Least privilege (principle of least privilege)

That sounds trivial and is still violated in most companies. The developer keeps their production access after the project, the reporting tool runs with database admin rights, the new cloud service gets full access "for now". Each of these deviations is harmless on its own. Together they form the room for manoeuvre that an attacker, a faulty script or a manipulated AI agent later exploits. Least privilege limits that room and with it the damage that is possible at all when something goes wrong.

Origin and definition

The principle was formulated in 1975 by Jerome Saltzer and Michael Schroeder in their paper "The Protection of Information in Computer Systems". There it appears as one of eight design principles for secure systems, alongside principles such as fail-safe defaults, economy of mechanism and complete mediation. The core statement: every program and every user should operate with the smallest set of privileges necessary to complete the job. Saltzer and Schroeder justify this not only with attacks but also with mistakes. Whoever may do little can do little wrong, and when damage occurs, the circle of suspects is small.

The US standards institute NIST puts the principle like this today: a security architecture should be designed so that each entity is granted only the minimum system resources and authorisations it needs to perform its function (NIST SP 800-53 Rev. 5). Three dimensions are contained in this wording:

• Scope: which objects may the subject see or change at all? An accounting process needs no access to personnel files.
• Depth: which operations are allowed? Reading is different from writing, and writing is different from deleting or configuring.
• Duration: how long does the right apply? Access for a migration at the weekend should no longer exist on Monday.

The third dimension is the one most often forgotten in practice. Rights are granted but rarely collected again. A permission concept that only governs the moment of granting is therefore only half finished.

Distinction from related terms

Least privilege is a principle, not a procedure. It says what should be achieved, not how. Several concepts implement it or build on it:

• RBAC (role-based access control): rights are assigned not to individual people but to roles. A "purchasing" role bundles exactly the permissions that buyers need. RBAC is the most common tool for making least privilege manageable at all in business software. It does not guarantee the principle, though: a role cut too broadly violates it just as much as an individual account with too many permissions.
• Need-to-know: the older sibling from the protection of classified information. Anyone who does not need a piece of information for their work does not learn it, regardless of their level in the hierarchy. Least privilege transfers this idea from information to actions.
• Zero Trust: an architecture philosophy that no longer regards any network segment or device as trustworthy. Every access is checked individually. Least privilege is one of its supporting pillars: if every request is authorised anyway, the authorisation can also be narrow.
• Just-in-time access (JIT): elevated rights are granted only at the moment they are needed and withdrawn automatically after a short time. At rest, the administrator has no admin rights but requests them for a specific task, ideally with a justification and a log. JIT solves the duration problem that RBAC alone does not address.

Implementation in software and the cloud

In modern system landscapes, the principle appears in four places where it is decided in concrete terms.

IAM policies in the cloud. Whether AWS, Azure or Google Cloud: permissions are written as policies that allow or deny actions on resources. The temptation to work with an asterisk, meaning "all actions on all resources", is great. Least privilege demands the opposite: one policy per function, with explicitly named actions and resource identifiers that are as narrow as possible. Cloud providers now ship analysis tools that log unused permissions over weeks and suggest how to cut them back.

Scopes in OAuth. When an application accesses a third-party API on behalf of a user, scopes define what it may do. A calendar tool that is supposed to read appointments needs no scope for deleting emails. Users see these scopes in the consent dialogue when connecting, but rarely read them. For providers this means: request the smallest possible scopes and ask again later rather than demanding full access from the start.

Service accounts. Technical accounts under which services run are the classic place for runaway rights. One service account per service, with its own key and its own policy, is mandatory. The shared "svc_app" account used by five applications makes any tracing impossible and passes the rights of the most demanding application on to all the others.

Container and process rights. A container that runs as root, with write access to the host file system and without resource limits, removes the isolation that containers are actually supposed to provide. Non-privileged users in the image, read-only file systems, capability drops and network policies between services are the container version of least privilege. The same applies on the database side: the application user does not need GRANT ALL, but SELECT, INSERT and UPDATE on exactly the tables it touches.

The use case in 2026: AI agents

With AI agents that run permanently, read mailboxes, operate browsers and call tools, the fifty-year-old principle gains new urgency. An agent is a subject like any other, with one difference: it makes decisions on the basis of text it receives from outside. This is exactly where prompt injection comes in. A prepared email, a manipulated web page or a comment in a document can slip the agent instructions that it treats as legitimate. The OWASP Top 10 for LLM applications therefore list "excessive agency" as a risk of its own alongside prompt injection: a model entrusted with too many tools with too wide rights does correspondingly great damage when something goes wrong.

The consequence is sobering and clarifying at the same time: according to the current state of knowledge, prompt injection cannot be reliably prevented. What can be controlled is the scope of the agent's rights. It determines the blast radius. An agent that may only read can at most disclose information after a successful injection. An agent with sending, booking or payment rights can act. For agents, least privilege is therefore not a compliance footnote but the most important security decision of all.

How the major providers implement the principle

The three always-on agents that came onto the market in 2026 deal with this question differently. Their documentation is revealing because it shows where the manufacturers themselves see the limits.

OpenAI Dots works with so-called custom rules. For each type of action, the user sets one of four levels: "Take action without asking", "Take action if pre-approved", "Ask before taking action" or "Hand off to you". According to the OpenAI help centre, the agent's proactive background research is limited to reading and suggesting; decisions that require judgement are handed back to the user. Each Dot runs on its own cloud computer, and access to local devices is disabled by default. This is least privilege as a configuration model: the default is narrow, and widening it is a conscious decision.

