AI Agent Permissions: How to Limit What an Agent Can Actually Do

AI agent permissions are the identity, access, and approval rules that decide what an AI agent can read, change, and send without a person stepping in. The question comes up when an agent connected to email, a CRM, or a payment system is about to go live, and someone has to say which records it may touch and which actions wait for a human.

In IBM's 2026 Cost of a Data Breach report, which studied 602 organizations hit by a breach, roughly one in five reported an AI-related breach, and 92% of those lacked proper AI access controls. An agent with too much access can send, delete, or pay at machine speed under an identity your systems trust.

We wrote this guide for CISOs, heads of IT and security, and the COOs and business owners who sponsor an agent rollout and answer for it to auditors, customers, and the board.

Key takeaways

• Decide five things for each agent. Settle its identity, the systems it can reach, the actions it may take, which of those need a person, and how long each grant lasts. Write them down before the agent connects to anything.
• Match the access model to whom the agent acts for. An agent working for a user stays inside that user's rights through delegation. An agent working for the company gets its own role, a named owner, and a place in your access reviews.
• Grant by action type. Reading, drafting, editing, sending, deleting, paying, and changing permissions each carry their own default, from standing access to approval each time to never. Our matrix gives a starting point with the evidence to keep.
• Keep the limits right after launch. Review agent access on a schedule you set, revoke it when the job or the user goes, protect the logs from the agent, and reopen approval when the model, tools, or owner change.

What an AI agent's permissions control

An AI agent's permissions are the decisions that fix who the agent is when it acts and how far it may go without a person. They apply least privilege, which the NIST glossary defines as restricting "the access privileges of users (or processes acting on behalf of users) to the minimum necessary to accomplish assigned tasks".

Each agent needs a written decision on five points.

• Identity: the agent's own account or credential, kept apart from any employee's login, so the logs can tell its actions from a person's.
• Reach: the systems, data sets, and outside destinations the agent can connect to, each one named in the grant.
• Actions: what it may do on each system, from reading and drafting up to deleting, paying, or granting access to others.
• Autonomy: whether each action runs on its own, waits for a named person's approval, or stays off limits to the agent.
• Duration: whether a grant is standing or issued per task as short-lived credentials that expire when the work ends.

OWASP's Top 10 for LLM Applications 2026, a ranked list of the most critical security risks in applications built on large language models, puts excessive agency third, under the code LLM03. OWASP defines it as the weakness that lets an LLM-based system take damaging actions. It traces the weakness to too much functionality, too many permissions, or too much autonomy. Access control enforces all five decisions at the moment the agent acts.

Why AI agents need different permissions than human users

An agent is a non-human identity that picks its next step while it works. That breaks assumptions built into access rules for employees. Four differences matter most for permissions.

• Actions chosen at run time: a person's access fits a known job. An agent's next action depends on what it has just read. NIST's National Cybersecurity Center of Excellence (NCCoE) raised this as an open question in its draft concept paper, asking how to limit an agent "when its required actions might not be fully predictable when deployed". The question is still open, and the section on what the standards have not settled shows where that work stands. Until it closes, attach limits to each class of action, as the permission matrix below does.
• Content written by strangers: an email, a ticket, or a web page can carry instructions that the agent then carries out with its own access. In this confused deputy pattern, a person with little access steers an agent that holds more. Our practical threat model for securing AI agents walks through how those attacks reach an agent.
• Permissions gathered along task chains: when one agent hands work to another, rights can pile up along the chain. Commenters in NCCoE's summary of comments warned that agents "will aggregate authorizations as task chains are executed", weakening separation-of-duties protections.
• Misuse that looks legitimate in the logs: a joint guide on careful adoption of agentic AI, co-authored by CISA, NSA, and four allied agencies, describes a compromised procurement agent used to modify contracts and approve payments. Because it acted under a trusted agent identity, "the system produces audit logs that appear legitimate and delay detection".

AI agent access control models for delegated and autonomous agents

The right access control model depends on whom the agent acts for. A delegated agent works under a user's authority, an autonomous agent holds a role of its own, and both need the allow-or-deny decision to run in code outside the model.

Delegated agents that act for a user

