AI Security
AI Agent Permissions: Least-Privilege Authorization by Design
A practical authorization model for AI agents covering tool policy, scoped credentials, human approval, multi-tenant boundaries, and audit evidence.
AI agent permissions should determine exactly who may perform which action on which resource, under what context and limits. The model may propose an action, but a deterministic authorization system must decide whether it is allowed. That separation lets an agent remain useful without inheriting a user’s or service account’s full authority.
Least privilege for agents is more than hiding tools from a prompt. It requires narrow capabilities, resource-level checks, scoped and short-lived credentials, limits on action chaining, meaningful approval for high-impact changes, and enforcement at every target system. If prompt injection or model error changes a plan, those controls should still contain the consequence.
Why AI-agent permissions are different
Traditional applications execute paths developers defined in advance. An agent selects among tools and may revise its plan as results arrive. Its behavior is probabilistic, multi-step, and sensitive to dynamic context. A broad goal such as “resolve the customer issue” can expand into reading records, editing an account, sending an email, or issuing a refund.
Authorization must account for action chaining, delegated authority, changing session state, newly discovered tools, model uncertainty, and machine-speed repetition. A permitted read and a permitted write can combine into a consequence no individual check captures.
The broad AI agent security guide covers isolation, memory, monitoring, and incident response. This page focuses narrowly on the authorization decisions between an agent’s plan and a real side effect.
Authentication is not authorization
Authentication establishes an identity: for example, user Alice, workload agent-42, or a tool gateway running in production. Authorization asks whether that principal may perform a specific action on a specific resource under current conditions.
An agent knowing that the user is Alice does not prove Alice owns invoice 817, may approve its payment, or intended this particular transaction. Likewise, an agent authenticated with a backend service account should not inherit all of that account’s permissions. Keep the requesting human or service, the executing agent workload, and the target-system credential separately identifiable in policy decisions and logs. NIST’s 2026 identity analysis warns that sharing human credentials with agents creates impersonation and accountability gaps, and recommends treating agents as first-class entities with identifiers, credentials, and entitlements tied to the user or system operating them.
Never make the LLM the authorization engine
An LLM can extract a proposed action, classify intent, or explain a policy result. It should not be the policy decision point. Natural-language conclusions such as “this refund seems allowed” are nondeterministic, may rely on incomplete context, and can be changed by untrusted content.
A real decision should look more like: principal Alice, through agent-42, may issue a refund of at most $100 on order 817, which belongs to Alice’s tenant, before 17:00, provided the order is eligible and no refund already exists. Each fact comes from an authenticated or authoritative source, not the model’s assertion.
The policy service should return allow, deny, or an explicit step-up requirement. Unknown principal, missing ownership, ambiguous resource, stale consent, or unavailable policy should fail closed. The target API should still enforce its own access controls; a gateway approval is not a reason to remove defense in depth.
The Agent Authorization Decision Model
PermsAI’s model evaluates WHO can do WHAT to WHICH RESOURCE under WHICH CONTEXT with WHICH LIMITS.
| Element | Meaning | Example evidence |
|---|---|---|
| Requesting subject | Human or service on whose behalf work is performed | Authenticated user session or signed workload request |
| Agent principal | Distinct workload executing the plan | Agent identity and deployment instance |
| Action | Typed operation, not a prose goal | invoice.read, refund.create, email.send |
| Resource | Canonical target and owner | Tenant ID, order ID, mailbox, repository |
| Context | Current security and business facts | Environment, device assurance, risk signal, workflow state |
| Constraints | Boundaries on execution | Amount, destination, fields, count, time, rate, purpose |
| Approval | Transaction-specific human authorization when required | Approver, immutable action summary, timestamp |
| Expiry | Point after which authority is invalid | Token expiry or workflow deadline |
Map every tool call into this decision object before execution. Do not pass free-form model text directly to a policy engine. Resolve names to canonical resource identifiers, validate the schema, retrieve ownership from the system of record, then ask the policy decision point. Store the decision ID with the resulting tool event.
Apply least privilege across dimensions
Least privilege constrains multiple dimensions: available tools; read, create, update, delete, and administrative actions; resource and tenant; environment; expiry; volume and spend; destinations; and the approved workflow purpose.
A role such as “support agent” may be a starting point, but resource attributes and transaction constraints must narrow it. NIST notes that moving from static keys to modern authorization protocols does not automatically eliminate overly broad entitlements.
Tool-level authorization
Tool registration controls what the model can request; the gateway controls what actually executes. Give each tool a stable name, typed input schema, risk classification, allowed environments, and policy reference. Reject unknown fields, ambiguous identifiers, and unsupported destinations.
A useful enforcement sequence is:
- authenticate the requesting subject and agent workload;
- parse the model’s proposed tool call against a strict schema;
- resolve resource identifiers without trusting model-supplied ownership;
- evaluate action, resource, tenant, context, constraints, and expiry;
- obtain step-up approval if policy requires it;
- attach a scoped credential and call the tool adapter;
- let the target system recheck authorization and invariants;
- record the decision and result.
Default deny applies to unregistered tools and parameters. Prefer constrained business-level tools over a generic HTTP client that can select arbitrary methods and destinations.
Design credentials for containment
Do not give an agent a user’s password, a cloud administrator key, or one shared token used by every tenant. Store secrets server-side in the gateway or workload identity system, outside prompts, memory, and tool results. Mint or select credentials only after authorization.
Prefer credentials that are short-lived, audience-restricted, and scoped to the needed action and resource where the platform supports it. Delegation should attenuate authority: each hop receives the same or less privilege, never more. OAuth and workload-identity patterns are useful foundations; RFC 9700 documents current OAuth security practices, not end-to-end proof of user intent.
Revocation must work during an active workflow so operators can invalidate one credential, tool, workflow, or tenant without stopping every agent.
Use human approval at meaningful boundaries
Approval is appropriate when policy cannot safely pre-authorize a consequential action: destructive changes, financial transactions, external communications, privilege escalation, credential operations, or high-impact production modifications. It should not interrupt every harmless read.
Show the exact action, resource, destination, parameters, and effect. Bind approval to that immutable transaction with a short expiry; any material change invalidates it.
Overuse creates approval fatigue. NIST compares overly chatty agent prompts with consent-fatigue patterns: users become conditioned to click allow. A permission boundary ladder makes escalation more deliberate.
| Boundary | Example | Typical controls |
|---|---|---|
| Read | Retrieve an authorized customer record | Resource check, field minimization, audit |
| Draft | Prepare an email or change without sending | Same read controls, isolated draft storage |
| Internal write | Update a reversible internal field | Fresh policy check, schema validation, rollback |
| External side effect | Send a message or create a transaction | Destination/amount limits, step-up when risk warrants |
| Destructive action | Delete data or revoke access | Explicit transaction approval, recovery path, dual control when appropriate |
| Privileged/admin action | Change roles, policies, credentials, or production config | Separate administrative workflow; normally unavailable to the agent |
Put a policy enforcement gateway in every action path
The intended architecture is:
Agent → typed tool request → policy enforcement point → identity and context resolution → authorization decision → credential broker → tool adapter → target system
The model must not have a second path that calls the target directly. Network policy and secret placement should make bypass impossible, not merely prohibited in the system prompt. The gateway should centralize common controls, but target services remain responsible for resource ownership, state transitions, and business invariants.
Re-evaluate authorization when the action changes. Approval to draft a message does not authorize sending it; permission to read a repository does not authorize merging code. For multi-step plans, carry a workflow identifier and delegated authority envelope, then narrow it at each step.
Least privilege limits prompt-injection impact
A successful prompt injection may influence the agent’s chosen action, but it should not create authority. The prompt injection guide explains how untrusted documents, web pages, and tool results can alter model behavior. If the tool gateway independently checks identity, resource, tenant, action, and limits, an injected instruction becomes a denied proposal rather than a completed transaction.
This is why hiding a dangerous tool from the prompt is insufficient. The attacker may find another tool chain, and the model may hallucinate a permitted route. Enforce permissions at execution, constrain credentials, and validate downstream effects.
Enforce tenant boundaries explicitly
Every authorization request in a multi-tenant system should carry a tenant derived from the authenticated session or workload identity—not from model text. Resolve the resource and verify its tenant before returning data or executing an action. Include tenant scope in credentials and policy caches where possible.
Guard against cross-tenant identifiers in tool arguments, retrieval results, shared memory, queues, caches, and logs. A globally unique record ID does not make access legitimate. Tests should attempt horizontal access with valid IDs from another tenant and confirm denial at both gateway and target service.
Preserve audit evidence
Record the subject, agent version, action, resource, tenant, policy version, decision, constraints, approval, credential reference, execution, and outcome with a shared correlation ID. Avoid raw secrets and indiscriminate prompt retention; responders must still be able to reconstruct delegation, decision, action, and result.
Common permission failures
- Wildcard tools: one generic interface reaches many methods or destinations.
- Shared credentials: human and agent actions become indistinguishable.
- Agent-admin tokens: ordinary workflows inherit privilege-management authority.
- Natural-language permission claims: the model says a user consented without authoritative evidence.
- Missing object checks: a role allows an action but ownership of the specific record is never verified.
- Tool-chain escalation: several low-risk calls combine to create a high-risk side effect.
- Standing authority: credentials outlive the task, user session, or deployment.
- Approval drift: the executed parameters differ from what the user approved.
The reported Anthropic cyber-evaluation incidents provide a concrete reminder that reachability and task similarity are not authorization. For the surrounding application trust boundaries, see the LLM security risks guide.
Implementation checklist
Before enabling an agent to act, verify that:
- the user, agent workload, and target credential are separately identifiable;
- every tool maps to typed actions and canonical resource identifiers;
- default deny covers unknown tools, fields, resources, tenants, and destinations;
- authorization is enforced outside the model and repeated at the target service;
- permissions constrain action, resource, environment, time, volume, and destination;
- credentials are server-side, scoped, short-lived where feasible, and revocable;
- approvals show and bind the exact transaction instead of a broad goal;
- delegated authority can only stay equal or become narrower across tool chains;
- tenant scope comes from authenticated context and is tested against horizontal access;
- audit events connect delegation, policy decision, tool execution, and outcome;
- operators can revoke a credential, disable a tool, and stop one workflow quickly;
- adversarial tests confirm that prompt injection cannot bypass the gateway.