Meta Muse relies on an architectural separation. Each user gets their own isolated virtual machine. On the same machine runs a separate process called Sentinel, separated from the agent at system level, which checks every outgoing action against the user's permissions. If an action needs approval, the request goes directly to the user's device, not via the language model. The idea behind it is exactly that of Saltzer and Schroeder: the instance that decides whether an action is allowed must not be the same one that could be manipulated by an injection. That internal testers documented before the launch how an agent bypassed guardrails and exposed private photos shows at the same time that architecture alone is no guarantee.

xAI Grok Bot takes the opposite route and is remarkably open about it. All bots of a user account share one cloud computer. The xAI documentation states literally: "Do not use separate Bots as a security boundary." Files, browser sessions and credentials are reachable for all bots of the account. That is why xAI advises not to put secrets, customer data or internal URLs into a bot that is shared, to log out of services as soon as they are no longer needed and to remove temporary files after the work. The sentence "An approval controls the proposed action. It does not reverse work already completed" sums up the limits of after-the-fact approvals precisely. For companies this means: anyone who wants to run Grok Bots with different levels of trust needs separate accounts, not separate bots.

What all three approaches have in common is that they use approvals as a control point. The difference lies in who enforces the control point and how small the unit is that gets isolated: an agent, a user or an account. The smaller the unit, the closer to the principle.

Example: permission matrix for an assistant agent

Anyone introducing an agent in a company should draw up a matrix before the first connector. It forces a decision for every system and every operation, instead of granting full access and hoping for good behaviour. A possible result for an agent that supports the management with correspondence and order tracking:

The matrix is a tool, not a final state. It becomes shorter when it turns out that the agent never uses certain rights, and it is reviewed when the agent gets new tasks. The order is important: first the matrix, then the connectors. The other way round, you end up asking which rights you can take away from the agent again, and experience shows that this question is asked less often.

Common mistakes

Violations of the principle almost always follow the same patterns, regardless of technology and company size.

• Admin rights out of convenience. An access fails, nobody has time to research the exact permission, so the account gets administrator rights. The problem disappears, and the account keeps the rights forever. The mistake costs nothing until it costs everything.
• Shared service accounts. One technical account for several applications means that the compromise of one application drags all the others with it. In addition, the log no longer shows which application triggered an action.
• Rights that are never revoked. Employees change departments, service providers finish projects, pilot phases expire. The associated permissions remain. Without regular recertification, every company's stock of rights grows monotonically.
• Full access for integrations. A new SaaS tool is connected, the consent dialogue requests twelve scopes, and all of them are confirmed. Nobody has checked whether the tool would need three of them for its function.
• Isolation confused with authorisation. The Grok Bot case shows it: the fact that two agents have different names and tasks does not mean they have different rights. A separate identity without a separate execution environment is not a security boundary.

GDPR relevance

Least privilege is not named literally in the GDPR, but it follows directly from two articles. Art. 25 requires data protection by design and by default. Paragraph 2 expressly demands that personal data are not made accessible by default to an indefinite number of people without the individual's intervention. A permission concept that opens wide by default and restricts on request goes against this idea. Art. 32 obliges controllers to take technical and organisational measures appropriate to the risk and explicitly names the confidentiality of systems. Restricting access is the most fundamental of these measures.

For AI agents this becomes a practical issue: an agent that can access the entire mailbox, the CRM and the file storage processes personal data on a scale that hardly any record of processing activities covers. Limiting access to what is necessary not only fulfils a security principle but also keeps the data protection impact assessment manageable. Within AI governance, the agent's permission matrix is therefore a document that data protection and IT security should maintain together.

Outlook

The principle itself will not change; it has been stable since 1975. What is changing is the number of subjects to which it has to be applied. When a company runs dozens of agents in future that delegate to one another, the question of which agent may pass which rights on to which other agent becomes the central architecture decision. Short-lived, task-bound permissions that come into being with the assignment and expire with it are the obvious answer. Providers are working on intermediary layers that issue scoped tokens to agents instead of giving them permanent accounts. Anyone introducing agents today would do well to adopt this way of thinking now: rights belong to the task, not to the agent.

Frequently asked questions

Is least privilege the same as RBAC?

No. Least privilege is the goal, RBAC is a means. Role-based access control makes permissions manageable by bundling rights into roles. Whether the roles are actually cut to the minimum depends on how they are designed. A company can have fully introduced RBAC and still violate least privilege because every role may do too much.

Does least privilege slow work down?

In the short term it can seem so, because access is requested rather than taken for granted. With just-in-time procedures and cleanly defined roles, the effort is reduced to a few seconds per request. This has to be weighed against the effort of a security incident that, with wide rights, affects the entire company instead of one system. In almost all cases the calculation comes out in favour of the restriction.

Why is it not enough to instruct the AI agent well?

Because instructions are written in text and so are attacks. A language model cannot reliably distinguish whether an instruction comes from you or from an email it is currently reading. Prompt injection exploits exactly this weakness. Instructions such as "Never send without asking" are sensible, but they are not a security boundary. The boundary is drawn by the permission system, which technically does not release the send function.

Where do I start in a mid-sized company?

With an inventory of the accounts that have administrator or full rights today, including technical accounts and connected SaaS services. Then by revoking all rights whose purpose nobody can name any more. Only then is it worth building a role model. For AI agents: draw up a permission matrix before the first connector and put an approval on every write or send operation until the agent's behaviour has proven trustworthy over weeks.