Access control for AI agents defines which data an agent may read, which actions it may take, and whose authority permits each operation. Those decisions need enforcement in the systems handling the request.
Authentication verifies identity. Authorization decides permission. An agent allowed to read a customer record should not automatically gain permission to change it, export it, or issue a refund.
That distinction becomes critical when one conversation spans a knowledge base, CRM, email service, and payment system. Each step can require different authority, even when the user describes everything as one task.
Why reading and acting need separate permissions
A contract assistant might retrieve an agreement correctly, then disclose a confidential clause to someone outside the legal team. No database update is necessary for an access-control failure.
NIST's Zero Trust Architecture rejects implicit trust based on network location or ownership. Applied to agents, that means running inside your cloud does not establish permission to access your resources.
| Boundary | Read-only retrieval | State-changing actions |
|---|---|---|
| Data access | Check authorized documents, rows, and fields | Keep the same data restrictions |
| Operations | Limit retrieval and disclosure | Authorize each create, update, delete, or send operation |
| Sensitive steps | Restrict confidential access and output | Add approval where the action's impact requires it |
| Failure tests | Attempt unauthorized retrieval and leakage | Also test tampering, replay, and duplicate execution |
Prompt injection can influence what a model requests. It must not determine what the backend permits. The following nine controls cover authorization, limits on execution, and operational evidence.
Related LuMay guides: See how to design AI agent audit trails for accountability evidence, and review the requirements for integrating AI with legacy enterprise systems.
1. Give agents distinct identities and explicit delegation
Failure prevented: Shared administrator credentials hide which workflow acted and can grant an agent more authority than its requesting user possesses.
Give each independently permissioned agent deployment a workload identity, named owner, documented purpose, and lifecycle. Separate production from development identities; track individual executions with run identifiers.
For work performed on a user's behalf:
- Record both the agent and the initiating user.
- Define permitted resources, operations, expiry, and downstream delegation.
- Constrain access by the user's authority, the delegation grant, and the agent's policy limits.
For unattended workflows, use an explicitly approved application grant. Do not invent a user delegation for a scheduled job.
When one agent delegates to another, authenticate the receiving worker and authorize its specific task. A planner's message is not permission to use a specialist's broader credentials.
Verification test: Have a read-only agent request a write through a privileged worker. The worker should deny it unless a separately authorized grant permits the operation.
2. Separate read, draft, write, and send permissions
Failure prevented: A summarization feature can modify records or contact customers because its connector carries broad application access.
Define permissions around business operations. Reading an invoice, preparing a payment draft, submitting it for approval, and executing payment are separate capabilities.
- Expose narrow tools such as creating a draft ticket.
- Separate export, deletion, external communication, and privilege changes.
- Remove unused tools and restrict their underlying credentials.
OWASP's AI Agent Security guidance recommends minimum necessary tools and per-tool permission scoping, including separate read and write access.
Scope labels do not enforce themselves. The destination API must interpret them and check the specific resource. Hiding a write tool from the interface does not help if its endpoint still accepts the retrieval credential.
Verification test: Use the normal retrieval credential to call update, delete, export, and send endpoints directly. Confirm every operation outside its grant is denied.
3. Enforce tenant, row, document, and field permissions
Failure prevented: A shared search index returns another customer's document, or an authorized record exposes fields the user cannot view.
Use role-based access control (RBAC) for job responsibilities and attribute-based access control (ABAC) for conditions such as tenant, resource ownership, and classification.
Derive tenant identity from authenticated server context. Enforce source permissions before retrieved content reaches the model, including metadata, snippets, and citations.
For retrieval-augmented generation (RAG):
- Preserve permission metadata on document chunks.
- Protect cached answers, summaries, and conversation history.
- Define how permission changes invalidate previously retrieved context.
Microsoft's document-level access documentation explains that indexed permissions depend on synchronization. Several native approaches remain in preview; check feature status before choosing an implementation.
If access must end immediately, stale index metadata is insufficient. Check authoritative permissions before releasing results. Include this requirement in RAG development from the start.
Verification test: Remove document access, then query through search, cached answers, and follow-up questions. Measure the exposure window against your revocation requirement.
4. Use scoped credentials and protect their lifecycle
Failure prevented: A leaked key remains useful indefinitely or works against systems unrelated to the task.
Prefer managed identities or workload federation where supported. Keep necessary secrets in a controlled secret manager and outside prompts, retrieved documents, tool results, and logs.
At the receiving service, validate the issuer, intended audience, expiry, and permissions. Verify signed tokens cryptographically; decoding their claims is not validation.
The OAuth 2.0 Security Best Current Practice recommends audience restrictions and minimum privileges. Where supported, sender-constrained tokens require proof from the legitimate holder, reducing the usefulness of a stolen token alone.
Choose token lifetimes around the workflow's risk and operational needs. Protect refresh credentials too: short access-token lifetimes offer limited containment when an attacker can continuously obtain replacements.
Verification test: Present a token to the wrong API, retry after expiry, and attempt renewal after the relevant grant is revoked. Confirm rejection without recording token values.
5. Authorize every retrieval and tool call server-side
Failure prevented: A malicious document persuades the model to request restricted data, and a connector trusts the request without checking permission.
Enforce policy at retrieval services, execution gateways, and destination APIs as appropriate. Evaluate the authenticated actor, delegation, tenant, operation, target resource, and current policy.
- Deny requests missing required authorization context.
- Validate tool arguments against permitted resources and operations.
- Reauthorize queued work when it executes.
- Fail closed when required policy checks are unavailable.
For HTTP integrations using MCP authorization, the Model Context Protocol specification requires token audience validation. That check does not replace your application's resource permissions or business approval rules.
Build these checks into enterprise AI integration, including connectors to legacy systems. A gateway must not become a privileged shortcut around source-system restrictions.
Verification test: Place an instruction in an authorized document asking for a forbidden record. Confirm that the backend rejects the attempted retrieval even if the model requests it.
6. Bind human approval to the exact action
Failure prevented: A person approves one transaction, but the agent changes the amount, recipient, destination, or affected records before execution.
Require approval for actions whose impact warrants it, such as payments, privilege changes, bulk deletion, or sensitive exports. Generate the preview from validated server-side data rather than relying only on the model's summary.
Bind the approval record to:
- The actor, tenant, operation, and target resources.
- Material parameters and the relevant resource version.
- An authorized approver, expiry, and single-use identifier.
OWASP's transaction authorization guidance calls for transaction integrity and a final authorization gate before execution.
Reject changed parameters. Atomically claim a single-use approval and coordinate it with a durable execution record so concurrent calls or crashes do not cause blind retries.
Approval supplements access policy; an approver cannot grant an operation beyond their own authority.
Verification test: Approve a refund, alter its destination, then replay the original request concurrently. Reject the alteration and verify that replay creates no duplicate refund.
7. Restrict tools, destinations, and outbound data
Failure prevented: An approved connector sends confidential data to an unauthorized account, recipient, endpoint, or model service.
Allowlist the tool, operation, destination, and permitted data categories. Trusting an email provider does not establish trust in every recipient.
- Replace open-ended shell or HTTP tools with narrow operations where possible.
- Restrict network egress and validate the actual connection destination.
- Disable redirects or revalidate every destination before following them.
- Block metadata endpoints and unauthorized internal addresses.
Apply data minimization and inspection to model requests, attachments, uploads, and messages. A sensitive-data detector can miss content; it should supplement explicit access and destination rules.
Map these disclosure paths during AI engineering design, especially when internal retrieval feeds external services.
Verification test: Use controlled test endpoints to make an allowed destination redirect elsewhere. Separately attempt a sensitive attachment to an unapproved recipient. Both attempts should stop before disclosure.
8. Limit transactions, handle retries, and test revocation
Failure prevented: Valid permissions allow a loop, retry storm, or parallel workers to exceed business limits or repeat an action.
Enforce per-action and cumulative limits on amounts, records, recipients, retries, and execution time. Aggregate budgets across delegated workers so splitting a task cannot bypass a threshold.
Use a stable idempotency key for one logical operation, bound to its tenant and parameters. Deduplication needs enforcement and durable state; adding a key does not guarantee exactly-once execution.
When an outcome is uncertain, reconcile downstream status before retrying. For emergencies, block execution routes, stop new grants, revoke applicable credentials, and cancel queued work.
A self-contained access token can remain accepted until expiry unless resource servers enforce revocation state. Disabling an identity alone may not stop every worker, and no kill switch reverses a completed external action.
Verification test: Simulate a timeout after successful execution, retry concurrently, then disable the agent. Check for duplicate effects and measure when every worker stops accepting new actions.
9. Maintain audit evidence and review effective access
Failure prevented: The team cannot reconstruct an action or discover permissions that outlived their purpose.
Connect the user request, agent run, delegation, policy decision, approval, tool invocation, and downstream result through correlation identifiers.
Record actor identities, tenant, timestamps, resource references, policy versions, allow or deny decisions, approval references, and execution outcomes. A conversation transcript alone cannot establish what the API executed.
- Keep secrets and unnecessary personal data out of logs.
- Restrict audit access and protect records against alteration or deletion.
- Alert on unusual exports, repeated denials, and activity after disablement.
- Review permissions after ownership, role, tool, or workflow changes.
Make these reviews part of ongoing LLMOps practices for enterprise AI. Review actual downstream privileges as well as the agent's declared tool list.
Verification test: Reconstruct one allowed and one denied action from audit records. Remove an obsolete permission and confirm that the agent's effective capabilities change.
Two hypothetical scenarios to test
A supplier document attempts data theft
A purchasing agent reads an authorized quotation containing instructions to upload internal pricing to an external site.
The quotation provides task data, not authority. Tool authorization and destination restrictions should block the upload, while the audit record captures the attempted action without duplicating the confidential pricing.
An approved refund changes destination
A supervisor approves a $120 refund to the original payment method. A later request changes the destination, while another worker retries the original operation after a timeout.
Parameter-bound approval should reject the destination change. Retry handling should reconcile the original refund instead of treating the timeout as proof that nothing happened.
Deployment checklist
Before production, require evidence that:
- Every agent has an owner, identity, permission inventory, and delegation model.
- Retrieval and action permissions are separated and enforced downstream.
- Tenant and document restrictions survive indexing, caching, and follow-up questions.
- Credentials are scoped, protected, and tested across expiry and revocation.
- Every tool call receives a current authorization decision.
- Approvals resist parameter changes, stale versions, replay, and concurrency.
- Outbound rules cover recipients, redirects, uploads, and model-bound data.
- Limits and duplicate-action controls work across delegated workers.
- Revocation meets a measured containment target.
- Audit records support investigation without exposing unnecessary sensitive data.
Assign an owner and expected result to each negative test. Repeat relevant tests when prompts, tools, connectors, or policies change.
Build permissions into the workflow
Start with one agent. Map its data sources, possible actions, delegation paths, and failure tests before expanding its authority.
For implementation support, explore LuMay's AI agent development services and discuss how these controls fit your existing identity, integration, and operational systems.
