Security and access
What we read, what we change, what we never touch.
The questions a platform team asks before granting access, answered up front, with the exact policies. Read-only to start, every change approved by a person, and everything revocable by deleting one role.
- Finly AI
Proposal: resize 6 API nodes from m5.2xlarge to m5.xlarge on 30 days of p95 utilization. Saves $1,120 a month. Dry run attached.
Pull request opened in infra-live. No change applied. - Engineer
Reviewed the plan and the rollback. Approved for the Tuesday change window, one node group at a time.
Approval recorded on the pull request - Sage AI
Applied to node group api-a. Latency and error rate unchanged after 30 minutes. Proceeding to api-b.
Blast-radius limit: one group per hour - Sage AI
Console edit detected on a security group outside Terraform. Reverted and the diff posted to #infra.
Confirmed by the on-call engineer - Summary
2 changes applied, 2 approvals, 0 rollbacks. Audit log exported to your bucket.
Posted to #ops
How access is used
From a read-only role to an approved change.
- Read-only accessA cross-account role and Datadog read keys
- 30 days analysedCost, utilization and Datadog usage
- Findings rankedBy annual savings and blast radius
- Approved, then appliedAn engineer signs off. Changes land as pull requests.
What we read on day one
- Cost: Cost and Usage Report, Cost Explorer, commitment coverage and utilization
- Utilization: CloudWatch CPU, network and memory at p95 over 30 days
- Datadog usage: custom metric series by tag, log volume by index, host and APM counts
- Inventory: idle volumes, snapshots, NAT gateways, load balancers, untagged resources
What we change, after approval
- Compute: instance sizes, autoscaling bounds, non-production schedules, commitments
- Datadog: log exclusion and archive routing, metric tag allow-lists, monitor thresholds
- Delivery: a pull request where Terraform owns the resource, otherwise an API change with a record and a rollback
- Guardrails: a named approver, blast-radius limits, your change windows, an exportable audit log
| Access | Free audit | Managed plan |
|---|---|---|
| AWS | Cross-account role: ReadOnlyAccess, Cost Explorer, Cost and Usage Report, CloudWatch GetMetricData | Same, plus write scoped to each approved change. Pull requests where Terraform owns the resource. |
| Datadog | API key and application key with usage, metrics, logs configuration, monitors and dashboards read | Same, plus logs configuration and monitors write for approved changes |
| Kubernetes | Metrics through your existing Datadog or Prometheus. No cluster credentials. | Read-only kubeconfig, or your GitOps repository for node group changes |
| Data we handle | Metadata and utilization only | Metadata and utilization only. Never application data or log contents. |
| Revocation | Delete the role or the key | Same. The plan runs month to month. |
The exact access, as policy
What you create, word for word.
Two steps, about ten minutes, both reversible by deleting what you create. The account id and external id come from the call.
AWS: a cross-account role named DevLiftAudit
Attach the AWS managed policy ReadOnlyAccess, trust our account with an external id, and add the inline policy for billing data. Send us the role ARN.
Trust policy
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::DEVLIFT_ACCOUNT_ID:root" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "EXTERNAL_ID" } }
}]
}Inline policy for cost data
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ce:Get*", "ce:Describe*", "ce:List*",
"cur:DescribeReportDefinitions",
"cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics",
"savingsplans:Describe*", "compute-optimizer:Get*",
"organizations:Describe*", "organizations:List*"
],
"Resource": "*"
}]
}This allows no write, no read of object contents in S3 and no secrets. We read utilization metrics, inventory and billing data.
Datadog: read-scoped keys
An API key named devlift-audit and an application key with these scopes only.
usage_readmetrics_readlogs_read_configmonitors_readdashboards_readapm_read
We use them to read usage by product, metric cardinality by tag, log volume by index and service, host and APM counts, and which metrics and logs your dashboards and monitors actually query. We never read log contents.
Keys travel through a one-time secret link, not email.
What we never do
Six things the access does not allow, by design.
The role and the keys are scoped so these are not possible, not merely promised.
- Read application data or log contents
- Read S3 object contents
- Read secrets, keys or credentials
- Write anything without an approved change
- Hold standing admin access
- Keep access after the engagement ends
Guardrails on every change
The same six rules, whether an agent or an engineer proposes it.
A named approver
Every change carries the name of the engineer who approved it and the person on your side who can veto it.
Blast-radius limits
Changes land one resource group at a time, with a ceiling on how much can change in a window.
Your change windows
Nothing ships outside the hours you set, and production waits for staging where one exists.
A dry run and a rollback path
The plan is attached before approval and the rollback is written before the change is applied.
An exportable audit log
Who proposed, who approved, what changed and when, exported to a bucket you own.
Pull requests where Terraform owns the resource
Changes land in your repositories, reviewed the same way as your own. Otherwise an API change with a record and a rollback.
The people holding the keys
Engineers who break systems for a living, on the defending side.
OSWE-certified engineers, DEF CON and Black Hat speakers and former CTF leads, with five discovered CVEs between them. A shared pager. Someone is reachable when it breaks, under an SLA, and the same engineers approve every agent change.
Frameworks we build to
Questions
Before you grant access.
Do you need write access to start?
No. The audit runs on a read-only IAM role and a Datadog API key with read scope. Write access comes later, scoped to the changes you approve, and you can revoke it at any time.
Who approves changes?
A DevLift engineer signs off on every change the agents prepare, and your team keeps a veto. Nothing is applied on the strength of an agent's judgement alone.
Can our team review every change?
Yes. Where Terraform owns the resource the change is a pull request in your repository, reviewed the way you review your own. Elsewhere it is an API change with a record and a rollback you can read before it ships.
What data do you handle?
Metadata and utilization only: cost and usage reports, CloudWatch metrics, inventory, and Datadog usage by product, index and tag. Never application data or log contents.
How do we revoke access?
Delete the role and the keys. There is nothing else to remove. The managed plan runs month to month, so leaving is a matter of removing our role and taking the pager back.
Walk through it with an engineer.
Book a demo and bring your platform team. We will go through the role, the scopes and the approval flow on a live account.