AI Agent Access Control: Scope Permissions Where Agents Act

What changes when software acts as an agent

AI agent access control is the set of mechanisms that decide what an agent can read, change, and trigger across connected systems, enforced at the moment each action is attempted. A prompt that says "never touch production" is a request. A policy check that returns deny is a control. The difference between the two is the whole subject of this piece.

An agent is not one API call. It plans, calls a tool, reads the result, and calls the next tool, sometimes dozens of times for a single request. Auth0's walkthrough of access control in the era of AI agents makes the practical consequence plain: an agent's effective role can shift from moment to moment, so a static role either gets hopped constantly, which floods the logs, or gets inflated into one oversized role that never needs to change. Neither survives an audit.

The harm that worries a CISO is rarely one forbidden call. It is a chain of calls that were each individually permitted. A read of a contract, a lookup in a billing system, and a send from a shared mailbox are three legitimate grants. Together they are an external disclosure no one approved. OWASP's LLM Top 10 names the underlying condition excessive agency, and the project's Agentic Security Initiative and Agent Control Standard both start from the premise that autonomous, multi-step work needs transparency and control that a chat interface never required.

Not every agent is fully autonomous, and this argument does not require it. It applies the moment a model can call a tool that has side effects.

The access-control design for agents

NIST's AI Risk Management Framework organizes risk work into four functions: Govern, Map, Measure, and Manage. It does not prescribe an agent permission model, and nobody should pretend it does. What it gives a security leader is the vocabulary to assign accountability, and accountability is where access control starts. Someone owns the agent's identity, someone owns the policy, and someone owns the approval. The Generative AI Profile extends that to the specific risks of generative systems.

Five controls make that ownership concrete. The table shows where each is enforced and what evidence it leaves.

| Control | Enforced where | Evidence to retain | Failure it limits | |---|---|---|---| | Identity | Identity provider and credential issuance | Agent ID, task ID, delegating user, credential lifetime | Shared credentials that make every action look like the same actor | | Scope | Credential grant and tool inventory | Granted scopes, resources reachable, expiry | One compromised token reaching everything the platform can touch | | Per-action authorization | Policy decision at each tool call | Resource, operation, inputs context, allow or deny, policy version | Chained permitted actions producing a prohibited outcome | | Approval | Workflow gate outside the model | Proposer, approver, the exact action approved, timestamp | An agent authorizing its own consequential action | | Logging | Where the action executes | Full record of request, decision, side effect, result | Reconstruction gaps after an incident |

Give each agent and task a bounded identity

An agent should not borrow a human's session and should not share a service account with six other agents. Each agent gets its own identity, and each task gets credentials that are short-lived and narrow. Auth0's guidance is to start agents read-only and grant elevated permissions only through an audited step. That is the right default.

The question people ask about service accounts has a precise answer. A service account is acceptable as the carrier of an agent identity when it is task-specific, scoped to the minimum resources, and tied to a delegating human whose context travels with the call. A service account that holds standing write access to a system of record on behalf of every user is a master key with a friendly name.

Check every read and write at the action boundary

Three categories of action deserve different treatment, and a policy that cannot tell them apart will be either too loose or unusable.

A read touches data. Reading an employee file is a read, and the control question is whose data and for whom. Cerbos's piece on permission management for AI agents makes a sound point here: filtering has to happen before retrieval, so the model never sees documents the user could not have opened.

A write changes a system of record. Updating a ledger entry is a write, and the control question is whether this agent, for this task, may mutate this record, and whether the change can be reversed.

An external side effect leaves the building. Sending an email to a customer is a side effect. It cannot be recalled, and it carries the company's name. It earns the strictest check of the three.

Auth0 states the principle in one sentence worth taping to a wall: the model can propose an action, but the policy, not the model, decides whether it runs. A prompt rule cannot stand in for that check. A prompt is part of the model's input, and the model's output is exactly the thing being authorized. Context windows get flooded, instructions get injected, and a rule held in text is only as strong as the model's compliance on that run.

Separate proposing from approving

Permission to prepare an action is not authority to complete it. An agent can be fully entitled to read invoices and draft a collections note while having no authority to send it, because sending is a commitment made in the company's name. Collapsing those two grants is how an agent ends up approving its own work.

Set the line by consequence. Low-impact, reversible actions can run on policy alone. Anything that moves money, contacts an outside party, deletes data, or changes access should require a named human approver, and the approval should bind to the exact action, not to a general intent. An approver who clicks "continue" on a summary has approved a summary. Auth0 recommends human confirmation for payments and deploys, and per-identity rate limits and budgets. Add escalation as a first-class outcome: when the policy cannot decide, the safe result is a queue item for a person, not a retry with broader scope.

A worked access-control example: invoice reconciliation

This is an illustrative design, not a customer deployment. It shows where each control sits in a workflow that crosses three systems.

