What least privilege means for an AI agent

Giving an agent a “read/write” integration is easy to describe and hard to defend. The agent may need to update one ticket during one task, yet the credential can edit every ticket for months. A manipulated plan, software defect or stolen token can turn that unused authority into impact.

Least privilege for an agent is not the smallest role a team can configure before launch. It is the smallest mandate needed for the next bounded action, recalculated as the task changes and enforced somewhere the model cannot override.

Separate the delegator from the acting identity

An agent commonly acts because a person requested work, because a scheduled service triggered it, or because another agent delegated a subtask. Preserve that chain. The downstream system should be able to distinguish the human or service that initiated the task, the agent workload that made the request, and the policy that allowed it.

Using a person’s session token for the entire run collapses those roles. Using one shared “agent-service” account collapses every task and tenant. Both make revocation, investigation and policy harder. The 2026 NCCoE concept paper on software and AI agent identity highlights identification, authorisation, auditing and non-repudiation as connected questions for agent systems.

A stronger pattern is delegated authority: authenticate the initiator, identify the workload, then issue a task-specific credential or signed mandate that states what the workload may do on the initiator’s behalf.

Keep attribution through asynchronous steps. When a request becomes a queue message or scheduled job, preserve the initiator, actor, mandate and expiry as verified metadata rather than copying an editable user-supplied identifier. A worker should reject a message whose mandate has expired or whose signature no longer validates. Otherwise, a well-controlled interactive path can quietly regain standing privilege as soon as work leaves the request thread.

Narrow authority across six dimensions

“Can write tickets” is not a least-privilege policy. Define the mandate across at least six dimensions:

Dimension	Narrow question	Example constraint
Principal	Who initiated and who acts?	User A via workload instance W
Purpose	Which approved task is this for?	Resolve support case 1842
Resource	Which objects are in scope?	Case 1842 and its customer record
Action	Which operation and fields?	Add internal note; not close or refund
Time	How long is authority useful?	Expires in ten minutes or at task end
Consequence	What limits or gates apply?	No external send; refund requires approval

Add tenant, location, device posture or data classification where relevant. The policy engine should decide from authenticated attributes and current state, not from a model’s prose explanation.

This is consistent with NIST’s zero-trust architecture, which shifts protection from a trusted network location towards explicit, per-request decisions about subjects and resources. Its cloud-native extension describes identity-tier and application-level enforcement across multi-cloud environments, a useful model when agents invoke many distributed services.

Replace standing privilege with just-in-time capability

Keep the orchestration process free of broad, long-lived secrets. When the agent selects a tool, a broker can request a short-lived capability for the exact resource and action. The broker checks the active task, user delegation, policy, risk signals and any approval, then returns a credential that the target service can verify.

The credential should be audience-bound so it is useless at another service, narrowly scoped, short-lived and preferably sender-constrained. OAuth security best current practice recommends sender-constrained tokens such as mutual-TLS-bound or DPoP-bound tokens to reduce misuse of stolen access tokens. Cryptography does not fix excessive scope, but it can prevent a captured token being replayed by a different sender.

Do not give the model the credential value. The execution service can attach it after validating a structured tool call. Logs and model context should contain a reference or redacted identifier, never a reusable secret.

Design tools that make privilege expressible

Least privilege is difficult when the only tool is run_sql(query) or execute_shell(command). These interfaces transfer policy into free-form strings. Prefer intent-specific tools: add_case_note(case_id, text), draft_refund(order_id, amount, reason) and send_approved_message(approval_id).

Narrow tools are not merely easier to prompt. They create stable authorisation points. The service can verify that the case belongs to the authenticated tenant, that the amount is within the mandate, and that the approval binds the exact recipient and payload. Schema validation should reject unknown fields, not silently accept model creativity.

Where general tools are unavoidable—software engineering and investigations are common examples—place them in a constrained workspace with repository-, path-, command- and network-level policy. A sandbox limits what execution can affect; a separate authority decision still determines whether the task should have that access.

Treat delegation as a shrinking chain

Multi-agent systems introduce a common failure: a coordinator delegates all of its authority to a specialist because that is operationally convenient. Make delegation monotonic. A child may receive a subset of the parent’s resources, actions and lifetime, never more. Record the parent mandate and purpose, and limit delegation depth.

If a specialist needs more privilege, return to the policy or human approval point. Do not allow the specialist to obtain it by asking another agent. Bind results to the task so a capability issued for research cannot later be reused to publish or transact.

This control also improves cost and reliability. A specialist that cannot call unrelated tools has fewer ways to wander, and a trace with explicit mandates is easier to evaluate than an open-ended conversation.

Test denial, expiry and revocation

A happy-path test proves only that the agent can work. Least-privilege tests should attempt to:

• access a neighbouring tenant or resource;
• alter an excluded field;
• exceed a transaction limit;
• replay a credential against another audience;
• use it after task completion or expiry;
• delegate beyond the parent’s authority;
• continue after the initiating user’s permission is revoked; and
• race an action against a revocation or approval cancellation.

Verify the downstream state and audit record, not only the error returned to the model. A denied attempt should identify the acting workload, delegator, requested resource, policy decision and reason without leaking sensitive details into the model context.

Test usability as well. If narrowly scoped credentials cause engineers to add an undocumented bypass, the effective design is the bypass. Measure denial rates, emergency grants and policy exceptions, then refine tool and workflow boundaries.

Review read permissions with the same care as writes. Broad discovery can expose confidential names, relationships and identifiers even when the agent cannot modify them. Search and list endpoints should enforce tenant and resource filters at the service; asking the model to omit results is not access control. Where an agent needs to locate an object before a narrow grant can be issued, return opaque candidates or a purpose-limited reference instead of unrestricted records.

Make privilege visible at the release gate

The release evidence should include an authority inventory for every tool, the actual deployed policy, samples of issued mandates, negative test results, credential lifetime, revocation behaviour and named owners for exceptions. NCSC secure-design guidance recommends secure defaults and restrictions on actions an AI component can trigger; the inventory shows whether those restrictions exist outside the model.

Reject “the agent only uses what it needs” unless the architecture proves it. A capable model with a large tool catalogue may choose not to use a privilege during testing and still retain it when conditions change. The defensible position is structural: the credential does not carry unrelated power, the service refuses out-of-scope parameters, the mandate expires, and an operator can revoke it without negotiating with the agent.