DEV Community: Vamshidher Reddy Jannapu Reddy

My agent guardrail only lived on the laptop. So I compiled it into AWS.

Vamshidher Reddy Jannapu Reddy — Thu, 01 Oct 2026 19:08:30 +0000

For the past few weeks I've been building Aegis-DevOps, an open-source check that sits in front of the shell commands an AI coding agent runs. Before Claude Code, Codex, Copilot, Cursor or Gemini CLI runs kubectl, terraform or aws, a hook hands the command to Aegis, and Aegis blocks it if your signed policy says no. It works. It also has a hole I knew about from the start, and version 0.3.0 is my first attempt at closing it.

Disclosure: I drafted this article with help from an AI assistant and reviewed it myself. The commands and output below are from running aegis-devops 0.3.0 against its example policy.

The hole: a hook only sees commands

A pre-execution hook sees the command string the agent asks its shell tool to run. It doesn't see:

a Python script the agent writes and runs, which calls boto3 directly;
an SDK call from code the agent is "just testing";
a credential the agent found in a file and used from somewhere else.

In all three cases the destructive call reaches the AWS API without ever looking like aws s3 rb. Blocking on the client is the right first layer, because it's fast and it can explain itself to the model. It isn't the last layer.

The fix: let AWS refuse the call

AWS already has a control that sits above everything an identity inside an account can do: a Service Control Policy. An SCP attached to an account in an AWS Organization caps what any role in that account may do, and an agent with IAM rights inside the account can't detach it.

So 0.3.0 adds a compiler. It takes the same policy the hook enforces and writes it out as SCPs:

$ aegis compile aws --account 111122223333 --out build/aegis-aws
aegis: wrote 1 SCP(s) for account 111122223333 to build/aegis-aws
       (exact=2, not-applicable=27, partial=1)
aegis: agents.yaml is report-only: the SCPs are under report-only/ and are not for attaching;
       review coverage.md, then set enforcement: enforce

The rule "never delete an S3 bucket or an RDS database" becomes an explicit Deny:

{
  "Effect": "Deny",
  "Action": ["rds:DeleteDBInstance", "rds:DeleteDBCluster", "rds:DeleteDBSnapshot",
             "rds:DeleteDBClusterSnapshot", "s3:DeleteBucket", "s3:DeleteObject",
             "s3:DeleteObjectVersion"],
  "Resource": ["*"],
  "Condition": {
    "ArnNotLike": { "aws:PrincipalArn": ["arn:aws:iam::111122223333:role/BreakGlass",
                                         "arn:aws:iam::111122223333:role/Deploy"] },
    "StringNotEqualsIfExists": { "aws:SourceIdentity": ["alice@example.com"] }
  }
}

Now it doesn't matter whether the agent typed aws s3 rb, wrote a boto3 script, or found a key. If the call is made as an agent identity, AWS refuses it.

Who counts as an agent?

An API call carries an identity, not a hint about who was typing. So the compiler needs an identity model, in a signed agents.yaml. The default is deny-by-default: you list the identities you trust (people, your deploy role, CI bound to a specific workflow), plus at least one break-glass role, and everything else is treated as an agent.

I went with deny-by-default because the other way round, listing the agents, fails open. Forget one, or let an agent mint a new role, and the new one isn't restricted.

An agent will try to become trusted

If the only thing between an agent and DeleteDBInstance is "is this call from the Deploy role?", the obvious move is to become the Deploy role. So every compile also adds statements that stop exactly that:

no sts:AssumeRole into a trusted or break-glass role, and no iam:PassRole of one;
no edits to a trusted role's trust policy or permissions, and no new credentials for a trusted user;
no setting an exempt source identity on a session;
no organizations:LeaveOrganization, since an account that leaves the organization sheds its SCPs.

The part I care about most: saying what it doesn't cover

A guardrail that looks stronger than it is does more damage than no guardrail, because people stop checking. So every compile writes a coverage report, rule by rule:

### block-s3-bucket-delete: exact, mapping verified
- enforced: s3/bucket delete (s3:DeleteBucket, s3:DeleteObject, s3:DeleteObjectVersion)
- same effect, not covered: s3:PutLifecycleConfiguration: an expiration rule deletes every object
- same effect, not covered: s3:PutBucketPolicy: a deny-all bucket policy locks everyone out

### block-rds-delete: partial, mapping verified
- not enforced: 'rds/*' also matches resource types the action map does not know
- same effect, not covered: rds:ModifyDBInstance: BackupRetentionPeriod=0 deletes the automated backups

"Same effect, not covered" is the list of other ways to reach the same outcome that the rule, as written, doesn't block. You can widen the rule, or accept the gap knowingly.

A few more choices along the same lines:

Report-only first. The first compile writes SCPs into report-only/ and tells you not to attach them. You switch agents.yaml to enforce (a signed change) once you've reviewed who would be restricted.
Aegis never holds cloud write credentials. It writes JSON, and you apply it with your own infrastructure as code.
Unverified rules never reach a compiled policy. The compiler starts from a verified snapshot, so a rule that was tampered with, forged, or written by someone not allowed to write it gets no vote, the same as on the client.
Every action mapping was tested in a sandbox AWS Organization, with live calls and the IAM policy simulator. A mapping added later starts out marked unverified.

