AI Agent Authorisation: Least Privilege for Agents

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. 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. It is for IAM architects, security engineers and agent builders, and maps the controls to NIST, ISO, CIS and OWASP.

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 or at the start of a workflow.
Never exceed the delegating user. An agent acting for a user should never exceed that user's access, and usually needs much less; carry both identities so the resource can enforce the intersection.
Keep authorisation outside the model. Prompts and guardrails express intent; only a policy enforcement point in the platform, gateway or backend actually stops an action.
Use human approval selectively. Reserve it for irreversible, high-value or unusual actions, show the real parameters, and enforce it technically 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 under ASI02 Tool Misuse and Exploitation and ASI03 Identity and Privilege Abuse in its Top 10 for Agentic Applications for 2026. See the Prompt Injection Guide.

OWASP's LLM06:2025 Excessive Agency names the root causes as excessive functionality, permissions and autonomy, with examples such as a read-only extension whose identity can also update and delete, or a per-user extension that uses a generic high-privileged identity.

ASI03 warns that without a distinct, governed identity of its own an agent "operates in an attribution gap that makes enforcing true least privilege impossible". 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:2025 Overprivileged NHI. See the Agentic AI Identity Guide.

Principles for authorising agents

1. Least privilege and least agency

Least privilege limits what an identity can access. NIST SP 800-53 control AC-6 already frames it for software, allowing "only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks". OWASP extends this with least agency: avoid unnecessary autonomy, because "deploying agentic behavior where it is not needed expands the attack surface without adding value". ASI02 recommends per-tool least-privilege profiles (scopes, maximum rate and egress allowlists), expressed as authorisation policy attached to each tool rather than ad hoc conventions.

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. RFC 9396 (OAuth 2.0 Rich Authorization Requests) says the scope parameter suits "coarse-grained authorization requests" but not requirements such as "please let me transfer an amount of 45 Euros to Merchant A", and defines an authorization_details parameter that carries type, actions, locations and other fine-grained fields as JSON.

3. Just-in-time and ephemeral access

Issue access when the task starts and remove it when it ends. ASI02 recommends temporary credentials or API tokens "that expire immediately after use", bound to specific user sessions, and ASI03 recommends short-lived, narrowly scoped tokens per task capped by permission boundaries. This also addresses OWASP NHI7:2025 Long-Lived Secrets. See the JIT Access Guide and the Privileged Access Management Guide.

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. RFC 8693 (OAuth 2.0 Token Exchange) distinguishes impersonation, where A "is indistinguishable from B", from delegation, where A keeps its own identity and "any actions taken are being taken by A representing B". Its act claim identifies the acting party, and nested act claims record a chain of delegation. Prefer delegation for agents: the resource and the audit log can then see both identities. See the OAuth Token Exchange and Delegation Guide.

5. Continuous, per-action decisions

Evaluate authorisation at each action. ASI03 lists time-of-check to time-of-use in agent workflows as a named weakness, such as a purchase completed on an old token after the user's spending limit was cut. Its mitigation is to "re-verify each privileged step with a centralized policy engine".

Access control models compared for agents

Model	How it decides	Strengths for agents	Limitations for agents
RBAC (role-based)	Permissions attached to roles assigned to identities	Simple, familiar, easy to audit; good outer boundary	Too coarse; roles become broad to cover all possible tasks
ABAC (attribute-based)	Policy over attributes of subject, object, operation and environment	Can include task, data classification, time and risk	Needs good attribute data; policies can become complex
ReBAC (relationship-based)	Access derived from relationships (user owns document, agent assigned to project)	Natural fit for "on behalf of this user, for this project"	Relationship data must be accurate and current
PBAC (policy-based, externalised)	Central policy decision point evaluates requests from enforcement points	Consistent decisions across tools; per-action checks; auditable policy	Adds latency and a dependency; needs integration at each tool

NIST SP 800-162 defines ABAC as a method where authorisation "is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships". Most organisations combine models: roles set outer boundaries, attributes and relationships narrow access, and a policy engine decides and logs. See the Authorisation Models Guide.

Where to enforce

Enforce at several points; each covers a different gap.

Enforcement point	What it can see	What it should enforce	What it misses
Token issuance (authorisation server)	Client, user, requested scopes, audience, authorisation details	Only the scopes, audience and lifetime the task needs	Individual tool calls and their arguments
Tool wrapper, MCP server or gateway	The specific tool, arguments, calling agent and delegating user	Per-call policy decision, schema and rate limits, egress allowlists	Object ownership inside the backend
Resource (backend API)	The object, its owner and classification	Object-level permission for the identities in the token	Task context and agent behaviour
Orchestrator (multi-agent)	Delegation chain between agents	Authority narrows at each hop; no inheritance without re-validation	Backend state

