What is an example of least privilege?

A deployment pipeline that can push images to one repository and update one Kubernetes deployment, and cannot read secrets, delete namespaces, or touch any other service. The narrower version of the same idea: a developer who can restart the service they own and hold no other production permission at all.

Why is least privilege so hard to implement?

Because the narrow grant costs more than the broad one at every step. You do not know the minimum set of permissions until you have run the task, expressing a real-world job in verbs and resources produces a combinatorial explosion of roles, and permissions granted during incidents are almost never revoked. Broad access is the path of least resistance, so systems drift toward it unless the narrow path is made easier than the broad one.

Does least privilege apply to AI agents?

Yes, and NIST's definition already covers it: it speaks of processes acting on behalf of users, not only of people. An agent should hold the minimum set of tools and permissions its task requires. OWASP's LLM06, excessive agency, is the name for what happens when it does not.

Concepts

Least privilege

The principle of least privilege says that every user, process, and agent should hold the minimum access required to do its job, and no more. NIST's glossary states it as restricting access privileges "to the minimum necessary to accomplish assigned tasks". It is one of the eight design principles Saltzer and Schroeder set out in 1975, and it is close to universally endorsed, which makes it worth being precise about why it is also routinely violated. The smallest permission that lets someone finish a task is usually much harder to work out, grant, and maintain than a broad permission that obviously works. Least privilege loses to convenience not because engineers disagree with it, but because the convenient grant is the one that is available at the moment the decision is made.

Where it comes from

The phrase comes from Jerome Saltzer and Michael Schroeder's 1975 paper The Protection of Information in Computer Systems, where least privilege appears among the design principles for protection mechanisms. The NIST glossary gives the definition still in use: "A security principle that a system should restrict the access privileges of users (or processes acting on behalf of users) to the minimum necessary to accomplish assigned tasks."

Two words in that definition do more work than they look like they do. Processes: least privilege was never only about people, and it applies unchanged to a CI job or an AI agent. And tasks: the unit of privilege is supposed to be the job being done, not the person doing it. Most access-control systems get the first right and the second wrong.

Why it is hard in practice

The minimum is not known in advance. You find out which permissions a task needs by doing the task and watching it fail, which is not an experiment anyone wants to run during an incident. So the grant is padded, and the padding is permanent.
Permission systems grant capabilities, not outcomes. Kubernetes RBAC's unit is a verb on a resource. The job is "restart the checkout API". Expressing that job as verbs means a role per operation per service per person, which is a combinatorial problem that no team maintains for long.
It decays. Access is granted under pressure and revoked under none. Every incident, migration, and onboarding adds permissions; almost nothing removes them.
Broad is the path of least resistance. Granting edit takes a minute and always works. Writing the narrow role takes an afternoon and might not.

Least privilege is a property of a system's design, not a policy people can be asked to follow harder. If the narrow grant is more work than the broad one, the broad one wins, every time, forever.

Least privilege applies to agents too

An AI agent is a process acting on behalf of a user, which puts it squarely inside NIST's definition. It is also the case where the principle bites hardest, because an agent's behaviour is not fully predictable and its inputs are frequently attacker-influenced. OWASP names the failure mode excessive agency and lists it as LLM06 in its Top 10 for LLM applications. The mitigation is not a better prompt; it is the same principle applied to a new kind of principal.

How Spellbook relates to this

Spellbook does not make it easier to write a narrow RBAC role. It changes what has to be permissioned in the first place. Instead of granting a person the verbs they would need to perform an operation by hand, the operation itself is the thing that is permissioned: a spell runs in your cluster under its own scoped identity, and the person casting it holds no cluster credential at all. That is a different claim from "minimum permissions": the developer's permission set is empty.

What that does not do is remove the decision. Someone still has to say which people and which agents may cast which spells against which services. That is a least-privilege decision and it does not go away. The difference is that it is made in terms of actions a human can reason about ("the checkout team may restart checkout") rather than in verbs and resources, and it is made once rather than re-litigated per incident.

Common questions

What is an example of least privilege?: A deployment pipeline that can push images to one repository and update one Kubernetes deployment, and cannot read secrets, delete namespaces, or touch any other service. The narrower version of the same idea: a developer who can restart the service they own and hold no other production permission at all.
Why is least privilege so hard to implement?: Because the narrow grant costs more than the broad one at every step. You do not know the minimum set of permissions until you have run the task, expressing a real-world job in verbs and resources produces a combinatorial explosion of roles, and permissions granted during incidents are almost never revoked. Broad access is the path of least resistance, so systems drift toward it unless the narrow path is made easier than the broad one.
Does least privilege apply to AI agents?: Yes, and NIST's definition already covers it: it speaks of processes acting on behalf of users, not only of people. An agent should hold the minimum set of tools and permissions its task requires. OWASP's LLM06, excessive agency, is the name for what happens when it does not.

Sources

NIST Computer Security Resource Center glossaryThe definition quoted above, sourced from CNSSI 4009.
Saltzer and Schroeder, The Protection of Information in Computer Systems (1975)The paper the principle comes from.
OWASP Top 10 for LLM Applications: LLM06, Excessive AgencyLeast privilege restated for AI agents.

Last reviewed 13 July 2026.

None of this needs a credential on your laptop.

Spellbook packages the dangerous operations so the people who run them hold nothing. It is not open yet.

Join the waitlist