AI Agent Permissions: How to Apply Least Privilege, Identity and Access Control to AI Agents

AI agent permissions decide which tools, data and actions an agent may use, on whose behalf and for how long. Apply least privilege tool by tool: read-only by default, narrow write scopes with value limits, no right the requesting user lacks, and short-lived credentials issued for a task instead of standing access. Check each call against policy at the moment it happens, send high-impact actions to a named approver, and log every allow and deny so that permissions can be reviewed and revoked.

Permissions are where agent security is won or lost. The OWASP Top 10 for Agentic Applications lists identity and privilege abuse as ASI03 and observes that an agent without a governed identity of its own works in an attribution gap where least privilege cannot be enforced. Financial regulation reaches the same point from the access-control side: DORA’s risk-management standards require EU financial entities to assign access rights on need-to-know, need-to-use and least-privilege principles. This guide sets out the design choices. The wider threat model is in the agentic AI security guide.

Why AI agent permissions go wrong

Three patterns produce most over-privileged agents.

The agent inherits a person’s full rights

When an agent runs inside a user’s session or with a copy of the user’s token, it can do anything that user can, across every system the token reaches, although the task needs a fraction of that. A finance manager who can approve payments, read salary files and edit supplier records lends all three to an agent asked to summarise one invoice. OWASP describes the multi-agent version as un-scoped privilege inheritance: an orchestrating agent delegates work and passes along its whole access context, so a narrow worker ends up with broad rights.

The confused deputy

A deputy is a program that holds authority and acts on requests from others; it is confused when it spends its own authority on behalf of a requester who should not have it. In agent systems the requester can be a poisoned document, another agent or a crafted message. ASI03 describes a low-privilege agent relaying valid-looking instructions to a high-privilege agent that executes them without re-checking the original user’s intent. The MCP security guidance covers protocol-level variants, including token passthrough, where a server forwards a client’s token to a downstream API that then trusts it.

The shared service account

Many first deployments run every agent under one technical account with rights wide enough for the most demanding agent. Downstream logs then show identical actions, one compromised agent holds everyone’s access, and revoking the account stops every agent at once. Article 21(c) of the DORA standards on ICT risk management asks financial entities to limit generic and shared accounts and to keep users identifiable for the actions they perform. A fleet of agents behind one account defeats both aims.

Identity models for AI agents

Every agent action involves at least two identities: the person or system the agent works for, and the agent itself. AI agent identity management is the choice of which of them a downstream system sees, and how each is issued, scoped and retired.

RFC 8693, published in January 2020, distinguishes delegation from impersonation: with delegation the acting party keeps its own identity, separate from the subject it acts for, which is what an audit trail needs. Identity providers now ship agent-specific constructs on top of these standards. Microsoft’s documentation lists Microsoft Entra Agent ID as generally available, on a “What’s new” page dated 1 May 2026, with agent identity blueprints, sponsors, access packages for on-behalf-of and autonomous agents, and Conditional Access templates for agents. AWS made on-behalf-of token exchange generally available in Amazon Bedrock AgentCore Identity on 30 April 2026; the exchanged token is scoped down and carries both the user’s and the agent’s identity. For workload identity without a cloud provider, SPIFFE and SPIRE graduated as Cloud Native Computing Foundation projects in 2022, and NIST’s National Cybersecurity Center of Excellence published a draft concept paper on software and AI agent identity and authorisation on 5 February 2026.

Whichever model you use, compute effective permission as an intersection: what the agent may ever do, limited by what the person behind it may do, limited again by what this task needs. The identity and containment checklist covers what to require before an agent receives production credentials.

Designing AI agent permissions tool by tool

The AI agent governance and security handbook specifies the full permission decision order and tool contract; the sections below cover the decisions that matter most.

Scope each grant to a tool and a resource

Grant tools one at a time from a register, and scope each grant to the resource it needs: one mailbox, one project, one table, one customer segment. A tool called “CRM” is not a permission; “read open opportunities for accounts in the requester’s region” is. MITRE ATLAS mitigation AML.M0028 recommends that shared tools receive the permissions, identity and restrictions of the agent calling them, configured in the MCP server or in the tool itself. The explainer on tool use and function calling covers how agents select and call tools.

Separate read from write, and cap the values

Make read and write separate grants so that most agents never receive write rights at all. Where writing is necessary, constrain it: append-only fields, enumerated values, ranges, and limits per action and per day. An agent that may raise a reserve up to a set amount, and must ask above it, is far easier to defend than one permitted to “update claims”.

Just-in-time access and zero standing privilege

Zero standing privilege means the agent holds no long-lived rights between tasks. Access is requested for a specific operation, granted after a policy check for one operation or one run, and expires on its own. OWASP’s ASI03 mitigations call for task-scoped, time-bound permissions backed by short-lived credentials such as scoped tokens or mTLS certificates. The window for misuse shrinks, and every grant becomes an event in the log rather than an assumption.

Approval for high-impact actions

Some actions should never be fully delegated: moving money, changing entitlements, deleting records, writing to customers or regulators. Mark them in the tool register as approval-required, so the agent can prepare the action while a named person releases it after seeing the exact payload. Approval patterns are covered in human-in-the-loop design for agents, and the autonomy each action deserves is set out in the concept of bounded autonomy.

Policy checks at call time

