Cerbos for AI agent security: what authorization changes

At a glance

What this is: Cerbos is an open-source authorization engine that centralises fine-grained policy decisions for applications and AI agents, with the key finding that policy enforcement is moving into runtime decision loops.

Why it matters: It matters because IAM, NHI, and agentic AI programmes now need consistent authorization controls that can follow users, service accounts, and agents across tools, data, and actions.

👉 Read WorkOS's analysis of Cerbos for AI agent authorization

Context

Authorization is the control plane that decides what an identity can do after authentication is complete. In AI agent and NHI environments, that decision can no longer live only in application code, because the same principal may touch multiple tools, resources, and workflows in a single session.

Cerbos is positioned around that problem: policy-based authorization for human users, service accounts, and AI agents that need resource-level decisions. The IAM issue is not just where identity is proven, but where permission is enforced, audited, and kept separate from business logic.

For teams building enterprise applications, this is a familiar governance gap with a new runtime shape. The controls that work for static role assignment often break when access depends on context, relationships, or agent-triggered tool use rather than a fixed user path.

Key questions

Q: How should security teams govern fine-grained authorization for AI agents and service accounts?

A: Security teams should centralise authorization in a policy layer that evaluates the principal, resource, action, and context at runtime. That keeps permission logic consistent across applications, makes policy changes testable, and avoids hardcoding rules into each service. For agents and service accounts, policies should reflect delegation boundaries, not just human roles.

Q: Why do AI agents increase the importance of runtime authorization?

A: AI agents can make repeated tool calls, retrieve data dynamically, and branch into new actions inside a single session. That makes pre-approved access lists too coarse for real governance. Runtime authorization is the control that keeps each action within scope as the agent moves through the workflow.

Q: What do teams get wrong when they rely on application code for permission checks?

A: They usually create inconsistent enforcement, because each service implements access rules differently and changes them on its own timeline. That breaks auditability and makes least privilege hard to prove. A central policy engine reduces those gaps by giving every request the same decision process.

Q: What is the difference between authentication and authorization in enterprise AI systems?

A: Authentication proves who or what the identity is, while authorization decides what that identity can do after it is verified. In enterprise AI systems, both layers matter. Authentication establishes the user, agent, or service account, and authorization must then constrain data access, tool use, and action scope.

Technical breakdown

Policy decision points for fine-grained authorization

A policy decision point centralises allow or deny logic so applications do not hardcode permission rules in every service. Cerbos evaluates YAML policies against the principal, resource, and action at request time, which supports RBAC, ABAC, and relationship-based rules in one control layer. That matters because authorization becomes a reusable service rather than a scattered set of checks. In practice, the architecture reduces duplication, improves testability, and makes policy changes visible through code review and audit logs.

Practical implication: move permission logic out of application branches and into a single policy evaluation layer that can be tested and audited.

GitOps policy workflows and authorization auditability

Treating policies as code means authorization rules are versioned, reviewed, and deployed through the same lifecycle as software changes. That pattern improves traceability because each policy update can carry tests, rollback history, and decision logs. For identity governance, the important detail is not automation for its own sake, but separation of duties between the code path and the approval path. It also creates evidence for investigations, since teams can reconstruct which policy produced a specific decision.

Practical implication: require policy tests and change review before authorization updates reach production.

MCP-based agent authorization and permission-aware RAG

In agent workflows, authorization has to sit inside the runtime loop, not after the agent has already retrieved or acted on data. Cerbos’ MCP-oriented patterns and permission-aware RAG approach try to check access before tool execution or retrieval, which limits exposure in context windows and downstream prompts. The architectural point is that the agent should never see data it is not permitted to use. That is especially relevant when a delegated agent acts on behalf of a user or service account.

Practical implication: enforce authorization before retrieval or tool invocation so sensitive data is never surfaced to the agent in the first place.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization sprawl is now an identity governance problem, not just an application design problem. When permission logic is scattered across services, teams lose a consistent control point for users, service accounts, and AI agents. That creates inconsistent enforcement, weak auditability, and policy drift across runtimes. The implication is that identity governance must own the policy layer as a first-class control surface.

