Least Privilege for AI Agents: Tools, Data and Delegated Authority

Least privilege is familiar: give a principal only the access needed to perform its job. AI agents make the principle harder because their “job” changes during a conversation. An assistant may search documentation, retrieve a customer case, draft a reply and propose a refund in one workflow. Granting authority for the most powerful step across the entire session creates unnecessary exposure.

Agents also choose tools and arguments from natural-language context. Untrusted email, webpages, documents and tool results can influence those choices. Least privilege must therefore be dynamic, consequence-aware and enforced outside the model.

Define practical authority

Start with what the agent can actually cause, not the tools shown in its interface. Map workload credentials, user delegation, tool inventory, downstream service roles, reachable data, network destinations and approval paths.

A hidden tool may remain directly callable. A read-only UI may sit over a service credential with write access. A search tool may accept arbitrary SQL. Validate effective authority at the final system.

Record maximum consequence per operation: public read, private read, reversible write, external communication, transaction, permission change, destructive action or code execution.

Separate identities

Give the agent workload its own identity. Preserve the initiating user when acting through delegation. Do not use one shared key for every agent or one user token for every resource.

Validate issuer, audience, environment and lifetime. Separate production from development. Revoke agent identity independently when compromised.

The downstream service should see enough trusted context to enforce both workload and user policy. See AI agent authentication and authorization for detailed patterns.

Grant capability per task

Instead of giving standing access to every tool, derive a task capability after policy evaluation. Scope it to tool, action, resource, tenant and expiration. High-impact capabilities can require trusted approval.

Expire authority when the task ends. Do not let a long conversation accumulate permissions indefinitely. Reevaluate when the workflow changes from read to write, internal to external or low to high consequence.

Test whether an attacker can establish a benign task, gain access and then pivot without a new policy decision.

Narrow tools and schemas

Prefer get_case_for_current_user over generic database query. Prefer draft_refund and submit_approved_refund over one tool that accepts arbitrary status. Structured operations make authorization and evidence clearer.

Constrain identifiers, destinations, amounts, file roots and bulk size. Derive tenant and user from authenticated state. Reject unknown fields. Avoid generic shell, HTTP and code-execution tools unless strongly isolated.

Review composition. Two low-risk tools can combine into a high-risk path: read confidential data plus send external message. Policy must account for sequences and data flow.

Apply resource-level authorization

Tool permission does not imply permission to every object. Reauthorize customer, document, repository, account and transaction at the owning service. Treat model-supplied identifiers as requested targets.

Test horizontal access across users and tenants, vertical access across roles and context changes during a session. Include list, export, search and pagination endpoints, not only direct object reads.

Use server-derived ownership where possible. A prompt instruction saying “only access the current customer” is not enforcement.

Control data context

Least privilege applies to information supplied to the model. Retrieve only necessary passages and fields. Avoid attaching complete histories, mailboxes or drives. Partition RAG and memory by tenant and purpose.

Minimize context sent to external model providers. Separate sensitive workflows from general assistants. Redact secrets before prompts and logs.

Test inference and aggregation. Repeated permitted queries can reveal more than one response suggests. Apply cumulative and bulk limits.

Time and state boundaries

Use short-lived credentials and capabilities. Recheck role, account state and risk before consequential execution. Invalidate authority after logout, revocation or approval expiry.

Long-running agents need periodic reauthorization. A task created yesterday should not execute today under stale policy. Queued operations should retain a clear authorization snapshot and revalidate material conditions.

Test delayed execution, retries, restored sessions and failover. Cached policy must have explicit lifetime and tenant scope.

Human approval as privilege elevation

Treat approval as temporary elevation, not proof that the model is safe. Display trusted parameters and bind the decision to the exact operation. Separate requestor and approver when policy requires.

If parameters change, invalidate the approval. Prevent replay. Verify approval at the downstream enforcement point.

The human-approval security guide explains how to resist deceptive summaries and fatigue.

Network and execution privilege

Restrict outbound network to required services. Block metadata endpoints, internal administration and arbitrary internet destinations. Limit filesystem roots, subprocesses and package installation.

Run high-risk tools in a sandbox with a dedicated identity and reset state. A container is not sufficient if it mounts broad host directories or credentials.

Test SSRF, localhost access, command injection and escape attempts with synthetic targets. Observe actual network and process effects.

Dynamic authorization policy

Useful policy inputs include workload, initiating user, tenant, task, tool, resource, data classification, destination, consequence, session risk and approval. Keep authoritative attributes outside model control.

Role-based access provides a baseline. Attribute and relationship policy refine resource decisions. Capability tokens can represent narrow, expiring authority. Most enterprises need a combination.

Record which rule allowed or denied a request. This supports investigation and prevents opaque “policy says no” outcomes.

Test for privilege creep

Agent deployments evolve quickly. A new tool, connector or prompt can expand authority without changing the advertised use case. Inventory versions and compare effective permissions during release review.

Look for shared service accounts, wildcard scopes, unused tools, stale approvals and broad default roles. Remove access rather than relying on the model not to use it.

Turn critical denials into regression tests. Retest after identity, tool, schema, model, prompt or orchestration changes.

Least-privilege test plan

1. Invoke hidden or undisclosed tools directly.
2. Substitute user, tenant and resource identifiers.
3. Move from read to write without reauthorization.
4. Combine permitted tools into sensitive data movement.
5. Replay expired capability or approval.
6. Continue after role revocation or logout.
7. Use indirect prompt injection to request elevation.
8. Reach unapproved network, file and process resources.
9. Trigger bulk and cumulative access.
10. Exercise error and fallback paths.
11. Test another agent using the same credential.
12. Verify downstream denial and retained evidence.