A delegated agent, such as an assistant that drafts replies from a manager's inbox, uses delegated access and stays within the rights of the person it serves. RFC 8693, the OAuth token exchange standard, separates two setups. With impersonation, the agent "is indistinguishable from" the user, so the audit trail cannot tell the agent's actions from the person's. Delegation lets the agent keep "its own identity", and an "act" claim in the token names the acting party, which is why we recommend delegation. OWASP adds that chained workflows should "preserve the original user context and authorization scope".

Autonomous agents with their own role

An autonomous agent runs on a schedule or an event, such as a nightly reconciliation job, and acts for the organization with no user behind each request. It needs a role sized to that job and a named person who owns the role. The joint guide asks developers to build each agent "as a distinct principal". Treat the role like any service account. A point of focus under SOC 2's CC6.3 covers periodic review of access roles, including system and service accounts.

RBAC, ABAC, and ReBAC for AI agents

For agents, combine three types of rules. Role-based access control (RBAC) attaches permitted actions to roles, in NIST's definition. Attribute-based access control (ABAC), in the same glossary, decides on attributes of the requester and of the object.

Relationship-based access control (ReBAC) stores permissions as relations between users and objects, the model Google described for its Zanzibar authorization system. In practice AI agent RBAC sets the baseline with a role such as "invoice reader", attributes narrow it to certain data classes or hours, and relationship rules decide which shared files a delegated agent may open for its user.

Where the allow-or-deny decision is made

Keep the decision to allow or block an action in ordinary code that sits outside the model, where a prompt cannot change it. OWASP's 2026 list calls this complete mediation, meaning each request the agent sends to another system passes a policy check first. The check can live in the tool, in a separate policy service, or in the target system.

Commenters to NIST agreed that "deterministic policy and policy enforcement" are "essential to security". A policy check returns the same answer to the same request every time. The model can add context on top, as the commenters suggested, and the policy gives the final answer.

An AI agent permission matrix by action type

A permission matrix sets a default grant for each class of action an agent can take, with the approver and the evidence for each. The matrix follows the joint guide's advice to classify agent actions "by potential impact, likelihood and reversibility" and its call for just-in-time credentials on high-impact work. It also follows OWASP's graduated enforcement, which auto-approves reversible steps and routes irreversible ones to human review.

A per-task cell means just-in-time access that expires with the task. The agent never changes permissions, credentials, or security settings and never deletes or alters logs, under any approval. A request to do so is denied or held for a human, who acts with their own access outside the agent. SP 800-53 AC-6(1) reserves security functions for named individuals or roles. Table 1 is our recommended starting point.

Table 1. Default grants by type of agent action

Source: BD Emerson recommendation based on the CISA and NSA joint guide, OWASP LLM03:2026, and NIST SP 800-53 AC-5 and AC-6(1); read October 2026.

What NIST, SOC 2, and OWASP expect from agent permissions

Controls written for people and service accounts already reach AI agents, and OWASP and the joint guide add detail written for agents. In a SOC 2 Type 2 examination, the service auditor tests controls against the AICPA Trust Services Criteria. Of these, CC6.2 and CC6.3 fit agent access directly. The first asks the entity to register and authorize users before issuing credentials, and its points of focus extend that authorization to credentials of systems and software. The second governs how access is granted, changed, and removed, and its points of focus add a periodic review of roles.

The other frameworks differ in status, which matters when you cite them to an auditor or a customer.

• NIST SP 800-53: the federal catalog of security and privacy controls, which supports the programs federal agencies run under the Federal Information Security Modernization Act (FISMA). Outside government, its AC family gives agent limits a precise vocabulary, from dividing duties in AC-5 to logging privileged functions in AC-6(9).
• OWASP's two lists: the 2026 LLM list files excessive agency under LLM03. Its Top 10 for Agentic Applications adds ASI03, Identity and Privilege Abuse. It also asks organizations to apply "Least-Agency" and avoid autonomy an agent does not need.
• The joint guide: non-binding guidance from CISA, NSA, and their partners.
• Agent Control Standard: OWASP's pre-1.0 wire specification for runtime control, known as ACS. Its release 0.1.4 came out on October 16, 2026, and pre-1.0 releases may still change its core baseline.

None of these documents is a law. Under FIPS 200, SP 800-53 is required for federal information systems other than national security systems. The OWASP documents and the joint guide are recommendations. Table 2 sets out what each framework asks and how it applies to an agent.

Table 2. What current frameworks ask of agent access