What's still missing

It's a preview. AWS is in the 0.3.0 release; a Kubernetes target (ValidatingAdmissionPolicies scoped to agent identities) is merged and waiting for the next release, and GCP and Azure are designed but not built. SCPs don't apply to an organization's management account, so agents shouldn't run there at all. Rules with a time window or a rate limit stay client-side, because an SCP can't express them. And it's a young project: I'd much rather hear "this mapping is wrong" now than after someone relies on it.

Try it

pip install aegis-devops
aegis init .aegis
aegis compile aws --account <your-account-id> --out build/aegis-aws

If you run agents with real AWS access, I'd like to know how you scope them today. Issues are open at github.com/moneytool/aegis-devops.

Deleting your AWS Copilot stacks can delete your database. Here's why.

Vamshidher Reddy Jannapu Reddy — Thu, 01 Oct 2026 02:51:27 +0000

AWS ended support for the Copilot CLI on June 12, 2026 and archived the repository ten days later. If you deployed ECS services with Copilot, they keep running: Copilot was only ever a generator of CloudFormation stacks.

The trouble starts when you try to leave. Most teams want those services in Terraform, and the obvious plan is "recreate it in Terraform, then delete the Copilot stacks." Done naively, that plan deletes production.

The four traps

I read through Copilot's source to map exactly what happens when its stacks are deleted. Four things stand out.

1. Custom-resource Delete handlers. Copilot ships 13 Lambda-backed custom resources, and 9 of them do something destructive on Delete. When the environment stack goes, they:

delete the ACM certificate and its DNS validation records,
delete every Route 53 alias record for your custom domains,
delete the NS delegation record in the app's hosted zone,
empty the ELB access-logs bucket, every object version included.

Importing those resources into Terraform first doesn't save you: the Lambda doesn't care who manages the certificate now.

2. The env-controller. Each service stack carries an EnvControllerAction custom resource. When the last service that needs a shared ALB, NAT gateways or EFS is deleted, the env-controller updates the environment stack and removes them. Delete your last service stack and your load balancer and file system go with it.

3. Unprotected addons. Aurora, DynamoDB and S3 addons live in a nested stack with no DeletionPolicy. Delete the parent and CloudFormation deletes your database.

4. --retain-resources doesn't help. The flag everyone reaches for only works on stacks already in DELETE_FAILED.

Adopt in place instead of rebuilding

The safe sequence is:

Put DeletionPolicy: Retain and UpdateReplacePolicy: Retain on every resource in every stack, nested stacks and the StackSet included. Retain on a Custom::* resource also stops CloudFormation from invoking its Delete handler.
Import every resource into Terraform with the exact values it runs with today, so the first plan is import-only.
Delete the Copilot stacks. CloudFormation forgets the resources; nothing is deleted.

Doing that by hand across dozens of resources is error-prone, so I built a tool for it.

ecsodus

ecsodus is an open-source CLI (Apache-2.0) that does exactly that sequence and nothing else:

uvx ecsodus inventory --app myapp -o inventory.json   # read-only discovery
uvx ecsodus report    inventory.json                  # REPORT.md: what's safe, what's blocked, why
uvx ecsodus generate  inventory.json --out infra/     # Terraform + retain patches + RUNBOOK.md

The design choices that matter for a tool like this:

Read-only by construction. Every AWS client is wrapped in a guard that refuses anything but Describe, List, Get and Lookup. ecsodus never applies Terraform, deletes anything or moves traffic. You run the runbook.
Exact imports. Each resource becomes a flat aws_* block built from literal deployed values, and ecsodus check --phase import rejects any plan with an update, create, delete or replacement.
Policy-only change sets. The retain patch edits the deployed template line by line, and check --changeset accepts a change set only if it changes deletion policies and nothing else.
Never split a stack. If anything in a stack is unsupported, the whole stack (and everything that depends on it) stays on Copilot, and the report says why.
An honest baseline. Every report starts with the zero-risk option: keep the CloudFormation.

Does it work?

On September 30 I ran it end to end against a real Copilot v1.34.1 app (an environment, a Load Balanced Web Service, DynamoDB and S3 addons; 5 stacks, 49 resources) in a sandbox account:

44 of 44 resources imported, 0 changed, 0 destroyed.
Every Copilot stack and the StackSet deleted.
The service kept returning HTTP 200, and the sentinel data in DynamoDB and S3 survived.
The env-controller and rule-priority Lambdas were never invoked on teardown.

The full report is in the repo: docs/e2e/2026-09-30-aws-e2e.md.

What it doesn't do yet

It's alpha. v0.1 supports Load Balanced Web Services and Backend Services, their environment, and Aurora/RDS, DynamoDB and S3 addons. Worker Services, Scheduled Jobs, Request-Driven Web Services, Static Sites, NLB, CloudFront, sidecars and pipelines are detected and reported as blocked. App Runner is next.

If you're still running something on Copilot, I'd like to hear what it is. Run ecsodus inventory and ecsodus report (both read-only) and open an issue with what's blocked: that's how the roadmap gets set. And if the tool saves you a bad afternoon, a star on GitHub helps other Copilot users find it.