Zenaique

Which practices reflect the principle of least privilege applied to an agent's tool set?

Multi-select·Medium·4.0 · 0·~1 min·Asked atBasetenLabelboxPwc·Relevant atAdobeAi21AmazonAnduril
Attempt it
TL;DR

Least privilege for agents means scoping tools to the task, sandboxing what tools can touch, and gating irreversible actions. More tools or a bigger model do not shrink the perimeter.

Memory aid
Sign in to see the mnemonic that makes this stick.
Easy to grasp

Imagine hiring a contractor to fix one window. You would not hand them keys to every room, the safe, and the company bank account just in case. You give them the one key they need, you stay nearby while they work on anything that cannot be undone, and you make sure the room they are in does not connect to places they should never reach. An AI agent is the contractor, and its tools are the keys. Least privilege means giving the agent only the keys the current job requires, fencing off everything else with locked doors, and standing by to approve anything permanent like deleting files or sending money. Handing over the whole keyring because the agent seems smart does not make the building safer. It just means a mistake or a trick can reach more rooms.

Key concepts

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 bound what the system can do to the outside world, independent of how the model reasons. The question asks which practices apply the principle of least privilege to an agent's tool set, and the deeper lesson is about where security actually lives. The answer is that it lives in the runtime around the model, not in the model itself.

Least privilege is an old idea from operating system and access control design. Grant every actor the minimum authority needed for its current task, and nothing more. For an LLM agent the actor is the loop, the authority is its tools, and the reach of each tool is the files, services, and network endpoints those tools can touch. The correct answers, task scoped registration, runtime sandboxing, and approval on irreversible actions, each constrain that authority. The two distractors either expand it or try to substitute model capability for a permission boundary.

The reason this matters so much for agents specifically is that an agent acts on the world autonomously, in a loop, often on inputs no human reviewed. A chatbot that says something wrong is embarrassing. An agent with a delete tool that is talked into using it can cause real, permanent damage. The blast radius is set by what the tools can reach, so that is exactly where the controls belong.

Two distinct layers: what can be called vs what a call can touch

The most important distinction in this question is between tool registration scoping and runtime sandboxing. They are easy to conflate but they operate at different layers, and a serious answer treats them as complementary.

Tool registration scoping controls which tools the agent can even attempt to invoke. If a delete tool or a payment tool is never registered for a session, the model cannot call it, no matter what it reasons or what an injected instruction tells it to do. This is the first gate, and it is the cheapest to get right because it is a configuration decision made before the loop starts.

Runtime sandboxing controls what a tool that does get called can actually touch. A registered file tool might still be allowed to read and write only a single working directory, and a network tool might only reach an allowlisted set of endpoints. Sandboxing assumes the agent might call the tool with hostile arguments and contains the damage anyway.

The two layers defend against different failure modes. Registration stops the agent from reaching for the wrong category of action. Sandboxing stops a legitimately reachable tool from being abused into touching the wrong resource. A gap in one layer is often caught by the other, which is exactly why defence in depth pairs them.

A concrete way to see the difference: imagine an agent that legitimately needs a file-read tool. Registration cannot help here, because the tool genuinely belongs in the set. The danger is the argument. A path traversal argument like a parent directory escape could pull in credentials outside the working directory. Only sandboxing, which pins the tool to a single directory regardless of the path it is handed, stops that. Conversely, sandboxing cannot stop an agent from calling a payment tool it never needed. Only registration, which simply omits the tool, can. Neither layer subsumes the other.

Why a larger model is not a security control
Reversibility classification and human approval
Production hardening beyond the three core controls
Mapping each option to the perimeter
Sign in to unlock the full deep dive.

Situations where this technique stops working.

Sign in to see when this approach fails.

2–4 min · Everything important, quickly.

Sign in to see the quick scan of the deep dive.

Real products, models, and research that use this idea.

  • Anthropic's Claude computer use ships behind a sandboxed container and recommends human confirmation before consequential actions, since the desktop tool can click anything on screen.
  • Model Context Protocol servers expose typed, explicitly registered tools per session, so a client like Claude Desktop grants an agent only the tool surface a given workflow declares.
Sign in to see more production examples.

What an interviewer would ask next. Try answering before peeking at the approach.

QWhy does prompt injection make capability based defences like a smarter model fundamentally insufficient?
A

Frame the model as inside the trust boundary. If untrusted tool output can steer it, defences must be external. Discuss registration, sandboxing, and approval as controls the model cannot reason its way around.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Treating a smarter or larger model as a security control. Reasoning quality does not shrink the blast radius. An over permissioned agent stays dangerous no matter how capable the underlying model is.

Sign in to see all red flags and common mistakes.

60 second bullets to scan on the way to the call.

  • Define least privilege in terms of an agent's tools, file access, and network reach.

  • Distinguish what the agent can call from what a called tool can touch.

Sign in to unlock the revision sheet.

Primary sources. Browse if you want the original framing.

Similar questions

Same topic, related formats. Practice these next.

4 curated
Next question
What is the Model Context Protocol (MCP) and what problem does it solve?
MCQ·Easy