Sources: AICPA TSC CC6.2 and CC6.3; NIST SP 800-53 Rev. 5; OWASP LLM03:2026, ASI03, and ACS; the CISA and NSA joint guide; read October 2026.

What the standards have not settled yet

None of the NIST or AICPA documents in Table 2 sets requirements written for agent permissions. NIST's Center for AI Standards and Innovation (now CAISSI) launched its AI Agent Standards Initiative in February 2026, and our article on the NIST AI Agent Standards Initiative covers the program. The NCCoE project on agent identity and authorization ran a formal comment period on its draft concept paper from February 5 to April 2, 2026, and now reviews feedback on a rolling basis.

A summary of more than 600 comments, published September 29, 2026, names a draft project description as the next step. Commenters found "no consensus on the exact means" of identifying agents and no broadly accepted standard for signed intent. The overwhelming majority favored building on existing standards. Until that work produces guidance, hold your team to the controls in Table 2.

How to limit AI agent access

Before an agent goes live, seven steps set its limits, and each leaves a record you can show an auditor or a customer's security review.

1. Inventory every agent and what it can reach today

Start with the agents you already run, including pilots and the tools teams connected on their own. For each, record the owner, the credentials it uses, and the systems and data it can reach, in one list that the later steps work from. IBM's 2026 report found that fewer than half of the organizations it studied are actively securing non-human identities. Expect to find agents that nobody registered. OAuth app grants in Microsoft 365 or Google Workspace are one place to find them, as our guide to shadow AI explains.

2. Write each agent's job and map its tasks to the matrix

Describe the agent's job in a few sentences, then break it into tasks and the tool actions each needs. Place each action in a row of Table 1 and copy its default grant to build a task map with one row per task. Any function the job does not use goes on a removal list for that tool. OWASP's example is a mailbox summarizer that only needs to read mail, so its tool should not contain functions for deleting or sending messages.

3. Register each agent's credentials before it goes live

Give the agent a credential of its own before launch, authorized by the owner of each system it touches. A CC6.2 point of focus extends that authorization to credentials for systems and software. Record the delegation mode for agents that act for users, and keep every agent off shared accounts and personal admin logins. The joint guide adds a trusted registry that binds each identity to its role, with access denied to any agent missing from it. File the approval as the agent's credential record, with its owner, scope, and expiry date.

4. Scope permissions to actions on named resources

Write each permission as an action on a named resource, such as read access to invoices in the accounts payable folder. The security guidance of the Model Context Protocol (MCP) lists wildcard or omnibus scopes such as "*", "all", and "full-access" among common mistakes. It recommends a minimal initial scope, with elevation when a privileged operation is first attempted.

You can set MCP tool permissions per agent. Where the MCP server uses OAuth scopes, each agent gets its own scopes for the tools its job uses. Scopes start minimal, widen one operation at a time, and never include a wildcard or full-access scope. Elevation stays within the Table 1 rows granting the agent access and never reaches the rows marked Never. OWASP likewise asks for tool permissions limited "to the minimum necessary" on downstream systems. Our guide to MCP security covers per-server credentials and the confused deputy risk.

5. Re-check permissions when they change mid-task

Check the agent's current permissions at every call. OWASP's agentic list files the gap under time-of-check to time-of-use (TOCTOU) in agent workflows. It states that "Permissions may be validated at the start of a workflow but change or expire before execution". In its example, a procurement agent keeps buying on an old approval after the user's spending limit was cut. The joint guide warns that entitlements checked only at startup leave "a stale allow decision" for an attacker.

Run the check in the policy engine, fail closed when it cannot answer, and cap a run's cumulative value, as OWASP suggests.

6. Decide who sets the approval gates and bind each approval to one action

The joint guide places the choice of when human approval is required with system designers or operations teams. Put a human-in-the-loop gate on each matrix row marked approval each time, and name the approver. An approval should cover one action with its parameters, such as the payee and the amount, and expire once that action runs.

Commenters to NIST warned of consent fatigue and recommended reserving human approval "solely for high-impact, high-risk actions". To set the threshold on each gate, start from the authority the person who does that work today already holds. Our article on agentic AI in insurance applies this to decisions to bind a policy, pay a claim, or decide coverage. It sets the thresholds by line of business, policy limit, and dollar amount.

7. Start with one low-risk workflow and widen access with evidence

