DEV Community: Vamshidher Reddy Jannapu Reddy

"Just use RBAC" is half right. Here's the other half for AI agents.

Vamshidher Reddy Jannapu Reddy — Fri, 09 Oct 2026 01:12:35 +0000

I maintain Aegis-DevOps, an open-source check that runs before an AI coding agent's shell commands and blocks the ones your policy forbids. In the last two weeks I've heard the same objection twice. A Reddit thread said RBAC already does this. A maintainer turned down a plugin submission because the agent harness "already has built-in provisions for controlling tool use."

Both are half right. You should have RBAC, and you should use your agent's permission settings. But neither one answers the question that matters when an agent is about to run kubectl delete: should this action, from this agent, happen right now?

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

Agent permission settings match text

Claude Code's permission rules are a good example, and its documentation is unusually honest about them. A Bash rule matches the command text the model writes. The docs say a deny rule "isn't a security boundary around the program", and give examples: Bash(git push *) stops git push origin main but not git -C . push origin main. For inspecting the full command before it runs, they point you to a PreToolUse hook.

That's fine for what permission settings are for: deciding what the agent may run without asking you. It isn't a policy engine, and nobody claims it is.

A hook can do more because it can work out what the command does. These all reach the same rule in Aegis ("no deletes in the prod namespace"):

Command the agent writes	Result
`kubectl delete deploy web -n prod`	BLOCK
`kubectl -n prod delete deploy web`	BLOCK
`kubectl delete deploy web -nprod`	BLOCK
`/usr/bin/kubectl ...`, `sudo kubectl ...`, `env kubectl ...`	BLOCK
`bash -c 'kubectl delete deploy web -n prod'`	BLOCK
`K=kubectl; $K delete deploy web -n prod`	refused: can't be checked statically, so the hook denies it

The last row matters as much as the others. A guard that can't understand a command should say no, not "no rule matched, go ahead".

RBAC sees the developer, not the agent

RBAC and IAM decide what an identity may do. A coding agent on a laptop usually runs with the developer's own kubeconfig and cloud credentials. As far as the API server is concerned, the agent is the developer, with every permission the developer has.

You can fix that by giving agents their own identities, and you should. But even then, RBAC is a static grant. It can say "this service account may delete deployments in prod". It can't say "this agent may not, unless a human approved it, and not during the release freeze", and it has no idea where a rule came from.

That last part is the reason I built Aegis. In an agent's world, a "rule" can arrive inside a Jira ticket or a Slack message the agent was asked to read. So an Aegis rule only gets a vote if nobody has changed it since it was signed, and if its author was allowed to write that kind of rule. A line planted in a ticket gets no vote.

Use all three

The honest answer to "why not RBAC?" is "yes, and":

RBAC / IAM: the hard ceiling on what any identity can do. Keep it tight.
Agent permission settings: what the agent may run without asking you.
A pre-execution policy check: whether this specific action should happen, by rules you can trust.

The policy check doesn't have to stay on the laptop either. Once agents have their own identities, Aegis compiles the same policy into the platform layer: aegis compile aws writes Service Control Policies, and aegis compile kubernetes writes ValidatingAdmissionPolicies. That covers calls that never go through the hook, like a boto3 script. Both are previews, and I wrote up how the AWS part works.

What it doesn't do yet

Readers keep finding real gaps, which is the point of writing these posts. This week one found that a namespace-scoped rule doesn't match a command that relies on the namespace in your current kube context, and that kubectl apply -f - is allowed because the piped manifest is never read. Both are being fixed. Aegis is alpha. Don't put it in front of anything you care about without reading the open gaps in the repo first.

Try it

pip install aegis-devops && aegis init .aegis

# Claude Code
claude plugin marketplace add moneytool/aegis-devops
claude plugin install aegis-devops@aegis-devops

# Codex, Copilot, VS Code, Cursor, Gemini CLI, OpenCode
aegis install codex   # or copilot | vscode | cursor | gemini | opencode

If you think the RBAC answer is enough for your setup, I'd like to hear why. Issues are open at github.com/moneytool/aegis-devops.

My agent guardrail was fine. Its kubectl parser wasn't.

Vamshidher Reddy Jannapu Reddy — Thu, 08 Oct 2026 01:40:33 +0000

I maintain Aegis-DevOps, an open-source check that sits between an AI coding agent and the shell. Before Claude Code, Codex, Copilot, Cursor or Gemini CLI runs kubectl, terraform or a cloud CLI, Aegis turns the command into an intent (action, resource, namespace) and matches it against signed policy. Recently I asked three AI models to review the design for the next version. They also found four bugs in the version that was already shipped. None of them were in the policy engine. They were all in the step that decides what a command means.

Disclosure: I drafted this article with help from an AI assistant and reviewed it myself. The bugs, the fixes and the command output below are from the project's own changelog and from running both versions.

Why the parser is the security boundary

