At a glance
- An AI agent needs its own identity, scoped to the operations its job requires — not the human's or an API key's full access.
- A six-step design procedure, from inventorying actions to logging and review, turns a broad API into a narrow, auditable permission set.
- A worked example table maps one workflow's tools to scope, credential type, rate limit, approval requirement, and logging.
- Read, draft, and anything that writes or sends are different operations and belong on different identities, so a manipulated read-only call can't write, send, or post anything.
- System prompts aren't an enforcement boundary: OWASP ties excessive agency to manipulated or unexpected model outputs, so enforcement has to sit in the credential, the scope, and the approval gate.
An agent is a new identity
An AI agent is not a passive script. As OWASP puts it, "an LLM-based system is often granted a degree of agency by its developer – the ability to call functions or interface with other systems via extensions" [1]. That agency makes it useful, and makes its access a new design problem, distinct from a human user's account or a shared API key.
The starting principle predates AI systems entirely. NIST's own control statement is direct: "employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks" [2]. An agent calling a tool is exactly that kind of process, and needs the same discipline as any account — not looser rules because it's new.
- A human user identity is provisioned for a person — AWS defines them plainly: "human users, also known as human identities, are the people, administrators, developers, operators, and consumers of your applications" [3], who sign in and act with their own judgment.
- An agent's identity should be provisioned as a workload — scoped to its own job, never borrowing a person's session, password, or long-lived key; acting on someone's behalf uses a delegated, scoped token instead.
NIST's guidance extends this to processes: "the principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions" [2]. AWS enforces that at the credential layer: "when you're building on an AWS compute service, such as Amazon EC2 or Lambda, AWS delivers the temporary credentials of an IAM role to that compute resource" [3] — the agent runs on its own job-scoped credential.
Every agent design review has to decide: its own identity, or the user's? Its own — scoped narrower than any person's account, and revocable without touching the human who commissioned it. When it acts for a specific user, OWASP goes further: the downstream action should execute "in the context of that specific user, and with the minimum privileges necessary" [1], not just the agent's own scope.
The design procedure
Turning a broad API or admin console into an agent's actual permission set is a repeatable procedure, not a one-off judgment call.
- Inventory the actions
List every action the agent's job requires — each read, draft, write, and send — before checking what the target API exposes.
- Map each action to a minimal operation
For each action, find the narrowest operation the target system offers: a read-only endpoint instead of a general query.
- Separate read, draft, and write/send identities
Give reads one identity, drafts a second, and anything that writes, sends, or posts a third, separate identity, so a manipulated or compromised read or draft path can't act on its own.
- Scope the data each identity can reach
Restrict each identity to the records and fields its operation needs, not the whole table or every field.
- Add approval gates on high-impact actions
Route every send or irreversible action through a named human approver before it executes; lower-impact writes — a draft, a queued ticket — get a rate limit and a log instead, and no identity can approve its own request.
- Log every call and review the set on a schedule
Record who — which identity — did what, on which record, when, and revisit the permission set on a fixed cadence, not only when something breaks.
Illustrative example: one workflow's access design
The table below applies the procedure to one synthetic workflow: an agent that triages support tickets, looks up the customer and order, drafts a reply, and — only for a billing dispute — opens a ticket in a human-staffed queue. The roles, systems, and numbers are generic.
| Tool | Operation | Scope (records, fields) | Credential type | Rate limit | Approval, then logging |
|---|---|---|---|---|---|
| Customer record system | Read | One contact, by ticket ID; name and order history, no payment fields | Service identity, read-only scope | 60 reads/minute | No approval; record ID and requesting ticket logged |
| Order system | Read | One order, by order ID; status and shipping fields only | Service identity, read-only scope | 60 reads/minute | No approval; order ID logged |
| Ticket system | Draft (write, unsent) | A draft reply on the open ticket only; not sent to the customer | Service identity, draft-only, no send permission | 30 drafts/minute | No approval, draft only; draft hash and ticket ID logged |
| Email system | Send | The approved draft, to the ticket's requester only, one message | Write/send identity, send-only, post-approval | 1 per approved draft | Yes, a named reviewer approves before send; sender, approver, timestamp logged |
| Billing disputes queue | Write (create) | One ticket in the disputes queue; no payment access | Write/send identity, create-ticket scope | 10 creates/hour | No approval to create; a human decides the billing outcome after. Ticket ID and conversation logged |
Read and write identities
The ticket-system row and the email row above are the same message from a person's point of view, but two different identities from the agent's: one that can only save a draft, one that can send, invoked only after approval. Some SaaS and email APIs don't offer that distinction natively; when that's the case, separating draft from send has to be enforced by the caller, not the API.
NIST applies a related idea to privileged users, not to read versus send directly: it requires that "users of system accounts (or roles) with access to [Assignment: organization-defined security functions or security-relevant information] use non-privileged accounts or roles, when accessing nonsecurity functions" [2]. The analogy carries over: the identity that can send or post is a different, narrower account than the one that only reads and drafts, even against the same downstream system.
When the target system has no fine-grained scope to hand out — as can happen with an older SaaS API or an internal admin console — put a narrow service in front of it: a small internal API that exposes only the operations from the design procedure's second step, holding the one broad credential the underlying system requires. The agent calls that narrow service, never the broad one directly.
Approval and logging
Every send or irreversible action in the example table above routes to a named human before it executes; the draft and the new billing-disputes ticket are lower-impact writes, rate-limited and logged instead. OWASP recommends exactly this for high-impact actions: "utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken" [1].
The identity that proposes an action and the identity that approves it should never be the same one. If the agent, or the person who configured it, can also approve its own request, the gate is decorative, not real.
Every gated action also needs a record, not just a gate: NIST's guidance is direct — "log the execution of privileged functions" [2]. In practice, that means recording four fields for every write, send, or create:
- Which identity acted — the specific service identity, not "the agent" as a whole.
- What it did — the operation, matched to the procedure's minimal-operation list.
- Under whose approval — the named human reviewer, for anything gated.
- When — a timestamp on every logged call.
None of this can live in a system prompt. OWASP describes excessive agency as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction" [1] — its mitigation is direct: "implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not" [1]. The credential, scope, and approval gate are that enforcement; the prompt only shapes intent.
Reviewing access after launch
A permission set designed well at launch drifts: workflows change, and a credential scoped for a pilot often outlives it. NIST's own control enhancement treats review as part of the design, not an afterthought, and deliberately leaves the frequency up to each organization: "Review [Assignment: organization-defined frequency] the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges" and "Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs" [2].
A cloud platform's own tooling points at the same habit: access-history data can help identify the users, roles, permissions, policies, and credentials you no longer need, and refine your policies toward least-privilege permissions [3]. An agent's identity should go through that same review.
| Check | Why it matters |
|---|---|
| Scope still matches the job | Access accumulates from workflows the agent no longer runs; matching scope to the job removes what's left over. |
| Read, draft, and write/send are still separate identities | A merge usually happens quietly, when someone reuses a credential under deadline. |
| Approval gates route to a named human, not to the agent's own configuration | An approver who can also request the action isn't a control. |
| Logs capture identity, action, record, approver, and time for every gated call | A log missing one of these fields can't answer who approved this. |
| Rate limits match current volume, not the pilot's | A limit set for a small pilot is either a bottleneck or meaningless at scale. |
| Unused credentials and scopes from retired workflows are removed | An unused but still-valid credential is a live risk until it's revoked. |
When this design doesn't apply
This design procedure is worth the overhead when an agent's tool access is genuinely broad and touches records a customer or auditor would ask about. It's more than the job needs in a few common cases:
- The agent only reads from a system with fine-grained, per-action scopes and full audit logging already built in — you're configuring an existing control, not designing a new one.
- Every action the agent takes is reviewed by a person before and after, at a volume small enough that a shared identity and a simple log are still legible.
- The task is better served by deterministic automation — a fixed script or rules engine — since the actions never vary. Least privilege still applies, but there's no excessive-agency question to design around.
- The system is a one-off prototype with no production data behind it. Design the real permission set before the pilot touches real records, not after.
Frequently asked questions
How do you apply least privilege to agents?
Give the agent its own identity, scoped only to the operations its job needs — not the human's or a shared API key's full access. Inventory its actions, map each to the narrowest available operation, separate read from write and send, restrict the data each identity reaches, gate high-impact actions, and log and review the result.
Should an agent use its own identity or the user's?
Its own. An agent is a workload, not a human user: a distinct service identity, scoped to its job, that authenticates on its own credential rather than borrowing a person's session. When it acts for a specific user, though, OWASP recommends scoping that action to what the user is allowed to do, not just the agent's own permissions.
How do you restrict an agent when the API has broad scopes?
Put a narrow wrapper API in front of it, exposing only the operations the agent's job needs and holding the one broad credential the underlying system requires — the wrapper is where the rate limit, logging, and approval gate actually live.
Are system prompts enough?
No. A system prompt is an instruction, not an enforcement boundary. OWASP's guidance on excessive agency ties the risk to "unexpected, ambiguous or manipulated outputs" from the model itself — exactly what a prompt can't prevent. The tool call's credential, scope, and approval gate are what stop an unwanted action; the prompt only shapes what the agent tries to do.
How often should permissions be reviewed?
On a fixed schedule, not only when something breaks. NIST's own control leaves the exact review frequency organization-defined, so start with a quarterly review and tighten it for higher-risk tools; reassign or remove privileges whenever they no longer match the role, and treat an unused but still-valid credential as a risk to revoke, not ignore.
Related reading
- The next step: AI agent implementation covers how a system like the one above is scoped, tested, and handed over.
- For a system that can't be swapped out at all, automating legacy systems without migration covers the integration options.
- Not every workflow needs an agent — when not to use an AI agent covers when simpler automation is the better call.
- To rank this workflow against other automation candidates, see the 360° AI Blueprint.
- To adapt the table above to your own tools, start from the blank AI agent permission matrix template.
Sources
- OWASP GenAI Security Project, "LLM06:2025 Excessive Agency" (OWASP Top 10 for LLM Applications, retrieved 2026-09-30) (accessed 2026-09-30)
- NIST, "Security and Privacy Controls for Information Systems and Organizations", SP 800-53 Rev. 5 (September 2020), Control AC-6 (accessed 2026-09-29)
- AWS, "Security best practices in IAM" (IAM User Guide, retrieved 2026-09-29) (accessed 2026-09-29)
More in Agent governance
Build vs. Buy AI E-Commerce Back Office Automation: Point Tools vs. an AI Implementation Partner
Build vs buy AI e-commerce back office automation: a six-factor decision table comparing packaged tools with an AI-agent layer, plus how to scope one workflow.
Ecommerce OperationsBuild vs. Buy AI for the Energy and Utilities Back Office: AI Agents vs. Entrenched Land, JIB and Billing Software
Build vs buy AI for the energy and utilities back office: a five-factor decision table comparing land, JIB and billing software with an AI-agent layer.
Utilities and Energy CompaniesAI Agent Approval Gates for Finance: A Role and Action Matrix
AI agent approval gates for finance: which actions an agent may do, suggest, or never touch, who approves each one, and what evidence to keep.