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.
What a simple subject-action-resource policy can and cannot express
Subject, action and resource are enough for a narrow allow-or-deny decision when the caller is stable and the permission boundary is simple. They break down when the decision depends on who is acting on whose behalf, which step in a chain is being authorised, or whether the requested operation is within the caller’s delegated scope rather than its raw identity.
That matters because agentic systems often make requests through layered context: a user starts the task, an agent interprets it, and tools execute parts of it. If the policy engine only sees a flat tuple, it cannot distinguish direct user intent from delegated action, or a legitimate nested request from an overreaching one.
For that reason, the missing primitive is not just “more fields”, but a way to carry authority context across the request path. Without that context, policy may still parse cleanly while failing to represent the actual security relationship that should govern the action.
Where delegated authority and multi-hop control collapse
The most important failure is delegated authority. A user may allow an agent to do one bounded task, but the agent may need to call several tools, each with different limits, tenant scopes or trust boundaries. A flat policy model has no native way to express the difference between “this agent may do X for this user in this session” and “this principal may do X in general”.
Multi-hop tool use creates the same problem. If one call triggers another, and the second call inherits context from the first, the policy decision needs to know whether authority should cascade, narrow or stop. Without an explicit delegation model, the system can accidentally treat inherited context as if it were original authority.
That is why this issue is closely tied to per-action authorization for agents. The relevant control is not merely access to a resource, but whether the agent is allowed to exercise a particular capability, under a particular delegation chain, at a particular point in the workflow. AI Agent Authorisation Guide covers the least-privilege pattern that flat subject-action-resource checks cannot capture on their own.
What policy models need beyond the flat tuple
To govern agentic requests well, policy needs more than identity and target object. It needs provenance of the request, the acting principal versus the end user, the tenant or boundary being crossed, and the scope of authority that has been delegated for this interaction. Those are the dimensions that determine whether a request is acceptable even when the operation itself looks ordinary.
This is also where agent identity becomes important. If the system cannot distinguish the agent as an acting entity from the human who initiated the task, then it cannot answer basic questions about ownership, approval, revocation or containment. Agentic AI Identity Guide is useful here because it frames identity as something that carries delegated authority, not just a login artifact.
For practical policy design, that means the decision point should not rely on a single static tuple when the request is actually a workflow. A better model carries context such as actor, delegation source, scope, tenant, tool chain and session boundary. Model Context Protocol: Authorization specification shows how audience-bound tokens and resource-server semantics are used to keep the authorization context attached to the right boundary.
Risk and Threat Considerations
When delegated authority is flattened into a subject-action-resource tuple, the main risk is overreach that still looks syntactically valid. An agent can obtain or reuse a request shape that passes policy checks while crossing a tenant boundary, exceeding its session scope, or executing a tool chain the user never intended.
Failure mechanism: The policy decision point evaluates the immediate request but loses the chain of authority, so inherited context, token reuse or tool fan-out can be mistaken for legitimate permission.
Impact: That can produce unauthorized actions, data exposure, cross-tenant mistakes or privilege amplification that is hard to detect because each individual step may appear normal in isolation.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent requests can look valid while using the wrong authority context. |
| Recommendation — Enforce per-action authorization and constrain delegated agent privilege. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Flat tuples hide when agents exceed their intended scope and boundaries. |
| Recommendation — Scope agent credentials to the minimum authority needed for each task. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegated agent actions should be limited to only the access each step needs. |
| IA-9 — Service Identification and Authentication | Agent-to-tool and service-to-service requests need stronger identity context than a flat tuple. | |
| Recommendation — Restrict each agent workflow step to least-privilege access. Authenticate non-human callers with context that preserves delegated authority. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Policy must verify each request and assume the caller may not carry broad standing trust. |
| Recommendation — Evaluate every agent action as a separate trust decision. | ||
Practitioner Guidance
What to verify: Check whether your policy engine can answer three separate questions for every agentic request: who initiated it, who is executing it, and what delegated scope is being exercised. If those answers collapse into one field, the model is too coarse for agent workflows.
Decision rule: If the request can cross a tenant boundary, invoke another tool, or act after a human handoff, require delegation-aware policy attributes rather than a flat allow-or-deny tuple. If none of those are true, a simpler policy may still be adequate.
Practitioner takeaway: For AI agents, the hard problem is not deciding whether a resource is allowed in the abstract, but preserving enough authority context to decide whether this actor may use that resource this way, right now.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org