A rule like "no rollout restarts in prod" is written against a normalized intent: action rollout-restart, resource deployment/*, namespace prod. If the parser produces a different shape for the same command, the rule doesn't match. In most guards, including this one, "no rule matched" means allow.

So a parser bug isn't a crash or a wrong answer you'd notice. It's a silent allow.

Bug 1: a flag before the subcommand

kubectl accepts global flags almost anywhere, and agents put them anywhere. This is what 0.1.5 made of a perfectly ordinary command:

$ aegis check kubectl --json -- kubectl -n prod rollout restart deploy/web

0.1.5:  ALLOW  rollout--n  prod/*
        ALLOW  rollout--n  restart/*
        ALLOW  rollout--n  deployment/web     (namespace lost)
0.2.1:  ALLOW  rollout-restart  deployment/web  ns=prod

The parser took -n as the rollout subcommand, then read everything after it as resources. The namespace was gone, so a namespace-scoped rule about rollouts in prod could never match. The fix takes the subcommand before merging global options, and consumes global options that appear between rollout and restart too, because kubectl accepts that placement as well.

Bug 2: impersonation was treated as noise

--as changes who the API server thinks is making the request. Rules scoped to the agent's own identity stop applying server-side, which makes the client-side hook the only place that sees the swap before it happens.

$ aegis check kubectl --json -- kubectl --as admin rollout restart deploy/web -n prod

0.1.5:  ALLOW  rollout---as  admin/*   (and two more intents like it)
0.2.1:  ALLOW  rollout-restart  deployment/web  ns=prod
        BLOCK  impersonate  user/admin  ns=prod   [block-kubectl-impersonation]

In 0.2.1, --as, --as-group and --as-uid each become their own impersonate intent, and the example policy blocks them. kubectl rollout --as admin restart ... parses the same way.

Bug 3: the same object under different names

Rules are written against one canonical name per object. The parser didn't always produce it:

kubectl cordon node1        0.1.5: node1/*        0.2.1: node/node1
kubectl exec web-0 -n prod  0.1.5: web-0          0.2.1: pod/web-0
kubectl delete sc fast      0.1.5: sc/fast        0.2.1: storageclass/fast

A rule for storageclass/* missed sc/fast. A rule for node/* missed every drain and cordon.

There was a fourth case in this family that failed the other way. kubectl drain node1 --ignore-daemonsets was rejected as malformed (exit 65), because the parser thought the flag needed a value. The hook fails closed, so the agent got blocked instead of waved through. That's annoying, but it's the right way to be wrong. Failing closed turned a parser bug into friction instead of a hole.

Bug 4: letting untrusted rules stall the pipeline

This one isn't a parsing bug, but it's the one that worried me most, because it's the exact attack the project exists to stop.

Aegis only lets a rule vote if it passes two checks: nobody edited it after it was signed, and its author was allowed to write that kind of rule. A rule that fails either check is discarded. That stops a line planted in a ticket or a Slack thread from becoming policy.

But there was a path that ran before those checks. When the environment of an action couldn't be resolved, every matching rule forced ESCALATE. So an unauthorized rule scoped to env: prod could stall any action whose environment was unknown. That's a denial of service on the guardrail, from exactly the kind of rule it's meant to ignore. In 0.2.1 those rules are discarded on that path too, and reported in discarded[] like everywhere else.

What I'd tell anyone writing a command guard

These apply whether you're writing hooks for Claude Code, a wrapper script, or an admission policy.

Normalize before you match. Write rules against one canonical form, and test that every spelling (aliases, short kinds, plural kinds, bare names) reaches it.
Test flag placement, not just flags. Generate the same command with global options before the verb, between the verb and its subcommand, and at the end, and assert that the intent is identical.
Flags that change identity or target are part of the intent. --as, --context, --kubeconfig, -n. Never file them under "options we can ignore".
Fail closed on anything you don't fully understand. An unknown option should block, not fall through to "no rule matched".
Get someone else to read the design. None of these came from my tests. They came from reviewers reading the code while checking a design for something else.

Try it

The fixes are in 0.2.1 and later (0.3.2 is current on PyPI). If you wrote rules against the old forms (node1/*, bare pod names, short kinds), update them. docs/constraints.md has the normal forms.

pip install aegis-devops && aegis init .aegis

# Claude Code
claude plugin marketplace add moneytool/aegis-devops
claude plugin install aegis-devops@aegis-devops

# Gemini CLI
gemini extensions install https://github.com/moneytool/aegis-devops

# Codex, Copilot, VS Code, Cursor, OpenCode
aegis install codex   # or copilot | vscode | cursor | opencode

The follow-up, on enforcing the same policy in AWS itself: My agent guardrail only lived on the laptop. So I compiled it into AWS.

If you've found a command shape that slips past your own agent guard, I'd like to hear it. Issues are open at github.com/moneytool/aegis-devops.

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) shipped as a preview in 0.3.1, 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.