Grant only what the task needs.
Every person, program, and AI agent should get only the access its job requires, and only for as long as it needs it. Less access means a smaller blast radius when something goes wrong, and fewer frightening choices for the people asked to grant it.
Jerome Saltzer stated the principle in 1974: every program and every privileged user of a system should operate with the least privilege needed to complete the job. In 1975 he and Michael Schroeder made it one of the design principles for protecting information in computer systems, building on work such as Roger Needham’s 1972 discussion of granting privileges dynamically.
Early Unix put it into practice: its login program started with superuser rights and gave them up the moment they were no longer needed. The same idea now runs through user accounts, app permissions, OAuth scopes, and the tools given to AI agents.
The principle of least privilege says that every user, process, or program should be able to access only the information and resources needed for its legitimate purpose. For design, it means asking for less, asking at the moment it matters, and making ordinary, limited access the default.
Saltzer’s rule is simple: every program and every privileged user should operate with the least privilege needed to finish the job. A backup account can run backups; it doesn’t need to install software.
Early Unix’s login program started with superuser rights and gave them up as soon as they were no longer needed. Grant elevated access at the last possible moment, and take it back right after.
A 2012 study found that only 17 percent of Android users paid attention to permissions at install time, and just 3 percent could answer all the comprehension questions. Ask for access in context, when a feature needs it, and say why.
Sign in with basic access first, and ask for more only when someone reaches a feature that needs it. Incremental authorization keeps the first request small and easy to agree to.
In a 2010 study of Windows users, all 45 participants worked in administrator accounts, and 91 percent didn’t know the benefits of low-privilege ones. Make limited accounts the default and elevation easy, so people aren’t pushed to run as admin.
The same study found that 69 percent of participants didn’t respond to Windows’ elevation prompts correctly. When prompts appear constantly, people approve them by habit, so keep them rare and tied to clearly consequential actions.
Giving someone read-write access when read access would do violates least privilege. Build roles such as viewer, editor, and admin around real jobs, and default new members to the most limited one that works.
Predicting exactly what access a program or person will need is impractical, so the access actually granted usually exceeds the true minimum. Remove what is clearly unnecessary, then review and revoke over time.
AI agents read data, call tools, and act for people. Every tool and permission they hold is something a mistake or a malicious prompt can use.
OWASP lists excessive agency, meaning too much functionality, permission, or autonomy, as a top risk for LLM applications. Give an agent only the tools and data its task requires, with the narrowest permissions that work.
Let agents act on their own within narrow bounds, and pause for a person before anything consequential or hard to undo, such as payments, deletions, or messages sent on someone’s behalf.