Security teams should model AI agents as first-class identities in a relationship graph, then evaluate access through the same shared context used for users, teams, and resources. That approach preserves delegation and collaboration semantics instead of flattening agents into human-style accounts or hard-coded rules.
How shared-context authorisation changes the problem
Dynamic authorisation for AI agents is not just about whether the agent can call a tool. The real question is whether the agent should inherit a slice of context that already expresses who it is acting for, what it is trying to do, and which resources are in scope. That makes authorisation a relationship problem, not a static role assignment problem.
In practice, the shared context becomes the control plane. If you treat the agent as a first-class identity inside that context, you can evaluate the request against the same graph of user, team, task, data, and resource relationships that drives collaboration for humans. That preserves delegated intent while avoiding brittle one-off permissions that quickly drift out of date.
The important distinction is that shared context should inform access, but not replace authorisation. The agent still needs an explicit decision boundary for each action, because context can be incomplete, stale, or overbroad. The goal is to let the agent benefit from inherited intent without turning every contextual reference into open-ended privilege.
What security teams need to check before they trust inherited access
Authorising by shared context only works when the context itself is trustworthy, current, and sufficiently bounded. Security teams should validate who established the context, which principals are represented in it, which resources are linked to it, and whether the agent is acting on behalf of a specific user, a team, or an organisational workflow.
That means the control question is not "does the agent belong here?" but "does this exact action remain valid under the context that was granted?" For example, a drafting assistant may be allowed to read project artefacts, but not export them; a workflow agent may be able to update a ticket, but not approve its own escalation. The inherited relationship should narrow or expand access only where the underlying delegation actually supports it.
Security teams should also watch for context leakage across conversations, workspaces, tenants, and sessions. If shared context is reused too broadly, an agent can accumulate invisible privilege from prior tasks or unrelated collaborators. The safer pattern is to bind context to a specific scope, time window, and action type, then re-evaluate when any of those change.
Why this model scales better than hard-coded agent permissions
Static allowlists and human-style account models tend to break down because agent behaviour is more situational than user behaviour. Agents often need narrow, temporary, and branching access that depends on the current request, the available tools, and the provenance of the context. A relationship-based model keeps that complexity legible without forcing teams to precompute every possible permission path.
This is also the cleanest way to keep delegation and collaboration semantics intact. If a user shares a resource with a team, and the agent is operating inside that team workflow, the authorisation decision can follow the same sharing logic instead of inventing a separate agent-only policy language. Security teams can then reason about least privilege at the level of the shared context, not at the level of every prompt.
A good implementation also makes revocation practical. When the human delegate leaves the workflow, loses access, or changes role, the agent should inherit that change immediately. If the agent retains a separate privilege set, teams lose the ability to explain why access exists and when it should disappear.
Risk and Threat Considerations
Shared-context authorisation reduces friction, but it also creates a powerful failure mode: an agent can inherit more access than intended if the context is too broad, stale, or contaminated by prior sessions. That turns convenience into an attack surface, especially where a malicious prompt, misleading reference, or compromised collaborator can influence what the agent believes it is allowed to do.
Failure mechanism: overbroad or unverified context can cause the authoriser to treat ambient collaboration signals as permission, so the agent inherits access that was never intended for the specific action or resource.
Impact: the agent may read, move, modify, or exfiltrate data outside the task boundary, and those actions can look legitimate unless the team can reconstruct the exact context and delegation path.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents inheriting shared-context access face privilege abuse risk. |
| ASI09 — Human-Agent Trust Exploitation | Shared-context delegation can be abused when trust signals are overextended. | |
| Recommendation — Enforce per-action authorization so agent privilege cannot exceed the delegated context. Validate context provenance before letting an agent act on shared trust. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Dynamic agent access should stay bounded to the minimum context needed. |
| IA-5 — Authenticator Management | Shared-context agents still rely on credential and token lifecycle control. | |
| AU-2 — Event Logging | Context-based agent decisions need traceable evidence for review and incident response. | |
| Recommendation — Limit each agent to the minimum permissions required for the current task. Rotate and revoke agent credentials promptly when context or delegation changes. Log the context, principal, and decision basis for each agent authorization event. | ||
| NIST Zero Trust (SP 800-207) | PDP/PEP — Policy Decision and Enforcement | Dynamic authorization requires evaluating each agent action against policy in real time. |
| Recommendation — Separate policy decision from enforcement and re-evaluate every agent request. | ||
| OWASP ASVS | V8 — Authorization | The topic is fundamentally about controlling what an agent may do through shared context. |
| Recommendation — Apply authorization checks that bind each action to the correct actor and resource. | ||
Practitioner Guidance
What to prioritise: define the smallest usable unit of shared context, then require every agent action to resolve against that unit before it is executed. If the action cannot be tied to a specific user, team, resource, and purpose, treat it as a new authorisation decision rather than an inherited one.
What to verify: the context should carry provenance, scope, expiry, and revocation state. Security teams should be able to prove which principal introduced the context, what the agent was expected to do, and why the access still exists at the moment of use.
Practitioner takeaway: treat inherited access as delegated intent with limits, not as standing permission, because the safest agent is the one that can explain exactly why each action is allowed right now.
Related resources from NHI Mgmt Group
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
- How should security teams manage permissions for AI agents?
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 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org