Implementation checklist

• Inventory effective authority and maximum consequence.
• Separate agent workload and user identity.
• Issue narrow, audience-bound, short-lived credentials.
• Grant capability per task and remove it afterward.
• Use typed, constrained tools.
• Enforce object authorization at the owning service.
• Minimize model, RAG and memory context.
• Bind approvals to exact parameters.
• Restrict network, filesystem and execution.
• Detect tool composition and privilege creep.
• Record policy, tool and downstream outcomes.
• Retest critical boundaries after every meaningful change.

Frequently asked questions

Can prompts enforce least privilege?

No. Prompts can guide behavior, but trusted services must enforce identity, tool, resource and action policy.

Should every agent have a separate service account?

Agents with different owners or consequences should have separable workload identities. Avoid one credential shared across unrelated systems.

What is just-in-time agent access?

It is temporary authority issued for a specific task, resource and period after policy evaluation, then expired or revoked.

How do we detect excessive permissions?

Compare declared use cases with reachable tools, downstream roles, data and network. Then test direct calls and composed workflows.

Least privilege turns agent security from an instruction problem into an enforceable architecture. Continue with excessive agency, agent secrets management and threat modeling.

Decompose capability by operation

Avoid permissions such as “use CRM” or “access cloud.” List read, search, create, update, delete, export and administer separately. Identify the resources and fields each operation may touch.

Give common, reversible operations a narrow path and isolate rare, consequential actions behind fresh authorization. A support agent that reads a case should not inherit account-deletion capability from the same connector.

Review hidden composition. Read access to secrets plus outbound messaging can equal exfiltration; repository write plus CI execution can equal production access.

Bind authority to purpose and context

Scope access by tenant, user, case, repository, environment or transaction. Include expiry and maximum consequence where relevant. Re-evaluate when context changes.

Do not ask the model to decide whether its purpose permits an action. A trusted policy layer should compare authenticated context with structured arguments.

Standing access should be exceptional. Issue task-specific credentials or delegated grants and remove them when the run completes or is cancelled.

Separate identities and duties

Use distinct workload identities for agents and tools. Preserve the initiating human or service in audit records. Shared accounts make revocation and accountability weak.

Separate planning, approval and execution for high-impact workflows. Ensure the same compromised agent cannot manufacture its own approval through another conversational role.

Keep development, staging and production identities distinct. Test whether non-production tokens or tool configurations can reach production endpoints.

Design tools for narrow authority

Prefer purpose-built operations over general shell, database or HTTP tools. Validate parameters downstream and constrain destinations, methods, resource types and volumes.

Return the minimum data needed. Paginate and cap bulk retrieval. Separate read and write tools so policy and monitoring can treat them differently.

Version schemas and review changes. A harmless tool can become privileged after an update even when the agent prompt remains unchanged.

Control delegation and child agents

A parent may delegate only a subset of its own authority. Include task, resource, action and expiry in the grant. Prevent children from forwarding reusable tokens.

Track the delegation chain and revoke descendants when the parent stops. Test orphaned work, retries and messages arriving after expiry.

Do not infer trust from an agent's role name. Each runtime principal needs explicit policy and independent validation at the target service.

Test least privilege behaviorally

Attempt unauthorized actions through direct requests, indirect injection, altered tool parameters and multi-turn escalation. Test missing identity and malformed claims.

Combine allowed capabilities to discover emergent privilege. Try exporting read data through messaging, changing configuration before execution, or using a support action to reach administration.

Use synthetic resources and mock effects. Capture the policy decision and downstream result, not only the model's response.

Observe permission use

Log credential issuance, token exchange, denied actions, unused grants and high-risk operations. Correlate with user, tenant, run and tool.

Review permissions against observed use. Remove dormant operations and shorten expiry. Alert when an agent suddenly accesses a new resource class or destination.

Protect policy and logs from model-accessible modification. Visibility should not create another route to secrets.

Handle exceptions safely

Emergency access and unusual customer cases need explicit workflows. Capture reason, owner, duration and approval. Expire the exception automatically.

Do not respond to repeated denials by granting a broad permanent role. Investigate whether the tool or workflow should be redesigned.

Review exceptions periodically and after incidents. A temporary privilege that survives becomes the real security model.

Measure progress

Track high-risk operations per identity, duration of grants, unused permissions, exception age and percentage of actions tied to an end-user intent. Measure revocation effectiveness.

Use attack-path exercises to determine whether multiple narrow grants combine into broad consequence. Raw permission counts alone do not show risk.

Report limitations honestly. Least privilege reduces blast radius; it does not make untrusted model behavior safe by itself.

Review vendor and framework defaults

Agent frameworks often optimize for fast integration and grant broad filesystem, network or tool access. Inventory the effective runtime permissions instead of trusting example configurations.

For managed tools, ask whether scopes apply per tenant, user and operation; how revocation works; and which administrative paths bypass normal policy. Validate answers with negative tests.

Treat every new connector as a privilege change. Require review, narrow initial deployment and evidence before expanding its authority.

Keep the permission inventory tied to runtime tests. Policy files can look narrow while fallback credentials, cached sessions or tool composition create broader effective power. Revoke access during active work, inspect the result and retain negative tests for future releases. Evidence of denial is more valuable than a diagram that has never been exercised.