The task: reconcile a vendor payment against an invoice and contract terms, then follow up on a discrepancy.

1. The task starts. The platform issues an agent identity and a task credential, 20 minutes of life, bound to the finance operator who requested it. Scope covers read on invoices and contracts, write on a draft table, nothing else.
2. The agent reads the invoice and the contract. Each read passes a policy check against the resource and the delegating user. Both are logged with the decision.
3. The agent reconciles amounts and finds a mismatch of a kind the contract allows for. This is judgment. It decides the discrepancy is a late-fee dispute and drafts a collections note into the draft table.
4. The workflow reaches a gate. The note is an external side effect and the ledger adjustment is a write to a system of record. Neither is in the agent's scope. The agent submits a proposal containing the exact note text and the exact adjustment.
5. A named approver in accounts receivable reviews the proposal, edits the note, and approves. The approval record binds to that content.
6. A separate execution step, running under its own narrowly scoped credential, sends the note and writes the adjustment. Both actions log the approver, the proposer, the result, and the credential used.
7. The workflow closes. A verification step confirms the ledger entry matches the approved adjustment and records the final state.

Notice what the agent never held. It never had send authority. It never had ledger write authority. A prompt injection in the invoice PDF could change the note the agent drafts, but the approver sees the note, and the credential that sends it does not belong to the agent.

What deterministic apps change

Steps 2, 4, 6, and 7 above are the same on every run. Only step 3 needs a model. That ratio is typical, and it points at a design choice about where the repeatable parts execute.

If the agent re-derives the workflow on each run, the permission boundary has to be re-established by the model each time too. The agent decides again which tools to call, in what order, with which arguments, and every one of those decisions is a fresh chance to drift. A reviewer looking at March has to reason about what the model happened to do.

When the repeatable parts live in an app, they are code. The app is written once and holds its own database, its files, and its logs. The agent invokes it. Its credentials are fixed to the app's actual needs, so the grant is narrower than the open-ended tool access an unconstrained agent needs. The same checks fire in the same order, and the same fields are written to the log on every run. A reviewer can read the code, not infer behavior from transcripts. This is what we mean by the app layer: the deterministic software where work executes and state lives, kept distinct from the agent layer that decides what to do and builds the apps.

What this does not solve. Deterministic app execution narrows repeated behavior. It does not eliminate prompt injection in the judgment step, credential compromise, a badly written policy, or the need for human oversight. Code written by an agent still needs review before it earns standing trust, and the model's reasoning at the exception points remains probabilistic. This article also does not cover agent evaluation or data-loss prevention for model outputs, which are separate problems.

What to audit and review

Logs do not prevent incidents. They make an incident answerable. Retain enough that a reviewer can reconstruct what happened without asking the agent.

For every action, keep the agent identity and the task it was running, the human it acted for, the tool and resource touched, the operation, the policy decision with the version of the policy that made it, any approval with the approver and the proposal approved, the result, the credential scope in force, and a timestamp. Add the app version for any action taken through a deterministic app, so a change in behavior can be tied to a change in code.

A useful test for a vendor or an internal platform: pick an action from last month and ask for five answers. Which identity acted. On whose behalf. What policy allowed it. Who approved it. What side effect landed. If any of the five requires interviewing an engineer, the audit trail has a gap. Our companion pieces on governance at the point of action, the AI agent security threat model, practical AI agent guardrails, and enterprise AI governance cover the surrounding controls.

What we're building at Major in response

We hold a position that some security teams will resist: an access policy that lives only in an agent's prompt, or only in a central policy document, is not a control. It becomes one when it is applied where the work executes.

Major is the enterprise platform where agents build the software they run on. When an agent works out how to handle a repeatable part of a task, it builds an app for that part. The app carries a managed database, storage, and logs, runs in deterministic code, and sits behind the platform's SSO, permissions, and audit. The agent then runs the app instead of reasoning through the step again. Reason once, run forever. For access control, that means the repeatable stretch of a workflow has a fixed shape, a scoped grant, and a log written by the code that did the work, so a person can inspect it and an auditor can replay it.

The model stays in the loop for judgment and exceptions, and people stay in the loop for approval of consequential actions. We do not claim the app layer removes the need for either. We claim it shrinks the surface where a probabilistic system holds authority, and that a smaller surface is one a security team can actually review.

If you are designing agent access today, draw the workflow as bounded steps first, mark which ones need judgment, and give every other step to code with its own credential. Then ask where the approval sits.

To see how Major scopes credentials and writes audit logs at the point where an agent acts, see how Major governs agent actions in the apps they build.

Related articles

• Agent Observability: What Deterministic Apps Change
• Enterprise AI Strategy: Build for Repeatable, Governed Work
• LLM Observability: What to Instrument When the Work Is a Black Box