Permission-aware agent design is closing a long-standing gap between identity and data access. AI agents and delegated workloads do not fit cleanly into human-centric approval models when they can query tools repeatedly in one interaction. Centralized authorization makes that runtime decision visible, which is why the category is moving toward policy evaluation at the point of action. Practitioners should treat this as an access architecture question, not an AI feature question.

Runtime authorization only works when the identity context is precise enough to govern delegation. If an agent is acting on behalf of a person, the entitlement boundary must follow that relationship rather than collapse into a generic application role. That is the governance value of policy engines in NHI programmes. The practitioner conclusion is simple: delegation chains need explicit policy semantics, or access will expand by default.

Least privilege is easiest to state and hardest to preserve once AI agents begin chaining tool calls. Static role design assumes the request path is predictable, but agentic workflows can branch across APIs, resources, and retrieval layers. That means permission scope is being tested continuously, not once at login. Teams should assume authorization failures will surface at the policy boundary before they show up in the business workflow.

Named concept: identity blast radius. The effective blast radius of an identity is the set of actions, data, and tools it can reach when authorization is evaluated at runtime. In agentic and NHI environments, that radius changes as policies, relationships, and context change. Practitioners should measure blast radius as a governance property, not just count roles or groups.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap is why practitioners should also study OWASP Agentic AI Top 10 alongside the NHI governance model.

What this signals

Identity governance programmes will increasingly be judged by whether they can enforce policy at runtime, not just prove authentication at onboarding. As agentic workflows expand, the useful control is the one that constrains action before data is exposed or tools are called. Teams that still treat authorization as application plumbing will miss the governance window where risk is actually created.

The next programme boundary is delegation. When a user, service account, or AI agent can act across multiple systems in a single session, the question is no longer who logged in, but which policy decided the next action. That is where a central policy engine becomes operationally relevant.

The practical signal to watch is policy drift across services, especially where AI retrieval or tool access is mixed with human application flows. If entitlements cannot be traced cleanly from identity to action, the governance model is already behind the runtime.

For practitioners

• Centralise authorization decisions in one policy layer Move fine-grained allow and deny logic out of scattered application code and into a single policy decision point that every service queries consistently. Preserve tests, version history, and decision logs so policy changes can be reviewed and explained.
• Model delegated agent access separately from human access Define explicit policy rules for agents acting on behalf of users, service accounts, or scheduled workflows. Do not reuse broad user roles when the agent can call tools, retrieve data, or chain actions across systems.
• Block retrieval before the model sees sensitive content Apply permission checks before RAG pipelines assemble context, not after the model has already consumed documents. This reduces the chance that a prompt, embedding, or context window exposes data outside the caller’s entitlement.
• Test authorization changes like code changes Require unit tests for policy logic, simulate edge cases for resource ownership and attribute conditions, and gate deployment on review. Authorization drift is usually introduced by small policy edits that nobody revalidates.

Key takeaways

• Fine-grained authorization is becoming a governance layer for AI agents, not just a developer convenience.
• Runtime policy enforcement matters because delegated identities can branch into actions that static role models do not capture.
• Teams that separate authentication from authorization cleanly will be better positioned to govern users, service accounts, and agents consistently.

Key terms

• Policy Decision Point: A policy decision point is the system that evaluates whether an identity should be allowed to perform a specific action on a specific resource. In NHI and agentic environments, it separates permission logic from application code, making access rules consistent, testable, and easier to audit.
• Attribute-Based Access Control: Attribute-based access control grants or denies access using context such as user role, resource state, time, location, or ownership. For non-human identities and agents, it is useful when entitlement must change dynamically instead of remaining fixed to a simple role assignment.
• Permission-aware Retrieval: Permission-aware retrieval is a pattern that filters documents or data before they enter an AI model’s context window. It prevents an agent from seeing content it is not entitled to use, which reduces leakage risk in retrieval-augmented generation workflows.
• Delegation Boundary: A delegation boundary is the line that separates what a person, service account, or agent may do directly from what it may do on behalf of someone else. It matters because runtime access should follow the delegated relationship, not expand into broad inherited privilege.

Deepen your knowledge

Authorization policy design for AI agents and service accounts is covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building runtime governance for delegated access, this is a practical place to start.

This post draws on content published by WorkOS: Cerbos for AI Agent Security: Features, Pricing, and Alternatives. Read the original.