It's tempting to grant a new AI agent broad access, so it never hits a permission wall mid-task, but this is exactly backward from a security standpoint. Least privilege means scoping an agent's identity to exactly what its specific job needs: an invoice-processing agent gets access to the AP system and nothing else, not the entire ERP.

This matters especially for AI agents because of prompt injection risk: if an agent is somehow manipulated into attempting an action outside its intended task, tight scoping means it simply can't, regardless of what it's tricked into trying, rather than relying entirely on the model's judgment to refuse.

Frequently Asked Questions

Why is least privilege especially important for AI agents versus human users?

A human generally understands not to act outside their role. An AI agent can be manipulated (via prompt injection) into attempting something outside its intended scope, so the access boundary itself, not the agent's judgment, becomes the actual safeguard.

What does scoping an agent's access actually look like in practice?

Granting a distinct agent identity (not a shared human's credentials) with permissions scoped to specific systems, specific actions within those systems, and often a dollar or volume threshold above which it must escalate rather than act autonomously.

What happens if an agent needs broader access for a new task?

Its access should be deliberately expanded to cover the new, specific need, not broadened preemptively "just in case." Each expansion is a deliberate decision, not a default toward maximum access to avoid future friction.

How does this relate to using a shared service account for multiple agents?

A shared account defeats least privilege by design, every agent using it inherits the combined access of all their needs, and there's no way to audit which specific agent took a given action. Distinct, individually scoped identities per agent are the standard practice.