Least-Privilege Tooling
Give an agent the narrowest set of tools, and each tool the narrowest scope, that the task actually needs. The pattern accepts that prompt injection will sometimes succeed and bounds what a hijacked agent can do — you cannot patch the model, but you can decide what it is able to reach.
Definition
Least-privilege tooling is the practice of scoping an agent's tool catalogue, and each tool's underlying credential, to the minimum the task requires — so the consequences of a successful attack or a model error are bounded by design rather than by the model's compliance.
Problem
An agent given broad tools and broad credentials turns any successful injection, jailbreak or hallucination into a real action carrying the full reach of the account behind it.
When to use it
Use it wherever an agent can act — call APIs, write files, send messages, move money. The more autonomy and the less human review, the more the blast radius has to be set at the permission layer rather than in the prompt.
Solution
Start from the task, not from the platform. List the operations the agent must perform and expose exactly those. A catalogue assembled from 'what the API offers' is a permission grant nobody reviewed.
Split read from write: separate tools, separate credentials, and no write path reachable by an argument to a read tool. 'Query' endpoints that can also mutate are the most common quiet escalation.
Scope the credential, not only the tool. A read-only tool backed by an admin token is one bug away from being a write tool; issue per-tool credentials at the narrowest scope the upstream system supports.
Bound the parameters. Allowlist the paths, repositories, tables, accounts or recipients a tool may address, so a hijacked agent cannot repoint a legitimate tool at an illegitimate target.
Make grants expire and be reviewed. Tools accumulate; remove what nothing has called, and treat adding a tool as the permission change that it is.
Log the grant and the call separately. What the agent could do and what it did are two different audits, and an incident needs both.
Components
Benefits
- Bounds the damage of a successful injection without depending on the model behaving well.
- Turns 'is this agent safe?' into a reviewable artefact: a list of tools, scopes and owners.
- Improves tool-selection accuracy as a side effect — fewer, sharper tools are easier for a model to choose between.
- Makes incidents investigable, because the reachable set was known before the incident.
Risks
- Scope creep by convenience: a broad token pasted in while debugging and never narrowed afterwards.
- Fragmentation: dozens of hair-thin tools the model cannot distinguish, trading a security win for a reliability loss.
- False comfort. Least privilege bounds consequences; it does not prevent the attack, and it says nothing about exfiltration through a legitimately granted read tool.
- Process drag: if issuing a scoped credential is harder than reusing a broad one, the process itself becomes the vulnerability.
When not to use it
- Prototypes on synthetic data with no production reach, where the ceremony costs more than the risk it removes.
- When the upstream platform cannot express scopes at all — then the control moves to a proxy in front of it, rather than being declared satisfied.
- When narrowing the agent would push the work onto a human path that is itself less bounded and less audited.
Technologies
Examples
- A coding agent given a repository token scoped to one repository and one branch prefix, with no organisation-wide read. An injection through a dependency README can still open a branch; it cannot reach the other forty repositories.
- A support agent whose CRM tools are split: read_customer with a read-only key, and update_ticket restricted to tickets already in the conversation. A hijacked session can annoy one ticket, not export the customer base.
- A public MCP server whose entire catalogue is getters over already-published content, backed by no credential at all — there is nothing to revoke because there is nothing to leak.
Production evidence
- Context
- The public MCP endpoint for this knowledge base, reachable by any agent on the internet.
- Scenario
- The corpus is public and read-only, so the catalogue is entirely getters. There is no tool that writes, no tool that reaches a database the site does not already publish, and no credential reachable from any tool.
- Technology
- Stateless JSON-RPC over HTTP on a Next.js route handler, origin allowlist checked before any handler runs, per-caller rate limiting in Redis, structured per-call audit logging.
- Load
- Continuous unattended agent traffic since launch, plus registry crawlers and directory health checks.
- Results
- A client of this server that is hijacked by prompt injection can obtain nothing it could not have fetched from the public site, because the reachable set is exactly the published corpus. There is no credential to revoke and no write path to abuse.
KPIs
- Tools per agent
- The size of the catalogue. Growth without removals is the signal that grants are accumulating unreviewed.
- Write-capable tool share
- How much of the catalogue can change state. The number worth driving toward the minimum the task allows.
- Age of the oldest unused tool
- Days since a granted tool was last called. An old unused grant is reach nobody needs and an attacker inherits.
- Scope documentation coverage
- Share of tools with a written scope and a named owner. An undocumented tool is an unbounded one.
Observed failure modes
- The admin token behind the read-only tool: scope declared at the tool layer, unbounded at the credential layer.
- Parameter repointing: the tool is legitimate and the target is not, because nothing constrained the argument.
- Confused deputy: narrowing the tools without narrowing whose authority they run under changes nothing, because the caller still inherits the agent's reach.
- Catalogue drift: tools added for an experiment stay, and the permission set that was reviewed is no longer the one deployed.
Lessons learned
- Write down the blast radius before granting the tool, not after the incident.
- A tool's name is not its scope. Only the server-side credential is.
- Removing a tool nothing calls is the cheapest security work available.
- Least privilege pays twice: it bounds attacks, and it makes the agent choose tools better.
FAQs
- Does least privilege stop prompt injection?
- No, and it is not meant to. It assumes injection will sometimes succeed and decides in advance what a successful one can accomplish. Prevention and containment are different jobs; only containment is under your control.
- How narrow is too narrow?
- When the model can no longer tell two tools apart, or when a routine task needs four calls that could safely have been one. Splitting improves security until it starts producing wrong tool choices, and a wrong call is its own failure.
- We use one service account for everything. Is that so bad?
- It means every agent, and every attacker who reaches one, has the reach of the widest task any of them performs. One account is the version of this pattern where the blast radius is 'all of it'.