{"slug": "just-use-rbac-is-half-right-here-s-the-other-half-for-ai-agents", "title": "\"Just use RBAC\" is half right. Here's the other half for AI agents.", "summary": "A developer maintaining Aegis-DevOps, an open-source pre-execution policy check for AI coding agents, argues that RBAC and agent permission settings are necessary but insufficient because they cannot evaluate whether a specific action by a specific agent should occur at a given moment. The tool statically resolves shell commands — including namespace flags, sudo/env wrappers, and bash -c invocations — against signed rules, denying anything it cannot parse, and can compile the same policy into AWS Service Control Policies and Kubernetes ValidatingAdmissionPolicies. The developer notes Aegis is alpha and that two reported gaps, namespace-context matching and unread piped manifests via kubectl apply -f -, are being fixed.", "body_md": "I maintain [Aegis-DevOps](https://github.com/moneytool/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.\"\n\nBoth 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?\n\n*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.*\n\nClaude 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.\n\nThat'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.\n\nA 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\"):\n\n| Command the agent writes | Result | \n|---|---|\n| `kubectl delete deploy web -n prod` | BLOCK | \n| `kubectl -n prod delete deploy web` | BLOCK | \n| `kubectl delete deploy web -nprod` | BLOCK | \n| `/usr/bin/kubectl ...` ,`sudo kubectl ...` ,`env kubectl ...` | BLOCK | \n| `bash -c 'kubectl delete deploy web -n prod'` | BLOCK | \n| `K=kubectl; $K delete deploy web -n prod` | refused: can't be checked statically, so the hook denies it | \n\nThe 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\".\n\nRBAC 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.\n\nYou 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.\n\nThat 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.\n\nThe honest answer to \"why not RBAC?\" is \"yes, and\":\n\nThe 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](https://dev.to/moneytool/my-agent-guardrail-only-lived-on-the-laptop-so-i-compiled-it-into-aws-j1d).\n\nReaders 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.\n\n```\npip install aegis-devops && aegis init .aegis\n\n# Claude Code\nclaude plugin marketplace add moneytool/aegis-devops\nclaude plugin install aegis-devops@aegis-devops\n\n# Codex, Copilot, VS Code, Cursor, Gemini CLI, OpenCode\naegis install codex   # or copilot | vscode | cursor | gemini | opencode\n```\n\nIf 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](https://github.com/moneytool/aegis-devops).", "url": "https://wpnews.pro/news/just-use-rbac-is-half-right-here-s-the-other-half-for-ai-agents", "canonical_source": "https://dev.to/moneytool/just-use-rbac-is-half-right-heres-the-other-half-for-ai-agents-548o", "published_at": "2026-10-09 01:12:35+00:00", "updated_at": "2026-10-09 01:18:00.509491+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools", "ai-tools"], "entities": ["Aegis-DevOps", "Claude Code", "Kubernetes", "AWS", "Jira", "Slack", "Reddit"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/just-use-rbac-is-half-right-here-s-the-other-half-for-ai-agents", "markdown": "https://wpnews.pro/news/just-use-rbac-is-half-right-here-s-the-other-half-for-ai-agents.md", "text": "https://wpnews.pro/news/just-use-rbac-is-half-right-here-s-the-other-half-for-ai-agents.txt", "jsonld": "https://wpnews.pro/news/just-use-rbac-is-half-right-here-s-the-other-half-for-ai-agents.jsonld"}}