An agent that can read a support case, query billing records, and send email has several routes to expose customer data. AI agent least privilege limits those routes through enforceable permissions across tools, data, and individual workflow steps.
Your agent needs enough authority to complete its task without inheriting every permission its operator holds. Authorization outside the model makes that boundary reliable, even when retrieved content contains malicious instructions.
For agentic AI, start by mapping what each workflow step can read, change, and release.
Key Takeaways
- Give each agent a distinct workload identity, and limit delegated access to the intersection of user entitlements, agent permissions, and task policy.
- Scope permissions to each workflow step, resource, action, time, and destination; preparing an action should not automatically grant permission to commit it.
- Enforce authorization outside the model at the tool or API boundary, and keep credentials in a trusted runtime rather than prompts or conversation history.
- Treat retrieved content and connected tools as untrusted, and use narrow approvals for consequential actions such as payments, external transfers, and destructive changes.
- Govern agents throughout their lifecycle by reconciling inventory with observed activity, testing denied actions and failure cases, and reviewing boundaries after changes.
What AI agent least privilege must restrict
AI agent least privilege gives an agent only the authority required for its current task. That includes which tools it can call, which records it can access, and which actions it can execute.
The boundary also includes time and destination. Permission to read an invoice shouldn’t automatically include permission to email it externally or retain it in shared memory.
The OWASP Top 10 for LLM applications identifies excessive agency as a security risk for AI agents. Narrow permissions limit the blast radius when a mistaken decision or successful prompt injection occurs.
Static role-based access control remains useful for baseline permissions. However, a role such as “support automation” rarely captures the current case, tenant, workflow stage, and approved recipient.
Use roles as one part of a governance framework and an upper bound, not a complete authorization decision. With zero trust access control, apply task-level restrictions at runtime to prevent overpermissioning. A tool appearing in the agent’s menu doesn’t establish permission to use it.
A read-only agent can still exfiltrate data if another tool lets it send the retrieved information to an unrestricted destination.
Separate agent identity from user authority
Give the agent a distinct workload identity
A human identity identifies the person requesting work. An agent identity identifies the software acting on that request. Treat agents as non-human identities, and keep both identities in the authorization and audit context.
Good identity management starts by registering each production agent with an owner, purpose, permitted environments, and approved tools. Give sensitive connectors separate credentials rather than sharing one service account across unrelated workflows.
For background automation, define a service-owned authority boundary. For delegated work, preserve the initiating user’s identity alongside the agent identity.
This distinction supports revocation and investigation. Disabling one compromised agent shouldn’t require disabling every employee who used it.
Bound delegated access by both identities
An agent acting for a user should receive the intersection of user entitlements, agent permissions, and task policy. This is fine-grained authorization. A finance employee’s payment authority doesn’t automatically belong to an invoice-processing agent.
RFC 8693 defines OAuth token exchange and distinguishes delegation from impersonation. Its JWT act claim can identify the acting party, although implementation support varies.
Where supported, use authorization-server-mediated exchange to obtain a resource-specific token for ephemeral access. A short-lived grant doesn’t by itself guarantee revocation or security.
Also bind the task context to trusted application state. Tenant identifiers, record ownership, and approval status must come from verified systems, not model-generated arguments.
Design permissions around the workflow
Start with a workflow map rather than a broad agent role. For AI agents, map every external effect, including messages, file exports, database updates, and persistent memory writes. This prevents overpermissioning.
For a Salesforce case-triage deployment, scope reads to the assigned case and authorized customer records. Permit reply drafting separately from sending. For SAP invoice processing, separate invoice extraction, purchase-order matching, and payment release.
These boundaries translate business steps into enforceable controls.
| Workflow step | Allowed authority | Explicit restriction |
|---|---|---|
| Retrieve a support case | Read assigned case and approved knowledge | No unrestricted customer export |
| Draft a response | Create a draft tied to that case | No external sending |
| Match an invoice | Read relevant purchasing records | No supplier bank-detail changes |
| Release a payment | Execute an approved transaction | Approval bound to amount and recipient |
Use access scoping and separate connector permissions for each workflow step.
The important distinction is between preparing an action and committing it.
Apply equivalent restrictions to data retrieval. Use fine-grained authorization for document and row-level access before content enters the model context. Filtering the final answer happens too late for data security.
The enterprise RAG security checklist covers identity-aware retrieval and connector scoping. Those controls matter because a narrowly scoped tool can still query an overexposed data store.
For this workflow, record access and tool execution need separate checks.
Enforce runtime access outside the model
Put a policy check before every side effect
Treat the model’s requested action as untrusted input. A tool adapter should validate its schema, resolve the target resource, and apply fine-grained authorization before execution.
These authorization layers provide policy enforcement outside the model. Runtime least privilege evaluates each requested action against the current task state, resource, and policy. Keep these checks at the tool execution boundary.
A practical execution path is:
- Authenticate the agent and verify any delegated user context.
- Load the task’s trusted tenant, resources, workflow state, and expiry.
- Evaluate the requested action and arguments against policy.
- Acquire a narrowly scoped credential and execute the permitted operation.
- Record the decision, outcome, and resulting state transition.
Enforce this path at the API or tool boundary. A model instruction such as “never modify customer accounts” cannot replace a write-denial policy.
Keep credentials short-lived and away from prompts
Hold secrets in a credential broker or trusted runtime, not in conversation history. Give the agent tool results without exposing the credentials used to obtain them.
Use short-lived, broker-issued grants for ephemeral access. Restrict them by resource audience, operation, and lifetime where the target system supports those controls. Otherwise, enforce equivalent restrictions through an adapter with narrow upstream credentials.
Manage issuance, refresh, expiry, and revocation as part of the token lifecycle. Short-lived tokens reduce the exposure window, but expiration alone doesn’t provide immediate revocation. High-risk operations may need fresh policy checks, token introspection, or another server-side denial mechanism.
Bind queued actions to task expiry. For long-running workflows, refresh access through a controlled broker rather than granting the model persistent refresh authority.
Keep authorization caches brief and scoped. Caching improves latency, but stale decisions can preserve access after an entitlement change.
Contain prompt injection and MCP exposure
Treat retrieved content as untrusted data
Indirect prompt injection can reach AI agents through documents, websites, email, and tool responses. An instruction embedded in an invoice can request an unrelated export or change the payment destination.
The OWASP AI Agent Security Cheat Sheet recommends task-required tools, resource-specific permissions, and explicit authorization for sensitive actions.
Separate trusted workflow instructions from retrieved material, but don’t treat that separation as a complete defense. Enforce recipient allowlists, export limits, and network egress policy outside the model.
Also isolate memory by tenant and workflow. Otherwise, sensitive information retrieved under one authorization context can appear in another agent session.
Constrain MCP servers and third-party plugins
Model Context Protocol standardizes tool integration; it doesn’t make every connected tool trustworthy. Each server introduces executable capabilities, credentials, dependencies, and returned content.
Allowlist approved servers and tools. Set connector permissions, use separate scoped credentials per server, validate arguments, and review tool-definition changes before deployment. Treat descriptions and schemas as untrusted inputs too.
The enterprise MCP security checklist expands these identity and connector controls.
Pin approved definitions or detect unexpected changes. However, schema pinning doesn’t establish that a server’s implementation is safe. Continue checking authorization at the downstream service and restrict the server’s network access.
Add approvals without blocking routine work
Human-in-the-loop oversight works best at consequential boundaries. Require approval for payment release, external data transfers, destructive changes, and privilege escalation. Routine authorized reads usually don’t need an approval queue.
For a GitHub code-assistance workflow, an agent can prepare a pull request while repository controls govern merging. Keep production deployment authority separate from code-generation access.
Human-in-the-loop approval must authorize the exact proposed action. Show the destination, affected resources, amount where relevant, and expected side effects. If the agent changes those details, require a new approval.
Bind approval records to trusted identifiers or an action digest. Any ephemeral access tied to approval should expire when its execution window closes. Recheck permissions at execution time, since approval can become stale and doesn’t grant broader permissions.
Retries need equal care. Use idempotency controls for payments, messages, and other side effects so a timeout doesn’t trigger duplicate execution.
This is a risk management tradeoff: more approvals reduce autonomous throughput and can cause reviewer fatigue. Narrow the approval surface instead of asking humans to approve every tool call. When an action cannot be safely bounded, pause it for review.
Discover, test, and govern deployed agents
Reconcile the inventory with observed activity
Start with registered agents, then compare that inventory against OAuth applications, service accounts, connector configurations, CI/CD deployments, and observed API activity. Investigate non-human identities calling tools without a known owner.
This inventory-and-reconciliation approach can reduce overpermissioning, but it isn’t a complete method for discovering all shadow AI. Unmanaged devices and unsanctioned external services can remain outside enterprise telemetry.
Record each agent’s owner, tool dependencies, data classifications, credential issuer, and retirement process. Non-human identity lifecycles need explicit offboarding because agents don’t leave through an employee termination workflow. Use ephemeral access where possible.
Disable unused connectors and remove standing grants when workflows retire.
Test denied actions and operational failures
Test runtime least privilege by checking cross-tenant reads, unauthorized exports, expired credentials, changed approval details, and prompt-injected requests for higher privileges. A successful authorized run proves little about the security boundary.
Also test policy-service outages. Sensitive actions should fail closed, while safe workflows may continue with reduced functionality. Define that behavior before production.
Log the agent identity, delegated user, task identifier, target resource, policy decision, approval reference, and outcome to create audit trails. Redact secrets and limit sensitive payload logging, while retaining enough context to investigate a security incident.
Central gateways simplify enforcement, but they create shared dependencies and can become bypass targets. Verify that agents cannot reach protected tools through another network path for tool execution.
Choose authorization components, gateways, and policy engines based on supported controls and integration constraints within your governance framework. No single framework or vendor fits every enterprise workflow. Re-run boundary tests after tool, model, policy, or connector changes as part of continuous verification to keep your security posture current.
Frequently Asked Questions
What does least privilege mean for an AI agent?
It means giving an agent only the authority required for its current task, including access to specific tools, records, and actions. Permissions should also be bounded by workflow stage, time, and destination.
Why can’t the model enforce its own permissions?
Model instructions can be influenced by mistaken decisions or malicious content, so they aren’t a reliable security boundary. A trusted tool adapter or API must authorize each requested action before execution.
How should an agent access a user’s permissions?
For delegated work, authorize the intersection of the user’s entitlements, the agent’s permissions, and the task policy. Keep both identities in the authorization and audit context rather than impersonating the user.
When should a human approve an agent’s action?
Require approval for consequential actions such as releasing payments, transferring data externally, making destructive changes, or escalating privileges. Bind approval to the exact proposed action and recheck permissions when it executes.
How can teams test agent least privilege?
Test denied actions as well as successful runs, including cross-tenant reads, unauthorized exports, expired credentials, changed approval details, and prompt-injected requests. Also verify that sensitive actions fail closed during policy-service outages and that alternate tool paths cannot bypass controls.
Make the Permission Boundary the Production Contract
Least privilege works when runtime least privilege follows the task across identity, retrieval, tools, and execution. AI agents can propose actions, but trusted systems decide which actions may occur.
A workflow-specific governance framework gives each agent a distinct identity and scopes access to required steps. Bind sensitive approvals to exact operations, then test denials as carefully as successful runs.
The support agent introduced earlier should have only the routes its task requires. A smaller authority boundary keeps a manipulated instruction from becoming unrestricted enterprise access.