Launch with one workflow whose actions can be undone and whose data is low risk. The joint guide recommends "phased deployment with progressively increasing access and autonomy". A narrow first scope limits the blast radius if the agent misbehaves. Widen access one matrix row at a time, and keep a dated record of each change with the evidence behind it, such as error rates and approval history. Our AI implementation services run pilots this way, with a bounded cohort behind an evaluation gate and security controls in place from the first call.

How to manage AI agent permissions after launch

After launch, the job is to keep the limits from the seven steps accurate as people, tools, and models change. Five duties cover it, each tied to a control in Table 2.

Name an owner for every agent

Give each agent a named owner who answers for its access, approves changes to it, and takes the first call when it misbehaves. A CC6.2 point of focus bases credential creation on authorization from the asset owner. Ownership matters more as agents hand work to other agents. Commenters to NIST pointed to accountability gaps "if downstream actions cannot be reliably connected back through the call chain to the responsible human or institution". When an owner leaves, reassign the agent the same day or suspend it.

Review and recertify agent access on a schedule

Agents belong in your access reviews, and a CC6.3 point of focus extends those reviews to system and service accounts. Run them on the same cycle as other privileged accounts, or more often for agents that can write, send, or pay. SP 800-53 AC-6(7) leaves the frequency to the organization and asks for privileges to be reassigned or removed when the need is gone. In each review, the owner confirms or drops each grant. Record the outcome as a recertification with the reviewer, the date, and what changed.

Revoke access when the job or the user goes

Remove an agent's credentials when its job ends, its owner leaves, or the user it acts for loses access. CC6.2 asks for credentials to be removed when access "is no longer authorized". For delegated agents, revoke the delegated tokens when the user's own rights change. Test revocation in advance by revoking one agent's credentials, confirming its tokens stop working within the time you expect, and logging the result.

Keep logs the agent cannot change

Log each privileged action with the identity the agent used, the user it acted for, and the approval behind it. SP 800-53 AC-6(9) asks for logging of privileged functions. The joint guide recommends isolating agents in enclaves "with no write access to logs" and quarantining requests to delete logs for human review. Under our matrix, the agent never deletes or alters a log, and a human who decides a deletion is warranted carries it out with their own access.

Apply separation of duties from AC-5 as well. The agent never approves its own action, and whoever administers its access does not also administer its audit trail.

Reopen approval when the model, tools, or owner change

A new model version, a new tool, a new data source, or a new owner can change what an agent does with the same permissions. Treat each as a change that reopens the agent's approval. OWASP's agentic list asks you to monitor when an agent gains new permissions indirectly through delegation chains. The joint guide asks operators to log identity and privilege changes and "audit regularly for drift, impersonation or misconfiguration". Re-run the step 2 mapping for the changed agent before it goes back to work.

AI agent permissions checklist

Run these tests before launch and at each access review. Each has a yes-or-no answer, and the evidence that proves it sits in parentheses.

Before launch

• Each agent has its own credential, approved by the owners of the systems it reaches (credential record).
• A named owner is on record for the agent (ownership register).
• Tasks map to rows of the permission matrix, and unused tool functions are removed (task map).
• No grant uses a wildcard, "all", or full-access scope (scope list).
• Delegated agents carry tokens that name both the user and the agent (token sample).

At run time

• Permissions are checked at each call by policy code outside the model, which fails closed (policy configuration).
• Approvals cover one action with its parameters and come from a named approver (approval log).
• Cumulative caps stop a run that passes its value or volume limit (cap settings and alerts).
• Every agent request to change permissions, credentials, or logs is denied or quarantined, and any change is made by a human with their own access (denied-request log).
• Privileged actions are logged with the agent identity, the user, and the approval (log sample).

After launch

• The agent has no write or delete rights on its own logs (log permissions).
• Reviews ran on the date set, with each grant confirmed or removed (review record).
• Revocation was tested, and tokens stopped working within the expected time (test record).
• Changes to the model, tools, or owner reopened approval before the agent resumed work (change log).
• Any expansion of access has a dated record with the evidence behind it (expansion record).

Conclusion

Inventory the agents you run, fill in a permission matrix for each one, and set a date for the first access review before the next agent goes live. Our enterprise AI consulting sets up access controls, logging, and human checkpoints before AI touches production. It widens an agent's autonomy one workflow at a time as the evidence comes in.