AI agent least privilege: let the model propose, let policy decide

An AI agent that can call APIs is more than a text interface. Its proposed actions may read private records, change application state, or communicate with other systems. The permission design therefore needs to describe not only what the agent can say, but what the execution environment will actually allow it to do. A broad credential paired with a careful prompt is not a substitute for a constrained action boundary.

This guide uses an imaginary customer-support assistant to explore a least-privilege design. The assistant can retrieve approved account information and propose a ticket update, but consequential actions require additional checks. The AI API Agent overview introduces this separation between planning and execution. The approach below is a reference pattern, not a claim that this website operates a connected agent.

Begin with the task and the consequences

Write the intended task in a short sentence, then list the minimum actions required to complete it. Distinguish reading from writing, internal changes from external communications, and reversible actions from difficult-to-reverse ones. A support assistant that summarizes a ticket does not need the same capability as an assistant that changes account ownership. Avoid granting the larger capability simply because both are available in one integration.

Identify the delegated authority

OWASP's LLM06:2025 guidance describes excessive agency in terms that include excessive functionality, permissions, and autonomy. Use those as separate review questions. Does the agent have unnecessary tools? Are its credentials broader than the task requires? Can it execute a consequential action without an appropriate approval boundary? The rest of this guide proposes concrete engineering decisions for answering those questions in a support workflow.

Give the agent an attributable identity

Decide whether the agent acts on behalf of a human user, under a dedicated service identity, or through a carefully defined combination. Preserve the distinction in the audit record. A service account's ability to access a system does not automatically mean every user of the assistant should inherit that account's full access. The application must establish the effective permission for each action.

Scope credentials to the relevant environment, resource set, and operation. Keep production and test identities separate. Define rotation, revocation, and ownership before the integration becomes operational. Do not place credentials in the model context as ordinary text when the executor can retain them securely. A model may request a named operation; the executor should supply only the appropriate credential through a trusted execution path.

Design narrow tools with explicit contracts

Prefer a tool such as reading an authorized ticket over a general interface that can issue arbitrary requests to arbitrary destinations. State the accepted arguments, allowed targets, maximum result size, and expected response structure. Remove operations the workflow does not need, even when the integration makes them easy to expose. Narrow interfaces make both authorization and testing more comprehensible.

Validate relationships between arguments, not just their individual types. A ticket and an account can each exist without belonging together. Resolve sensitive context from trusted state where possible rather than allowing the model to select it freely. Document the distinction between a descriptive tool result and a new instruction. The executor should not interpret text returned by one tool as permission to expand the next tool's scope.

Put authorization at execution time

Treat the model's proposed tool call as a request, not a verdict. Before execution, validate the arguments, establish the effective actor, check resource access, and apply the relevant operation policy. Use a clear default when required context is absent. A missing tenant relationship or approval record should not be silently filled in by asking the model to guess.

Keep this check close enough to execution that it reflects the actual action and current state. A permission checked much earlier may no longer be valid after a membership change or a delayed job. Where a workflow intentionally relies on a previously approved commitment, define its scope and lifetime explicitly. The multi-tenant authorization guide shows why identity alone is insufficient for resource-specific access.

Make approval specific and inspectable

For an action requiring human approval, show what will happen, which resource will be affected, and the parameters that matter. A button labeled only approve is weak when the reviewer cannot see the intended operation. Bind the approval to the action that was reviewed, not to an open-ended conversation or every future tool call in the session.

Decide when approval expires and what changes invalidate it. If the agent changes the recipient, amount, destination, or target resource, the earlier approval may no longer apply. Separate proposing an action from executing it so the user can understand the boundary. Also define rejection and cancellation behavior. An approval flow is part of the application's state machine, not simply a reassuring message added to a prompt.

Bound the workflow independently

Limit how many steps, calls, and resources the agent can consume while pursuing a task. Put those controls in the execution environment and make their outcomes visible. A repeated attempt to perform a denied action should not continue indefinitely. Decide whether the workflow stops, asks the user for clarification, or returns a limited result after a boundary is reached.

Use budgets for tool calls and model usage without confusing them with permission. An action being within budget does not make it authorized. Similarly, an authorized action can still be paused because the shared service lacks capacity. The AI Token Sentinel pattern complements least privilege by limiting consumption. Keeping these policies distinct helps operators explain why a request was rejected and which team should review it.

Preserve an execution record

Record the initiating actor, workflow identifier, proposed operation, policy decision, approval reference when applicable, and the execution outcome. Keep proposal and completion separate. A model saying that it changed a ticket is not evidence that the executor successfully changed it. Likewise, a request accepted for asynchronous work is not yet a completed action.

Use structured result states and safe error descriptions. Avoid logging full credentials, private documents, or unnecessary conversation content. Protect access to the records and maintain the policy version needed to reconstruct the decision. The evidence should let an authorized reviewer answer a practical question: what action was requested, who permitted it, and what actually happened? That question is more useful than a transcript containing every intermediate word.

Test denied paths and changed context

Create fixtures for a legitimate action, an unauthorized resource, an invalid argument relationship, an expired approval, a revoked identity, and a tool timeout. Verify the executor's behavior independently of the model's natural-language explanation. The correct result may be that a proposal is generated but never executed. Test that the user-facing status reflects that distinction accurately.

Include changes between proposal and execution. Remove a membership, alter a resource state, or cancel the workflow in a controlled environment. Confirm that the action does not inherit stale authority unintentionally. Test replay and duplicate submission for operations where repetition matters. Keep the evaluation scoped to systems you own or are authorized to assess, using synthetic records so the exercise cannot affect real customer data.

Make delegation deliberate

Least privilege is not a request for an agent to do less useful work. It is a way to define exactly which useful work the system is authorized to perform. The task, identity, tool contract, approval boundary, and execution evidence should all agree about that scope.

Review the design whenever a new tool or resource becomes available. Convenience can quietly expand an agent's authority unless someone owns the permission model. Start with a narrow task, test the rejected paths as carefully as the successful ones, and use the agent monitoring guidance to make execution observable. Let the model propose possibilities, while trusted policy decides which actions may become real.

Primary reference: OWASP LLM06:2025 Excessive Agency. The practical workflow and examples above are editorial guidance; the linked reference supplies the relevant technical foundation.