AI Agent Authorisation Guide: Least Privilege for Non-Deterministic Actors

Authentication tells you which agent is calling. Authorisation decides what it may do, and for AI agents that decision is much harder. Agents choose their own actions at runtime, act for users with different entitlements, chain calls across many systems and can be steered by the content they read. Static roles granted at deployment time either block agents from doing useful work or give them far more access than any single task needs. This guide explains how to apply least privilege to non-deterministic actors: task-scoped and just-in-time access, policy engines that decide each action in context, delegated authority from users, and human approval where it adds real protection.

Key takeaways

• Grant access to the task, not the agent. Scope permissions to what the current task needs, for as long as it needs them, rather than to everything the agent might ever do.
• Decide per action, in context. Check authorisation at each tool call using the agent, the user it acts for, the resource, the action and the current risk, not once at login.
• An agent acting for a user should never exceed that user's access, and usually needs much less.
• Keep authorisation outside the model. Prompts and guardrails express intent; only a policy enforcement point stops an action.
• Use human approval selectively, for irreversible, high-value or unusual actions, so approvals stay meaningful.

Why traditional access models struggle with agents

Role-based access control (RBAC) works when an identity's job is stable and its actions predictable. Agents break both assumptions:

• The same agent does different jobs. A general assistant may summarise a document in one task and update a CRM record in the next. A role broad enough for both is too broad for either.
• Actions are chosen at runtime. You cannot enumerate in advance every API call a planning agent might make.
• Authority is borrowed. Agents acting for users need the intersection of what the agent may do and what the user may do, which static roles cannot express.
• Input can redirect behaviour. An agent hijacked through prompt injection will try to use every permission it has. OWASP describes this pattern under ASI02 Tool Misuse and Exploitation and ASI03 Identity and Privilege Abuse in its Top 10 for Agentic Applications.

The result in many organisations is the worst of both: agents given broad, standing permissions "so they work", which is exactly the over-privilege described in OWASP NHI5.

Principles for authorising agents

1. Least privilege and least agency

Least privilege limits what an identity can access. For agents, OWASP also uses the idea of least agency: limit what the agent is allowed to decide and do on its own. An agent that only needs to read tickets should not have a tool that can close them, even if its credentials would allow it.

2. Task scoping

Tie permissions to a specific task: this ticket, this repository, this customer record, this date range. OAuth scopes are often too coarse for this. OAuth 2.0 Rich Authorization Requests (RFC 9396) lets a client request fine-grained authorisation details, such as a specific account and amount, rather than a broad scope string.

3. Just-in-time and ephemeral access

Issue access when the task starts and remove it when it ends. Short-lived tokens, temporary role assignments and dynamically generated secrets mean an agent holds nothing useful between tasks, and a stolen credential expires quickly. The Privileged Access Management Guide covers just-in-time access for privileged identities more broadly.

4. Intersection of user and agent

When an agent acts for a user, effective access should be the intersection of: what the user is entitled to, what the agent is permitted to do, and what the task requires. A resource server that only sees the user's token cannot enforce this. Delegation that carries both identities, for example OAuth 2.0 Token Exchange (RFC 8693) with an actor claim, makes it possible. See the Agentic AI Identity Guide.

5. Continuous, per-action decisions

Evaluate authorisation at each action. Context can change mid-task: the user's session may be revoked, the agent's behaviour may become anomalous, or the data may be reclassified. OWASP specifically warns about checking authority only at the start of a long workflow.

Access control models compared for agents

In practice most organisations combine them: roles to set outer boundaries, relationships and attributes to narrow access to the task, and an externalised policy engine to make and log each decision.

Where to enforce

Authorisation for agents is best enforced at several points, each covering a different gap:

• At token issuance: the authorisation server issues only the scopes and audiences the task needs, for a short time.
• At the tool or gateway: an MCP gateway, API gateway or tool wrapper checks each call against policy before it reaches the backend. This is the key control point for agents because it sees the specific tool and arguments.
• At the resource: the backend still enforces object-level permissions. Gateway checks do not replace them; broken object-level authorisation remains the top risk in the OWASP API Security Top 10.
• In the orchestrator: multi-agent systems check that delegated authority narrows at each hop. See the Multi-Agent and A2A Security Guide.