Permissions checked once, at the start of a workflow, go stale. ASI03 describes the time-of-check to time-of-use gap: a user’s spending limit is cut mid-workflow, yet the agent completes the purchase on the old authorisation. Evaluate each consequential call when it happens, at a policy decision point outside the model, and fail closed if the decision service is unavailable. Policy engines such as Open Policy Agent, a graduated CNCF project since January 2021, and Cedar, accepted into the CNCF sandbox in October 2025, express these rules as code that can be reviewed, versioned and tested.

Permission-aware retrieval for RAG

Retrieval is a permission too. An agent answering from a shared index must filter results by the requesting user’s rights at query time, before ranking, or it will surface documents that user could never open. The approach is explained in permission-aware private RAG and the course on RAG access control; for separating whole departments, see department-specific agents with data isolation.

What MCP and A2A say about authorisation

Agents increasingly reach tools through the Model Context Protocol and other agents through Agent2Agent (A2A). Neither protocol decides what an agent may do. Both define how identity and tokens travel, and the access policy stays with you.

MCP, revision 2026-07-28. Authorisation is optional in MCP. HTTP-based servers that implement it act as OAuth 2.1 resource servers and must publish OAuth Protected Resource Metadata (RFC 9728), while clients must name the target server in authorisation and token requests with a resource indicator (RFC 8707). Servers must confirm that a token was issued for them and must not accept or pass on any other token, which rules out token passthrough. The guidance favours a minimal initial scope with step-up: a server answers an under-scoped request with an insufficient_scope challenge, and the client asks for more only when an operation needs it. Servers using the local stdio transport skip this flow and take credentials from their environment, one more reason to run them in a sandbox with nothing else within reach. An MCP gateway is the natural place to enforce these rules across many servers.

A2A, version 1.0, first released in March 2026. An agent publishes an Agent Card declaring how callers must authenticate: API key, HTTP authentication, OAuth 2.0, OpenID Connect or mutual TLS. Credentials are obtained out of band and sent in protocol headers, the server must authenticate every request, and authorisation is left to the implementation. Agent Cards can be signed with JSON Web Signature, and clients should verify a signature before trusting a card; a forged card is exactly how OWASP’s fake “Admin Helper” agent gains privileged work under ASI03.

RBAC, ABAC or ReBAC for AI agent access control

Most estates combine the three: roles decide which tools an agent may hold, attributes decide whether a particular call is allowed, and relationships decide which documents retrieval may return. MITRE ATLAS mitigation AML.M0026, for privileged agents, names RBAC and ABAC alongside least privilege.

Credential hygiene for agents

Credentials are the part of AI agent access management that attackers go after first, so keep the rules strict and few:

• Keep secrets out of prompts, system instructions, tool descriptions, memory, evaluation sets and logs. Anything placed in a prompt can be echoed back.
• Store secrets in a vault and fetch them at call time, each scoped to one tool and one environment.
• Prefer short-lived, audience-bound tokens, and rotate them without redeploying the agent.
• Scan prompts, outputs and traces for secrets before they are stored.
• Bind credentials to tools in the platform; never let the model choose which credential to use.
• Log that a credential was used, and by which run, but never its value.

Auditing, reviewing and revoking permissions

Log every decision. Each allow, deny and hold should be recorded with the policy version and the reason, next to the tool call it governed. That record is what lets an auditor test whether access control worked, and it is the subject of the companion guide on the AI agent audit trail.

Review on a schedule. DORA’s standards on ICT risk management, Commission Delegated Regulation (EU) 2024/1774, require access rights to be updated where needed and at least once a year, and at least every six months for ICT systems supporting critical or important functions. Agent grants deserve the same cadence, and grants that the logs show are never used should go.

Revoke on events. Withdraw or re-approve grants when an owner leaves, a tool’s schema changes, a model is replaced or an incident is declared. The offboarding checklist for AI platforms covers what to remove when people leave, including what agents and shared prompts still carry.

Test revocation. Remove a grant during a run and confirm the next call fails closed instead of continuing on a cached token.

AI agent permission matrix template

The matrix below is a fictional example for an insurer’s motor-claims triage agent. Each row is a grant a reviewer can approve, question or remove; replace the rows with your own agent’s tools.

Two rows carry most of the risk: the reserve write and the missing payment rights. A good matrix records what is denied as carefully as what is granted.

How VDF AI fits

Access in VDF AI is organised around roles. Every plan, and every on-premises deployment, includes role-based access control with roles, permission groups and per-role tool grants, and the MCP-powered tool registry in VDF AI Agents turns each grant into an explicit entry. Each agent’s tools are scoped to the least privilege its workflow needs; agents work inside their roles and per-role tool grants, with permissions checked at the moment a tool is called.

Before a step runs, a workflow can call permission-check: the answer is allow or deny together with the reason from your role-based policy, the evaluation happens inside your perimeter, and the check is recorded. Consequential steps can pause at a human approval gate, or at the Human Approval node in VDF AI Networks, while human-approval-request blocks until a person decides and records who it was. Each agent’s audit log ties every tool call and its arguments to the input and identity that started the run.

For on-premises sign-in, Microsoft Entra ID single sign-on is native: Entra security groups map onto roles, and users and groups are synchronised from the directory. Okta, Keycloak, any generic SAML or OIDC provider and LDAP connect through an SSO-aware reverse proxy, while in VDF AI Cloud single sign-on comes with Enterprise Cloud. The AI governance platform enforces directory identities and entitlements per agent and per tool, and the Trust Center describes deployment and security options.