Explain the principle of least privilege applied to an agent's tool set. What specific risk does over permissioning create, and what two threat vectors does it amplify?
Least privilege gives the agent only the tools the current task needs, which shrinks both the prompt injection blast radius and the damage an honest mistake can cause.
Imagine hiring a contractor to paint one room. You would not hand them the keys to the whole house, the safe, and your bank card. You give them the key to that one room and nothing else. If they turn out to be dishonest, or if they simply make a mistake, the worst they can do is mess up the paint. An agent is the same. Every tool you register is a key you hand it: read files, delete files, send email, spend money. The model decides which keys to use, but the model can be fooled by hidden instructions in the things it reads. So you only hand over the keys the job truly needs, and you take them back when the job is done. Fewer keys means a tricked or confused agent can do far less harm.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
An agent's security perimeter is the set of controls that decide what damage the system can do, independent of what the language model wants to do. This distinction is the whole point. The LLM is an untrusted decision maker. It reads text from the outside world, and that text can carry instructions an attacker planted. So you cannot make the model the security boundary. You make the architecture around it the boundary.
Least privilege is the load bearing piece of that perimeter. It says the agent is granted only the tools the current task needs, and those grants are as narrow as possible. The reason it carries so much weight is simple. The set of tools you register is the exact set of actions any compromise or any mistake can reach. Shrink that set and you shrink the worst case directly, with no dependence on the model behaving well.
The rest of this explanation walks the full perimeter. We start with why the tool list, and not the prompt, is the real boundary. We name the two threats that over permissioning amplifies. Then we layer the remaining controls and close on why containment and audit matter once you accept that prevention will never be perfect.
Why the tool set is the boundary, not the prompt
A naive mental model treats agent safety as a prompting problem: write a careful system prompt, tell the model not to do dangerous things, and trust it. This fails because the model's instructions and its untrusted input share the same channel. Text the agent retrieves can override the system prompt through prompt injection, the number one risk in the OWASP LLM Top-10.
The correct mental model is that the registered tool set defines the action space, and nothing the model decides can exceed it. If a delete tool is not registered, no injection and no confusion can delete anything. This is why least privilege is an architecture control rather than a behavioral one. A behavioral control depends on a probability, namely how often the model complies. An architecture control changes what is possible, so its guarantee holds even against an adversary who fully controls the model's input.
This also explains a counterintuitive fact about model quality. A more capable model follows instructions more precisely, including injected ones, so improving the model does not shrink the blast radius. It can widen it. The tool scope is the only control that gets safer as the model gets better, because it does not depend on the model at all.
The practical rule is to scope tools per task, not per agent. An agent that serves many request types should not carry the union of all tools any request might need. Register only the tools the current task declared, execute, then unload them. A simple pattern is a per task tool registry that loads an allowlist on entry to a task phase and clears it on exit, logging each registration. The unused but registered tool is pure downside: it adds risk and buys nothing for the task at hand.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Anthropic's Claude computer use and Claude Code run tools in restricted environments and gate destructive or high blast radius actions behind explicit user confirmation rather than trusting the model.
- Model Context Protocol servers expose tools with declared scopes, letting a host register only the specific MCP tools a task needs and revoke the rest.
What an interviewer would ask next. Try answering before peeking at the approach.
QAn agent legitimately needs a delete tool for some tasks but it is too dangerous to leave always on. How do you design the gate?
Classify actions by reversibility and blast radius, then route irreversible ones through a human approval or a confirmation tool. Pair it with dynamic registration so the delete tool only loads for tasks that declared they need it, and log every approval decision with the requesting identity.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Treating least privilege as a model behavior problem. It is an architecture control. The set of tools registered bounds the damage no matter what the model decides to do.
60 second bullets to scan on the way to the call.
Define least privilege as task scoped tool access, not per agent grants.
Name the two amplified vectors: injection blast radius and accidental runaway.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.