Standardised interfaces help connect these points to a shared policy engine. The OpenID Foundation's AuthZEN Authorization API 1.0, approved as a Final Specification in January 2026, defines how a policy enforcement point asks a policy decision point for a decision about a subject, action, resource and context. The AuthZEN working group has since published further drafts aimed at agent use cases.

Writing agent authorisation policy

A useful agent policy considers at least:

• Subject: the agent identity, its owner, its risk rating and its registered purpose.
• Principal: the user or system on whose behalf it acts, and their entitlements.
• Action: the specific tool or operation, and whether it reads, writes, deletes, sends externally or moves money.
• Resource: the object, its owner and its data classification.
• Context: the task the agent was given, time, request rate, recent anomalies and whether a human is present.

Example policy statements:

• The support agent may read tickets assigned to the requesting user's team and add comments; it may not close tickets or change assignees.
• The finance agent may prepare a payment but may not release one; releasing requires approval by a human with payment authority.
• Any agent reading data classified as confidential may not call tools that send data outside the organisation in the same task.
• No agent may delete production resources; deletion requests are converted to tickets for human review.

Human approval that works

Human-in-the-loop approval is an authorisation control, not a user experience feature. To keep it effective:

• Reserve it for high-impact actions: irreversible changes, payments, external communications, access grants and bulk data exports. Approving every step leads to fatigue and rubber-stamping.
• Show what will actually happen: the exact action, target and parameters, not the agent's summary of them. OWASP ASI09 Human-Agent Trust Exploitation describes agents producing convincing but false justifications.
• Enforce it in the platform: the action should be technically impossible without approval, not merely discouraged in the prompt.
• Use a separate channel for high-risk approvals: OpenID Connect Client-Initiated Backchannel Authentication (CIBA) is one standard pattern for asking a user to approve on another device.
• Record approvals with the approver, time, action and outcome.

Common failure patterns

• Agents granted admin or owner roles during a pilot "to avoid permission errors", then promoted to production unchanged.
• Agents that, faced with a permissions error, search for and use other credentials. In the PocketOS incident, a coding agent found a token with blanket API authority and used it to delete a production volume and its backups.
• OAuth consent screens that ask for full mailbox or full drive access when the task needs one folder.
• Authorisation logic embedded in prompts ("never delete anything") with no enforcement behind it.
• Tools that accept model-generated identifiers without checking the calling user may access that object.

A maturity path

1. Remove standing admin: no agent holds owner, admin or wildcard permissions.
2. Scope by function: each agent has a role limited to its purpose, and a separate identity from other agents.
3. Scope by task: short-lived, task-specific tokens issued just in time.
4. Externalise decisions: a policy engine evaluates each tool call with agent, user, resource and context.
5. Adapt to risk: policy responds to behaviour signals, stepping up to human approval or blocking when an agent behaves unusually.

Practitioner checklist

• Remove admin, owner and wildcard permissions from all agents.
• Give each agent a role limited to its registered purpose, and tools limited to what that purpose needs.
• Issue short-lived, task-scoped tokens just in time; consider Rich Authorization Requests for fine-grained grants.
• Ensure agents acting for users never exceed the user's access, using delegation that identifies both.
• Enforce authorisation at tool calls through a gateway or wrapper backed by a policy engine, and keep object-level checks in the backend.
• Require platform-enforced human approval for irreversible, financial, external and access-granting actions.
• Log every authorisation decision with agent, user, action, resource and outcome.
• Review agent permissions on a schedule and whenever tools, models or autonomy change.

Standards and references

• OWASP Top 10 for Agentic Applications for 2026: ASI02, ASI03, ASI09
• OWASP Non-Human Identities Top 10 (2025): NHI5 Overprivileged NHI
• OpenID AuthZEN Authorization API 1.0
• RFC 9396: OAuth 2.0 Rich Authorization Requests
• RFC 8693: OAuth 2.0 Token Exchange
• OpenID Connect CIBA Core 1.0
• NIST SP 800-162: Guide to Attribute Based Access Control
• OWASP API Security Top 10

Related NHI Mgmt Group resources: Agentic AI Identity Guide · Privileged Access Management Guide · Zero Trust for AI Agents · IAM and IGA Basics