TL;DR: OPA policies built for deterministic microservices break down when agents make multi-hop, delegated tool calls across APIs, data stores, and payment rails, according to PermitIO. The authorization model now has to carry ephemeral agent identity, delegation scope, and real-time entitlement changes, or access decisions become blind to what the agent is actually doing.
At a glance
What this is: This is a PermitIO analysis of why OPA needs richer input context to authorize AI agents that call tools across multiple hops, with delegation chains, tenant boundaries and expiry now part of the decision.
Why it matters: It matters because IAM teams cannot govern agentic access with service-account assumptions when the policy engine must decide on delegated authority, not just caller identity.
Context
OPA was designed to decide access for stable callers that fit a simple subject-action-resource model. AI agents break that pattern because a single task can trigger many tool calls, sub-agents and downstream requests that depend on delegation, expiry and current entitlements.
The governance gap is not the policy engine itself but the context it receives. For agentic AI, identity, workflow state, tenant scope and parent-child authority all have to be visible at decision time, or policy becomes blind to who authorised what and under which boundary.
This is an authorization problem for AI agents and MCP-driven stacks, not a generic policy-as-code problem. The starting point is to treat delegated agent identity as a governable runtime subject rather than a renamed service account.
Key questions
Q: What breaks when OPA only sees subject, action and resource for AI agents?
A: OPA loses the ability to judge delegated authority. A simple subject-action-resource tuple can work for stable service callers, but it cannot represent user-to-agent delegation, multi-hop tool calls, tenant boundaries or parent-child scope. For agentic systems, that means the policy decision may be valid syntactically while still being wrong operationally.
Q: Why do AI agents need zero standing permissions instead of service-account style access?
A: Because an agent acts on borrowed authority that should expire with the task, not persist as a standing entitlement. Persistent credentials and long-lived tokens make it easy for scope to drift beyond the original delegation. Zero standing permissions forces each call to prove current authority, which is the right baseline for ephemeral agent identity.
Q: How do security teams know if agent authorization is actually working?
A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach. Good signals include short-lived credentials, task-scoped permissions, approval for sensitive changes, and clear logs linking each action to a user and an agent. If credentials are reused, privileges persist, or the agent can move between systems without reauthorization, the control is failing.
Q: Should teams enforce agent authorization at the gateway, API and data layers?
A: Yes, when agentic workflows can cross multiple services and datasets. A gateway can stop broad tool classes, but it cannot see row-level data scope or downstream API overreach. Layered enforcement is the safer model because each layer independently evaluates the same delegated authority boundary and can still deny if another layer misses it.
Technical breakdown
Why simple subject-action-resource inputs fail for agents
Traditional OPA inputs work when the caller is stable and the action is direct. AI agents are different because one user task can fan out into multiple tool calls, with sub-agents, workflow context and parent scopes changing the effective authority on each hop. If the policy input only contains subject, action and resource, OPA cannot evaluate delegation boundaries, tenant consistency or whether the current call exceeds the original grant. That is not a tuning issue. It is a mismatch between deterministic microservice assumptions and delegated, multi-hop agent behaviour.
Practical implication: feed OPA the agent run, user delegation, workflow and tenant context or the policy will overgrant by design.
Why zero standing permissions matters for delegated AI identity
Agentic access should be short-lived and scope-bound because the actor is ephemeral and its authority is derived, not inherent. In this model, zero standing permissions means no persistent agent credentials, no wildcard tokens and no session-long trust that survives entitlement changes. The policy must re-check every action against the current delegation chain, current user entitlements and the parent agent scope. That is what makes agent identity governable. Without expiry and re-evaluation, a delegated agent quietly turns into a standing privilege holder.
Practical implication: enforce per-call reauthorisation with expiry and scope intersection, not session-based trust.
Why layered enforcement is safer than a single AI guardrail
Agent authorization cannot rely on a single checkpoint because the agent path crosses gateway, API and data layers. A coarse gateway decision can approve a tool class, but it cannot see row-level access or downstream data scope. A data-layer policy can block overreach even when upstream checks miss it. That layered model matters because agent systems are non-deterministic in planning but deterministic in enforcement, so each layer must independently evaluate the same delegated authority boundary.
Practical implication: enforce authorization at gateway, API and data layers so one missed decision does not become full compromise.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Delegated AI authorization is exposing the limits of microservice-era policy design. OPA remains the right policy decision point, but the decision inputs now have to represent ephemeral agents, user delegation, workflow context and parent-child scope. The field is moving from caller identity to authority lineage, and that is a materially different governance problem. Practitioners need to treat context enrichment as part of the control, not a cosmetic addition.
Zero standing permissions is the correct baseline for agents because agent identity is borrowed authority, not native authority. A delegated agent should not keep persistent credentials or broad standing access after the task boundary closes. Once the actor can spawn sub-agents and chain tool calls, standing privilege becomes a structural governance failure. The implication is that access design must start from task scope, expiry and delegation intersection, not from durable account creation.
Richer context is now the boundary between explainable authorization and audit gaps. If the policy engine cannot reconstruct who delegated what, to whom, for how long and against which tenant, then “who authorised this call” becomes an after-the-fact investigation instead of a live decision property. That is a governance issue as much as a technical one. Teams should expect auditability to depend on policy input quality.
Layered enforcement is becoming the only credible control model for agentic stacks. A gateway check, an API check and a data-layer check each see different parts of the risk. The category is moving toward enforcement fabrics rather than single control planes because no one layer can fully observe delegated tool use. Practitioners should design for fail-closed overlap, not for one perfect gate.
Authority lineage is the named concept that will define mature agent governance. Agent authorization is no longer about whether a caller can reach a tool. It is about whether the current call is still within the original human delegation, the agent run scope and the tenant boundary. That concept matters because it turns policy from static permissioning into runtime proof of borrowed authority. Teams should govern the lineage, not the label on the identity.
From our research library:
- 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
- Read next: AI Agent Authorisation Guide
What this signals
Authority lineage is now the control surface. Agentic stacks are forcing IAM teams to stop thinking in terms of a single caller and start thinking in terms of delegation history, workflow context and tenant boundary. When policy decisions cannot reconstruct that lineage, the system is effectively authorizing labels rather than behaviour. Teams should treat identity minting and context propagation as part of the authorization design itself.
Delegation-aware policy inputs are becoming a hard requirement for multi-hop AI workflows. Service-account-era schemas do not carry enough meaning to govern sub-agent spawning, parent scope limits or mid-flight entitlement changes. The practical shift is from broad caller-centric allowlists to runtime proof of current authority. That is where authorization, auditability and incident response begin to converge.
For practitioners
- Enrich OPA input schemas for agents Add agent run identity, user principal, workflow ID, delegation chain, tenant and expiry to every authorization decision so policies can evaluate borrowed authority instead of just caller identity.
- Enforce zero standing permissions for agent runs Issue short-lived, task-scoped credentials for AI agents and require reauthorization on each tool invocation rather than across an entire workflow session.
- Validate parent-child scope before sub-agents execute Block child agent actions that exceed the parent run scope, especially where a supervisor agent spawns tool-specific sub-agents with narrower purpose and tenant context.
- Synchronise entitlement changes across all policy points Push policy and policy-data updates in real time to gateway, API and data-layer decision points so revocation takes effect before the next hop in a multi-step workflow.
- Test denial paths for multi-hop delegation Use policy tests to prove that expired delegation, broken chains, tenant mismatches and over-broad tool requests all fail closed before production rollout.
Key takeaways
- OPA policies built for deterministic microservices do not natively describe delegated AI-agent behaviour, which is why richer context has become central to authorization.
- The decisive control shift is from stable caller identity to authority lineage, including delegation chain, workflow state, tenant scope and expiry.
- Layered enforcement and real-time policy synchronisation are the practical controls that keep multi-hop agent access from outrunning governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent authorization fails when delegated authority and scope are not carried into the decision. |
| Recommendation — Model delegated agent authority as an identity and privilege abuse problem and block scope creep at decision time. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Ephemeral agent identity and delegation context must be proven on every call, not assumed. |
| NHI-05 — Overprivileged NHI | The article centres on reducing standing access and scope drift for agent identities. | |
| Recommendation — Require short-lived proof of delegated agent identity before any tool invocation is allowed. Constrain agent permissions to the smallest task scope and deny actions outside the delegated boundary. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Short-lived credentials and revalidation per call are core to the access model described. |
| Recommendation — Use authenticator lifecycle controls to issue, expire and revoke agent credentials on a task basis. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack pattern risk is over-broad tool access spreading across multi-hop workflows. |
| Recommendation — Map multi-hop tool abuse to credential access and lateral movement to prioritise detections on delegation abuse. | ||
Key terms
- Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
- Zero Standing Permissions: Zero standing permissions means an actor holds no durable broad privileges between tasks. Access is issued only when needed, scoped tightly to the action, and removed or contracted when the task ends or the context changes. For agents, this is a behavioural control as much as an access model.
- Authorization Lineage: Authorization lineage is the recorded path from original human approval through every identity, tool, and subagent involved in an action. It matters because fragmented agent workflows can obscure who approved what, making accountability and forensic reconstruction much harder when code, data, or production systems are touched.
- Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org