Principle of least privilege

The principle of least privilege says that every program and every user of a system should operate with the smallest set of privileges needed to complete the job.

Origin. Jerome Saltzer and Michael Schroeder listed it among their design principles for protection mechanisms in 1975. Their reasoning: it limits the damage an accident or error can cause, and it reduces the number of privileged interactions, so fewer programs need auditing when privilege is misused. RFC 4949, the internet security glossary, gives the same definition and adds that the principle also tends to reduce complexity.

In A2A. The A2A enterprise guidance states that agents must grant a client or user only the permissions needed for the operations they intend to perform through the A2A interface. It suggests OAuth scopes so an authenticated client can invoke some skills and not others, and it expects agents to enforce authorization before sensitive actions on the systems behind them.

Why it matters more for agents. A language model’s behaviour is not fully predictable, and injected instructions can redirect it. OWASP’s Excessive Agency risk (LLM06:2025) traces damaging agent actions to three root causes: excessive functionality, excessive permissions and excessive autonomy. AP2’s authorization model starts from the same premise, stating that even well-behaved agents need tighter constraints than an ordinary authorization model places on human users.

Applied to an agent. Illustrative:

Broad grant	Least-privilege grant
Full account API key	Token scoped to refunds on one order
No expiry	Expires when the task ends
Any amount	Capped at the order total
Tool that can read, write and delete	Read-only tool unless the task needs writes
Acts without review	Human approval above a set amount

Neighbouring terms. Scoped credentials and mandates are how least privilege gets written into what an agent carries. The confused deputy problem is what excess privilege makes possible.