Agent Security & Least Privilege, Explained

What securing an agent actually means

An agent is a model that can take actions in the world through tools: query a database, send an email, run a shell command, call an API, move money. Securing it is not primarily about making the model behave; it is about bounding what the model is physically able to do. If the agent has no delete tool, no amount of clever prompting, model error, or injected instruction can make it delete anything. Security lives in the capability grant, not in the hope that the model stays well-behaved.

That reframes the whole problem. The question is never 'how do I stop the agent from misusing this powerful tool?' but 'does the agent need this tool at all, and if so, in what narrowest possible form?' You design the agent's power surface first and treat every control on top as a second line of defence, never the first.

Capability bloat is the root risk

Capability bloat is the slow accumulation of tools, scopes, and access an agent picks up because they were convenient, or because a single service account already had them, or because nobody wanted to file a second permission request. Each addition is a compounding liability, and the danger is that most of it is never exercised in normal operation, so it draws no attention until it is abused.

• Every tool is attack surface. A tool the agent never legitimately needs is still callable by a prompt injection, a hallucinated plan, or a logic bug. Unused power is not harmless; it is dormant risk.
• Every broad scope is blast radius. An agent holding write access to an entire database can, in a bad moment, damage all of it. The same agent scoped to one table can only ever harm that table.
• Bloat is invisible until it fires. A read-only reporting agent that also happens to carry admin credentials looks fine on every good day and becomes a catastrophe on the one day it is steered.
• Convenience credentials are the usual culprit. Reusing one high-privilege service account across many agents means any single compromised agent inherits the union of everything that account can touch.

Least-privilege tool scoping in practice

Scoping is not a single yes/no on whether the agent gets a tool. It is a set of dimensions you narrow independently until the grant matches the task and nothing wider. Start from zero and add back only what a concrete task step demonstrably requires.

The identity row is the one teams most often get wrong. An agent that acts under a shared admin account sees everything and can do everything, and its actions cannot be attributed to a real user. An agent that carries the signed-in user's delegated credential is automatically bounded by that user's own permissions, enforced by the downstream system, with no extra policy code required.

The confused-deputy trap

A confused deputy is a program that holds more authority than the person driving it, and can be tricked into using that authority on the attacker's behalf. An agent is a textbook deputy: it carries broad credentials, and it takes instructions from inputs, retrieved documents, and tool results that may be attacker-controlled. When a hidden instruction in a fetched web page or a poisoned record persuades the agent to act, the agent's privileges, not the attacker's, are what execute.

This is exactly why over-permission is so dangerous in an agent specifically. The confused-deputy attack does not need to defeat your guardrails; it borrows the agent's own legitimate authority. The only durable defence is to ensure the deputy never held excessive authority in the first place. An agent scoped to one user's data, acting as that user, has nothing extra to be tricked into exercising.

Sandboxing agent actions

Some tools are inherently powerful in ways you cannot fully enumerate in advance, most obviously code execution and shell access. For these, least privilege takes the form of a sandbox: an execution environment deliberately stripped of everything the task does not require, so that even arbitrary code the agent runs is bounded by the walls around it.

• Isolate the runtime. Run agent-executed code in an ephemeral, disposable container or VM, not on a host that shares its filesystem or secrets with production.
• Deny network by default. An agent that only needs to transform local data should have no outbound network, which removes exfiltration and callback paths entirely.
• Mount only what is needed, read-only where possible. The sandbox should see the one dataset for the task, not the whole disk or the whole bucket.
• Strip ambient credentials. Environment variables, cloud instance roles, and mounted secret files are all things injected code will look for; a clean sandbox has none of them.
• Make it ephemeral. Tear the environment down after the task so nothing persists or accumulates state across runs.

Human gates and blast-radius containment

Some actions cannot be scoped to zero because the task genuinely requires them, and some of those are irreversible: sending money, deleting records, emailing a customer, deploying to production. For these, least privilege is complemented by a human gate, a mandatory approval step where a person sees the fully resolved action and its concrete parameters before it executes.

The gate must be deterministic and driven by policy, not by the model's judgement about whether an action is risky. Fixed conditions, the action is irreversible, the amount exceeds a threshold, the recipient is off the allow-list, decide when a human is required, evaluated in your code where an injection cannot dissolve them. Pair gates with blast-radius containment so that even an approved-and-then-wrong action is bounded.

• Human approval on irreversible or high-impact actions, showing the resolved action ('Delete 1,240 rows from orders?'), never a vague summary.
• Rate limits and spend caps so a runaway loop or repeated injection cannot compound into a large loss before anyone notices.
• Short-lived, narrowly-scoped credentials so a leaked token expires fast and unlocks little.
• Per-user data isolation enforced server-side, so the worst case for one compromised session is that one user's data, not everyone's.
• Full audit logging of every tool call with its parameters and the acting identity, so containment can be verified and incidents reconstructed.

Why removing a tool beats guarding it

This is the crux, and the exam's favourite trap. Faced with a risky capability, the tempting answer is to keep it and add a control: a system-prompt rule saying 'never do X', an output filter, a classifier that watches for misuse. The stronger answer is usually to remove the capability so there is nothing to guard. A control sits in the request path and can fail, be bypassed, be injected around, or simply be wrong. An absent capability has no failure mode, because the power was never there to leak.

So when a question offers you 'add a guardrail / add an approval prompt / add a policy instructing the model not to' against 'remove the tool / narrow the scope / drop the credential,' the least-privilege answer is the one that reduces what the agent can do. A prompt instruction telling the model not to use a dangerous power it still holds is the weakest option of all, because it relies on the very component you cannot trust under attack, the model, to police itself.