Least privilege for AI agents

The control gap

Agents are commonly given a token sized for an integration rather than for the current task. That leaves unused actions and resources available whenever the runtime is compromised or misdirected.

Least privilege should be measured at the external action, not inferred only from the agent's prompt or job title. Inventory the actual tools, actions, resources, environments, task purposes, and approval exceptions observed. A support agent may legitimately create issues in one repository but have no reason to merge, change protections, or reach every repository covered by the integration token.

Reduce authority in layers. First remove unused provider scopes where practical. Then apply deterministic deny and allow rules inside the remaining credential. Route exceptional, reversible work to request-bound approval. For supported adapters, issue a one-use grant so the agent never handles the reusable provider credential. Review emergency paths and periodic work before accepting a posture recommendation.

What good looks like

Policy and one-use grants constrain each execution to the observed task, tool, resource, purpose, and expiry while posture analysis proposes further reductions.

• Task and purpose conditions
• Resource-specific rules
• One-use scoped grants
• Observed-use posture recommendations

A production workflow

1. Measure real calls in shadow mode
2. Separate routine from sensitive actions
3. Enforce narrow resource rules
4. Review simulated reductions

Evidence to require

• Standing policy reach
• Observed action and resource set
• Grant scope and expiry
• Unused-access recommendation

Buyer checklist

• Can the product enforce a decision before the external tool executes?
• Can policy distinguish the agent, delegated user, tool, resource, and environment?
• Can reviewers see the exact requested action and approve it without broadening future access?
• Does every allow, deny, and approval retain the policy version and reason?