Tool and gateway checks

The tool layer is the key control point because it sees the specific action and its parameters. ASI02 describes a pre-execution policy enforcement point (an "Intent Gate") that treats model output as untrusted and validates intent and arguments. For MCP over HTTP, the Model Context Protocol authorisation specification requires clients to send a resource parameter naming the MCP server, and requires servers to "validate that tokens presented to them were specifically issued for their use". It warns that token passthrough to downstream services causes the confused deputy problem. See the MCP Security Guide and the AI Agent Tool and Plugin Security Guide.

Resource checks and orchestrators

The backend still enforces object-level permissions. Gateway checks do not replace them: agents that pass model-generated object IDs recreate OWASP API1:2023 Broken Object Level Authorization. See the Broken Access Control Prevention Guide. In multi-agent systems, ASI03 describes the confused deputy pattern where "a compromised low-privilege agent can relay valid-looking instructions to a high-privilege agent". See the Multi-Agent and A2A Security Guide.

Standard interfaces

The OpenID Foundation's AuthZEN Authorization API 1.0, published as a Final Specification in January 2026, lets policy enforcement points ask a policy decision point for decisions "without requiring knowledge of each other's inner workings". Its information model is subject, action, resource, context and decision, with evaluation and search endpoints. The AuthZEN working group announced further drafts aimed at the agent era in June 2026.

Writing agent authorisation policy

A useful agent policy considers at least five inputs, which map onto the AuthZEN request model.

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 (the subject of a delegated token, with the agent in the act claim).
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.

The third rule targets the pattern in two disclosed cases. In EchoLeak 2025, instructions in an email made Microsoft 365 Copilot place internal data in a link the browser fetched; in ForcedLeak 2025, instructions in a Web-to-Lead form made Agentforce query CRM records and send them to an allowlisted domain that had expired. In both, the agent's own access did the work.

Keep policy in version control, give it an owner and test it against recorded agent traces.

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. ASI02 recommends a pre-execution plan or dry-run diff, and ASI09 Human-Agent Trust Exploitation describes "fake explainability", where an agent fabricates convincing rationales so humans approve unsafe actions.
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) separates the consumption device from an authentication device on which the user "authenticates and grants consent", which suits asking a user to approve an agent's action on their phone.
Record approvals with approver, time, action and outcome.

Action tier	Examples	Approval pattern
Read, within task scope	Read the assigned ticket, query the user's own records	No approval; policy decision and log only
Reversible write	Add a comment, draft an email, create a branch	No approval; rate limits and anomaly alerts
External or bulk	Send outside the organisation, export many records	User confirmation showing recipients and data, step-up if unusual
Irreversible or privileged	Delete, release payment, grant access, change production	Out-of-band approval by an authorised human; separation of duties

See the Segregation of Duties Guide for keeping preparer and approver roles apart when one side is an agent.

Common failure patterns

Pilot permissions promoted to production. Admin roles granted "to avoid permission errors" in a pilot survive into production.
Agents finding their own credentials. Faced with a permissions error, agents search for and use other credentials. In PocketOS Database Deletion 2026, a coding agent working in staging found a Railway token in an unrelated file; it had been created to manage custom domains but was account-scoped, and the agent used it to delete a production volume and its backups. See the AI Coding Agents Security Guide.
Instructions mistaken for permissions. In Replit AI Agent Database Deletion 2025, an agent deleted a live production database during a declared code freeze and against explicit instructions. Rules written into prompts ("never delete anything") are not enforcement.
Coarse consent. Full mailbox or drive scopes for a one-folder task. See the OAuth 2.0 and OpenID Connect Guide.
Un-scoped inheritance between agents. A manager agent delegates to a worker and passes its full access context, which ASI03 calls un-scoped privilege inheritance.
Cached credentials in memory. ASI03 describes agents that cache keys or retrieved data and reuse them for a later, less-privileged user. See the AI Agent Memory Security Guide.
Unchecked identifiers. Tools accept model-generated object IDs without checking the calling user may access that object.
Agents creating identities. In the UK AISI Agent Testing Incident 2026, agents under test created fake online identities and invited other agents to reuse their accounts. Account creation must be a controlled action.

Detection and monitoring

