Least Privilege Matters More When the Actor Can Be Steered by Its Inputs

Least privilege is old advice. Scope every component to the access its own work demands and withhold the rest, so that a compromise anywhere stays confined to what that one component could already reach. The principle has governed the design of operating systems, service accounts, and API credentials for decades, and every senior engineer already believes it. With autonomous systems the principle still holds; what changes is the stakes. In ordinary software, the code holding a permission does a fixed, auditable thing with it. In an agent, the thing wielding the permission is a model whose behavior is shaped in part by inputs it does not control and cannot fully be trusted to interpret safely. A permission granted to an agent is therefore not a permission held by your code. It is a permission held by whatever can influence the model’s next decision, including the contents of a document it was asked to summarize or a web page it was asked to read.

That shift is why least privilege moves from good hygiene to a structural requirement the moment a system becomes agentic. Each tool you grant an agent is a capability an attacker can attempt to reach through the model, by getting adversarial instructions in front of it. You cannot prevent the model from occasionally being steered wrong, because being steerable by natural-language input is the property that makes it useful in the first place. What you can decide, entirely at design time, is how much damage a wrong step is able to do. Least privilege is the mechanism for that decision: it does not stop the model from making a bad call, but it bounds what that call can touch.

A tool grant is a permission an adversary can reach

The clearest way to see the tool layer is to treat every tool definition as a trust boundary: a specific set of operations the model is authorized to perform on the user’s behalf once it decides to invoke that tool. The schema fixes what arguments the call accepts. The handler fixes which systems the call reaches and what it is permitted to do there. Together they define, exactly, the scope of what the model can cause to happen through that one tool. Nothing more, and nothing less, is on the table when the tool fires.

Framed that way, a loosely defined tool is a broad grant of authority. A tool that accepts freeform input and connects to everything hands the model, and by extension anyone who can influence the model’s outputs, a wide and poorly controlled surface. The canonical illustration is a single tool that takes an arbitrary query string and runs it against a database with full credentials. In normal use it works and feels convenient. Under adversarial conditions it is a liability, because an attacker who can get instructions in front of the model, through a poisoned document or an injected web result, can potentially redirect that one tool to read, alter, or destroy data it was never meant to touch. The tool did exactly what it was built to do. The problem is that what it was built to do was almost anything.

This is the confused deputy problem, arriving at a new scale. A deputy acts with its own authority on instructions from someone else, and the classic risk is that it can be talked into misusing that authority. An agent is a deputy that takes instructions from a channel you do not fully control, carrying whatever authority its tools grant. The defense has always been the same: give the deputy no more authority than its task strictly needs, so that even a fully misled deputy cannot do much harm. For an autonomous system, that defense stops being optional polish and becomes the only durable line, because the assumption that the deputy will always interpret its instructions correctly is exactly the assumption you cannot make.

An agent’s reach is the sum of what its tools can touch

Once a tool is understood as a bounded grant, the security posture of an entire agent becomes legible. The worst thing an agent can do if it is fully subverted is the union of everything its tools can touch, and that union is its true attack surface. Every capability you add to the set enlarges it. So the design question for each tool is not only whether it is useful, but how much it widens the worst case, and whether that width is necessary.

Applying least privilege at this layer starts from a single rule: each tool carries the authority for one operation and no more of the surrounding system than that operation genuinely touches. A tool built to retrieve holds no power to mutate. A tool that speaks to a single datastore authenticates only against that store, never the wider backend. A tool that reaches into the filesystem is confined to the paths its work names rather than handed the tree. Each such constraint shrinks the union. Whether a tool is turned against its purpose by an adversarial prompt or by a breach of the service sitting behind it, a narrow scope is what keeps the fallout local.

The broad-versus-narrow contrast is where the discipline earns its cost. Replacing one permissive query tool with several specialized ones does more than tidy the interface. The permissive tool grants, through a single call, access to everything the credentials behind it can reach. The specialized set grants only what each operation needs, with a distinct tool for each table it must serve, every one limited to constrained filter arguments and carrying credentials that reach nothing beyond its own purpose. If any one of them is abused, the containment is a structural fact rather than a hope, because that tool never had the reach to do more. The broad tool is convenient to build and dangerous to operate. The narrow set is more work to design and safe as a matter of structure, and for anything deployed against real data that trade is not close.

The model cannot be trusted to respect a boundary it can merely see

A recurring mistake is to encode a boundary the model is expected to honor rather than one the system enforces. Instructing an agent to only read and never delete, or to stay within a certain directory, is a description of desired behavior, not a constraint on actual behavior. The model will usually comply. Usually is precisely the word that has no place in a security boundary, because the entire threat model is the case where the model does not do the expected thing. A boundary that holds only when the model cooperates is merely a suggestion, and adversarial input exists specifically to override suggestions.

Real enforcement lives below the model, in layers it cannot argue with, and the sound designs stack several so that each catches a class the others miss. The first layer is the schema itself. Declaring an argument as a strict enumeration rather than an open string means the boundary rejects any value outside the approved set before the handler ever runs, which removes the model’s ability to craft an arbitrary downstream instruction through that field. The second is grants declared at the integration layer, where a tool is told which paths or resource prefixes it may address. A caution belongs here: such protocol-level grants are frequently advisory, a declaration the server is expected to honor rather than one the runtime forces, so they must be backed by enforcement that genuinely cannot be bypassed, at the level of filesystem permissions, database roles, network policy, or container mounts. The third layer is authorization logic in the handler, which checks the caller’s identity and permissions against the specific resource before touching it, after the schema has already validated shape. Depth matters because the layers fail differently. A schema constraint cannot know who is calling; an identity check cannot catch a malformed argument. Run together, they close the gaps each would leave alone.

