The debate over how to secure AI coding agents often devolves into a false binary: rely on existing RBAC or trust the agent’s built-in permission settings. But the maintainer of Aegis-DevOps, an open-source policy engine for AI agents, argues both are insufficient for modern agentic workflows. In a recent post on DEV.to, the author reveals that these mechanisms fail to answer the critical question: should this specific action, from this specific agent, happen right now? The tool, Aegis-DevOps version 0.3.2, intercepts shell commands before execution to enforce dynamic policies that static permissions cannot handle.

The Text-Matching Trap in Agent Permissions

Standard agent permission systems, such as those in Claude Code, rely heavily on text matching. The documentation for Claude Code explicitly admits that a deny rule isn't a security boundary around the program. For example, a rule blocking git push * will stop git push origin main but fail to catch git -C . push origin main. While permission settings are useful for deciding what an agent may run without asking the user, they are not policy engines. Aegis-DevOps demonstrates this gap by blocking various obfuscated forms of kubectl delete commands, including those wrapped in sudo, env, or bash -c, which simple text matches miss entirely. Crucially, if a command cannot be checked statically, the hook denies it rather than allowing it by default.

RBAC Sees the Developer, Not the Agent

Role-Based Access Control (RBAC) and IAM systems operate on identity, not intent. In most local development environments, an AI agent runs with the developer’s own kubeconfig and cloud credentials. To the API server, the agent is indistinguishable from the developer, inheriting all permissions. Even if agents are given their own service accounts, RBAC remains a static grant. It can allow a service account to delete deployments in production, but it cannot enforce conditional logic such as blocking actions unless a human approved them or preventing deletes during a release freeze. Furthermore, RBAC has no mechanism to validate the provenance of a rule, leaving systems vulnerable to prompt injection where malicious instructions arrive via Jira tickets or Slack messages.

Provenance and Dynamic Policy Enforcement

Aegis-DevOps addresses the provenance gap by requiring that rules be signed and unmodified to be considered valid. If a line is planted in a ticket by an unauthorized source, it gets no vote in the policy engine. This approach moves beyond static grants to dynamic, context-aware enforcement. The tool also extends beyond the local laptop; it can compile policies into platform-layer controls, such as AWS Service Control Policies and Kubernetes ValidatingAdmissionPolicies. These compiled previews help cover calls that bypass local hooks, such as scripts using boto3, ensuring consistency across the stack.

Known Gaps in Alpha Software

Despite its sophisticated approach, Aegis-DevOps is still in alpha and has acknowledged limitations. Recent community feedback identified two significant gaps: namespace-scoped rules failing to match commands that rely on the current kube context, and kubectl apply -f - being allowed because the piped manifest is never read. The maintainer emphasizes that users should not deploy this tool in front of critical infrastructure without reviewing the open gaps in the repository. The tool is designed to be a complement to, not a replacement for, strict RBAC and careful agent configuration.

Key Takeaways

  • Text-matching permission rules in agents like Claude Code are not security boundaries and can be bypassed by command obfuscation.
  • RBAC and IAM cannot enforce conditional or temporal policies, such as blocking actions during release freezes.
  • Aegis-DevOps uses pre-execution hooks to analyze command intent and provenance, blocking actions based on dynamic rules rather than static identity grants.
  • The tool is currently in alpha with known gaps in handling kube contexts and piped manifests, requiring careful review before production use.

The Bottom Line

RBAC and agent permissions are necessary but insufficient security layers for AI agents. True safety requires a dynamic policy engine that validates command intent, provenance, and context before execution, rather than relying on static identity grants or fragile text matching.