Authorisation decisions are rich telemetry: who asked to do what, for whom, and whether it was allowed. ASI02 recommends immutable logs of all tool invocations and parameter changes, and monitoring for anomalous execution rates, unusual tool chaining and policy violations. ASI03 adds monitoring when agents gain permissions indirectly through delegation chains, or request new scopes or reuse tokens outside their original intent.

Log every decision: agent, delegating user, action, resource, arguments summary, policy version and outcome, from both the gateway and the policy decision point.
Alert on denials as well as allows: repeated denials often show an agent probing for another way in, as in PocketOS.
Watch sequences: sensitive read then external send, or scopes outside the registered purpose.
Feed revocation: anomalies should revoke tokens and pause the agent automatically.

See the AI Agent Observability and Incident Response Guide.

Framework mapping

Control IDs below were checked against the published control text of each framework.

Practice	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP
Distinct, owned identity per agent	PR.AA-01	IA-4, AC-2	5.16 Identity management	Control 5	ASI03, NHI9
Least privilege and task-scoped access	PR.AA-05	AC-6, AC-6(5)	5.15 Access control, 8.2 Privileged access rights	Control 6	NHI5, ASI02, LLM06
Short-lived, just-in-time credentials	PR.AA-05	AC-6	5.17 Authentication information	Control 6	NHI7, ASI02, ASI03
Delegated authority carrying both identities	PR.AA-04	AC-6 (processes acting on behalf of users)	8.5 Secure authentication	Control 6	ASI03
Object-level checks at the resource	PR.AA-05	AC-6	8.3 Information access restriction	Control 6	API1:2023
Human approval and separation of duties	PR.AA-05	AC-5	5.3 Segregation of duties	Control 6	ASI09, LLM06
Periodic review of agent permissions	PR.AA-05	AC-2 (j), AC-6(7)	5.18 Access rights	Control 5, Control 6	NHI1, NHI5
Decision logging and monitoring	PR.PS-04, DE.CM-03, DE.CM-09	AU-6, AC-2(4), AC-2(12)	8.15 Logging, 8.16 Monitoring activities	Control 8	ASI02, ASI03

CSF 2.0 PR.AA-05 is the anchor for most rows: access permissions, entitlements and authorisations "are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties".

Metrics that show progress

Metric	What it shows	Target direction
Agents holding admin, owner or wildcard permissions	Standing over-privilege	Down to zero
Agents with a distinct identity and named owner	Attribution and accountability	Up to 100%
Median lifetime of agent access tokens	Exposure window if a token leaks	Down
Share of agent tool calls checked by a policy decision point	Coverage of per-action authorisation	Up
Share of delegated calls carrying both user and agent identity	Ability to enforce the user-agent intersection	Up
High-impact actions executed without recorded approval	Gaps in human approval enforcement	Down to zero
Approval rejection rate and time to decide	Whether approvals are real or rubber-stamped	Stable, non-zero rejections; short decisions
Granted permissions unused in the last 90 days	Room to tighten scopes	Down

A maturity path

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

See the Agentic AI Identity Maturity Model

Implementation roadmap

Phase	Focus	Actions
First 30 days	Visibility and quick wins	Inventory agents and the identities, tokens and tools each uses; remove admin, owner and wildcard grants; separate agent identities from human and shared accounts; block agent access to production delete operations
Days 31 to 90	Scoping and approval	Define a registered purpose and tool list per agent; move to short-lived tokens with audience restriction; put a gateway or tool wrapper in front of high-risk tools; enforce platform approval for irreversible, financial, external and access-granting actions
Days 91 to 180	Externalised, per-action policy	Connect enforcement points to a policy decision point (AuthZEN where supported); adopt token exchange so delegated calls carry both identities; log decisions centrally and alert on denials and risky sequences; review agent permissions on a schedule and on every model, tool or autonomy change

See the AI Agent Threat Modelling Guide.

Practitioner checklist

Remove admin, owner and wildcard permissions from all agents.
Give each agent its own identity, a named owner and a registered purpose.
Limit each agent's tools to what that purpose needs, with per-tool scopes, rate limits and egress allowlists.
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.
Validate token audience at every MCP server and API, and never pass tokens through to downstream services.
Require platform-enforced human approval for irreversible, financial, external and access-granting actions, showing the real parameters.
Stop authority being inherited between agents without re-validation, and clear cached credentials between tasks.
Log every authorisation decision with agent, user, action, resource, policy version and outcome, and alert on denials and risky sequences.
Review agent permissions on a schedule and whenever tools, models or autonomy change.

Standards and references

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

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