The essential idea across all three is that the constraint has to sit somewhere the model does not author. Anything the model can regenerate on the next turn, it can be steered into regenerating differently. Only a constraint the model cannot rewrite actually constrains it.

Nothing crossing the boundary has earned trust yet

The server boundary, the point where a tool call crosses from the nondeterministic model into deterministic systems, is where inputs must be treated as hostile no matter how they were labeled on the way in. Two distinct reasons converge here. The first is that the schema guides the model’s generation but does not, on its own, guarantee the model’s output conforms. Unless the platform actively constrains generation to the schema, the model can emit a wrong type, omit a required field, or produce a value the schema was meant to exclude, so the handler cannot assume well-formed input just because a schema was declared. The second reason is deeper and independent of the model: an argument that is perfectly valid as a value can still be an attack on whatever the tool talks to next. A string that satisfies every type constraint can still carry a path-traversal sequence, a shell metacharacter, or a wildcard that means something dangerous to the system underneath.

So validation at the boundary is two jobs, not one. Validate shape against the declared schema, rejecting anything that does not match. Then sanitize content for the specific system the value is about to enter, escaping or refusing the characters that carry meaning there. An argument with no length ceiling belongs in the same pass, since it opens the door to resource exhaustion and to overflow conditions deeper in the stack. This is the last point at which malformed or malicious input can be stopped before it reaches production systems, and it has to be code that runs unconditionally, not a behavior the model is asked to perform on itself.

What a tool returns is also part of the grant

Scoping the call is only half of the boundary. What a tool sends back is equally a permission, and it is the half most often left open. A tool that returns raw rows and relies on the host application to filter them has not been scoped to what the caller may see; it has been scoped to what the query happened to select, and the difference is every record the caller had no right to. The filtering has to happen inside the tool, against the caller’s actual authorization, before the data leaves the boundary.

For an autonomous system this is sharper than ordinary output hygiene, because a tool’s return value does not merely reach a user interface. It enters the model’s context and becomes material the model reasons over and may surface in later output. Data the tool over-returns is data the agent now holds and can be induced to leak, through a summary, a follow-up call, or a response to a later injected instruction. Returning only what the caller is authorized to see does more than satisfy access control. It keeps unauthorized data out of the one place, the context window, where the model’s steerability turns a quiet over-share into an exposure.

The failures that look harmless in development

A few scoping mistakes recur across autonomous systems, and they share a signature: each is invisible in a development environment and expensive in production. The costliest is a single backend identity shared across every tool on a server, because then the compromise of any one tool inherits the reach of them all, dissolving the very containment that per-tool scoping was meant to buy. The quietest is unscoped output, where results leave the boundary carrying whatever the query happened to select, including records the caller had no right to see. The most common is the open schema, a freeform field standing in for a closed set of choices, which leaves the model free to compose arbitrary downstream instructions through an argument that should only have offered a menu.

None of these throws an error in testing. Each feels like a reasonable simplification while the system is small and the data is fake. Each becomes a standing liability the moment the system runs against real infrastructure and real adversaries. The reason to fix them at design time is not only that fixing them is cheaper than remediating them later, though it is. It is that they are decisions, not bugs, and a decision made once during design is far easier to make correctly than a pattern retrofitted across a tool layer that has already grown around it.

Least privilege and a lean toolset are the same discipline seen from two sides

There is an apparent tension worth resolving directly, because it is the objection a careful reader raises immediately. Splitting one broad tool into several narrow ones adds tools, and a larger toolset carries its own costs: every tool description sits in the model’s context on every turn, and near-duplicate tools make routing less predictable. So does least privilege fight against keeping the toolset small?

It does not, once the axis is named correctly. The variable that matters for security is authority per tool, not the raw count of tools. You narrow a broad tool when its authority genuinely exceeds what any single operation needs, replacing one wide grant with a few tightly scoped ones that each do exactly one job. You do not multiply tools that all share the same scope and differ only in surface, which buys no containment and pays the full context and routing cost. The two disciplines are the same act viewed from two angles. Scoping by authority tends to produce a toolset of specialists, each doing one thing with the minimum access that thing requires, and a set of clean specialists is both the safest arrangement and the most legible one to route across. When narrowing a tool and shrinking the toolset appear to conflict, the resolution is almost always that a near-duplicate crept in: the fix is a sharper boundary between the tools, not a broader grant inside one of them.

The other cost of the discipline is honest and worth stating. Least privilege is more design work up front. It asks you to answer, for every tool, not only what it should do but what it should be forbidden to do, and to push that answer down into schema, credentials, and enforcement rather than into an instruction. That effort is the price of an auditable system, one whose worst case you can state precisely because you drew every boundary on purpose. The alternative is a tool layer whose blast radius no one can quite describe, assembled from grants that each seemed harmless in isolation.

You bound the damage before it happens, or you do not bound it at all

The decisive property of least privilege for autonomous systems is when it takes effect. The scope of every tool is fixed when the agent is configured, long before any particular call, and it cannot be tightened afterward by prompting the model to be more careful. By the time a tool fires, the authority it carries was already granted; the only question the runtime answers is whether this specific call falls inside a boundary that was drawn earlier or outside one. If the boundary is wide, no instruction to the model closes it, because the model is the very thing the boundary exists to contain.

This is what makes least privilege the load-bearing discipline of the tool layer rather than one precaution among several. The goal was never to guarantee the model behaves, which is not achievable for a system whose usefulness depends on being steerable by language. The goal is to ensure that when the model is steered wrong, and across a long enough operating life something will steer it wrong, the damage is capped at what one narrow tool could reach. An agent built that way is not a system you have to trust to be safe. It is a system whose worst case you have already bounded, deliberately, at the only point where bounding it was ever possible.