Least privilege for AI agent tool calls

How does least privilege apply to AI agent tools?

Least privilege limits an AI agent to the tools, credentials, resources, and execution time required for its task. Enforce those limits by checking authorization before each tool performs an action. Tool visibility is one control; resource-level authorization is another. A tool appearing in the model's available-tool list does not mean every invocation of that tool is permitted.

For example, a support agent may read one customer's invoice and propose a refund. Don't give the agent a billing administrator's ability to export every account, change payment destinations, or issue arbitrary refunds. Those limits belong in the tool implementation and downstream service, even when the agent has already passed a prompt-injection check.

Microsoft's least-privilege guidance for AI agents treats identity, resource scope, and tool access as design decisions. The following example applies that principle to an application-owned refund workflow.

Define a permission matrix before wiring tools

Separate the model's proposed arguments from the application context used to authorize them. Derive the user and tenant from authenticated server state. Load invoice ownership and payment status from your database. The model must not be able to set fields such as isAdmin, approved, or tenantId to grant itself access.

Treat the matrix as the authorization contract. The agent identity guide covers credentials and delegation; this guide focuses on enforcing that contract when a tool executes.

Put the check on every execution path

Use a fixed sequence at the boundary that performs the work:

1. Validate the proposed arguments against a strict schema and reject unexpected fields.
2. Resolve the authenticated user, agent identity, tenant, and current task from trusted state.
3. Load the target resource and verify the caller's current permission for the operation.
4. Apply business limits, destination restrictions, and any required approval to the validated arguments.
5. Execute using narrowly scoped credentials, then record the outcome with the authorization decision.

For financial or destructive operations, preserve the permission and business limits across concurrent checks and execution. Use the transaction, conditional write, or downstream API guarantee appropriate to the service. An earlier read of a balance or permission is not a reservation. Bind retries to an operation identifier so a network timeout does not cause the effect to happen twice.

If a policy check fails or cannot complete, withhold the sensitive operation according to the failure behavior you chose for that action. Do not translate "the security service timed out" into "the user is authorized." Test your specific SDK and wrapper behavior; defaults vary.

Keep privileges narrow across delegation and retries

Prefer credentials limited to the downstream audience and operation. Avoid passing a broad user token to every subagent and tool. A worker that processes a queued action needs enough identity context to recheck permission; a serialized allowed: true flag from the original conversation is not enough.

Bind approvals to the actual resource, arguments, requester, expiration, and operation identifier. If the model changes the amount or destination after approval, evaluate the new action again. See human approval gates for agent actions.

Revocation also needs an execution boundary. Stopping new conversations does not stop jobs already queued or tokens already issued. Test what happens to the next tool call after access is removed, and document any credential lifetime during which revocation has not yet taken effect.

Which controls leave permission gaps?

A tool-name allowlist reduces available capabilities but does not validate resources or arguments. An allowed send_email operation may still target the wrong recipient.

A sandbox limits filesystem, process, or network access according to its configuration. It does not automatically restrict what a valid SaaS credential can do. Pair isolation with tool policy.

A Model Context Protocol (MCP) gateway can enforce policy for requests routed through it. Local tools and direct downstream calls need their own coverage. The MCP server must authorize access regardless of whether the client advertises a restricted tool list.

A prompt instruction can guide the model but cannot enforce a permission boundary. The tool must reject an unauthorized action even when the instruction fails.

Prove that the scope holds

Test a legitimate operation first, then vary one property at a time: another tenant's invoice, a larger amount, a changed recipient, an expired approval, a revoked role, and a duplicate retry. Assert both the returned decision and the downstream effect. For a denied refund, the payment call count must remain zero.

Run the same cases through alternate tools and background workers that reach the billing service. Add a concurrent pair of requests to test the cumulative limit. These are application authorization tests; an agent evaluation alone is unlikely to exercise all interleavings reliably.

Arcjet Guards can add policy checks at the integrated tool boundary. Supply trusted application context and keep the business authorization in the service that owns the resource. For broader coverage, connect this permission matrix to an agent threat model and the security testing suite.