Capability Scoping and Least Privilege
Day 24 gave you the principle, information flow control, forbid untrusted data from reaching a privileged action. Today is the most practical, highest leverage way to enforce it, and the one defense you should reach for first on any real agent: capability scoping. Shrink what the agent can reach until a landed injection, which you now assume always happens, grabs nothing worth having.
If dual LLM is the elegant architecture and information flow is the governing principle, capability scoping is the workhorse. It is the cheapest to apply, it needs no second model, and it downgrades more findings per unit of effort than anything else. On most assessments, it is the single recommendation that matters most.
The idea: least privilege, applied to agents
Least privilege is the oldest principle in security. A component should have exactly the access it needs to do its job, and nothing more. We apply it to users, to services, to processes. Agents have been the glaring exception, because teams hand them broad access for convenience, one powerful token, every tool enabled, access to everything the user can reach, so the agent can handle whatever comes up.
That convenience is the vulnerability. Every attack in this series was amplified by the agent having more reach than the task needed. The confused deputy worked because the token was broad. Cross customer theft worked because the lookup tool could read anyone. The GitHub case worked because the token spanned public and private. In every one, scoping the capability down would have shrunk the breach to nothing or near nothing.
State it as the rule: the blast radius of a compromised agent equals its capabilities. Shrink the capabilities, shrink the blast radius. Since you cannot stop the compromise, this is where the leverage is.
The three dimensions to scope
Capability scoping is not one knob. It is three, and you tune each.
Scope the reach, what data and actions the agent can touch. This is the big one. Bind every privileged tool to the minimum it needs for the current task, derived from trusted context, not from attacker influenced input. The Day 11 fix, generalized: lookup_customer bound to the ticket owner, create_refund bound to the ticket customer and a ceiling, every tool reaching only what this task requires.
Scope the identity, who the agent acts as. Instead of one broad service token for all users, the agent should act with the current user’s privileges, so its reach is naturally limited to what that user could do anyway. This removes the union of all access problem at the root. A compromise then gets the attacker only the current user’s access, not everyone’s.
Scope the toolset, what capabilities exist at all. The agent should only have the tools the task needs, not every tool someone might someday want. A support agent that never issues refunds should not have a refund tool loaded. Every tool present is attack surface, even unused ones, because an injection can invoke it. Fewer tools, fewer sinks.
Tune all three and the agent that was a skeleton key becomes a single purpose instrument that can touch only this task, as only this user, with only these tools.
Why this is the highest leverage defense
Three reasons it beats the alternatives for practical impact.
It downgrades many findings at once. A broad token is the amplifier under every chain. Scope it and cross customer theft, mass data access, and privilege escalation all shrink together. One fix, many findings downgraded. That is leverage no detection approach can match.
It is cheap and needs no new architecture. Dual LLM needs a second model and a channel. Information flow control needs taint tracking. Scoping often just needs binding a tool’s arguments to trusted context and issuing narrower tokens, work you can do in the existing agent without redesign.
It is indifferent to the attack. Scoping does not care how the injection was delivered, framed, or when it was planted. A landed payload of any kind reaches only the scoped surface. It is the purest form of the Day 22 thesis: make success not matter, regardless of how success was achieved.
The before and after that sells it
This is the demonstration from Day 11, now named as the flagship move. Take any chain from this series:
- Before scoping: injection lands,
lookup_customer reads any customer, data exits. High severity.
- After scoping: same injection lands,
lookup_customer bound to the ticket owner returns access denied for anyone else. The payload fires and reaches one record it was already entitled to, which is no breach.
Same attack, unchanged. Impact dropped from all customers to none, by scoping alone. When you put that before and after in front of a team, scoping stops being abstract and becomes the obvious first fix. It beats the unsolvable problem, injection, with a solvable one, access control, which teams already know how to do.
The honest tension: capability versus safety
Scoping has a real cost, and pretending otherwise leads to bad advice.
Narrow scope limits what the agent can do. The whole value of an agent is handling varied tasks. Scope it to one task and it cannot handle the next without re scoping. There is genuine tension between a flexible, broadly capable agent and a tightly scoped safe one. You cannot max both.
The resolution is per task scoping, not permanent narrowness. Rather than one agent with broad standing access, grant narrow access per task, derived from that task’s trusted context, and release it after. The agent is capable across many tasks over time, but never broadly capable in any single moment an injection could exploit. Capability over the session, least privilege at every instant.
Some capability is irreducibly dangerous. A coding agent that must execute code, an agent that must send email, cannot have those capabilities scoped to zero without ceasing to function. For those, scoping pairs with the other defenses, sandbox the execution, Day 17, allowlist the destinations, Day 21. Scoping shrinks what you can, containment handles the rest.
The honest framing: scoping is the highest leverage defense, not a free one. You trade some breadth of capability for a dramatic reduction in blast radius, and the right design gives the agent capability across tasks while holding least privilege within each.
Reproduce it in the lab
You have done pieces of this since Day 11. Now do it systematically.
- List every tool in your lab agent and, for each, what it can currently reach. Be honest about the broad ones.
- For each tool, define the minimum reach the task actually needs, derived from trusted context like the ticket, and bind the tool to that.
- Switch from one broad token to per task, per user scoped access where your lab allows.
- Remove any tool the current task does not need from the loaded set.
- Run every week three injection you have. Confirm each now reaches only the scoped surface, and record the before and after impact for each.
The exercise to feel across all of them: the attacks are unchanged and still land, and one after another they reach nothing, purely because you shrank the agent’s reach. That table of downgraded findings is the most persuasive artifact in agent security.
Detection and defense, where this sits
Capability scoping is the practical heart of the defensive week.
- It enforces information flow control, Day 24, on the target side: tainted input cannot expand a reach that is bound to trusted context.
- It pairs with dual LLM, Day 23: dual LLM bounds influence, scoping bounds reach, together the compromised component has no privileged hands and the privileged component has minimal reach.
- It pairs with egress constraint, Day 21, and sandboxing, Day 17, for the capabilities that cannot be scoped to zero.
- It is the first thing to recommend in a report, because it is cheap, it needs no redesign, and it downgrades the most findings per unit of effort.
The thesis, in its most actionable form: you cannot stop the injection, so shrink what a successful injection can reach until reaching it is worthless. Capability scoping is how you do that in practice, and it is the defense that earns its place on every engagement.
Homework for Day 25
- Inventory every tool in your lab agent and its current reach. Flag every tool with more reach than its task needs.
- Bind each privileged tool to the minimum reach derived from trusted context. Re run the relevant injection and confirm the downgrade.
- Move to per task, per user scoped access instead of one broad token, and show the union of all access problem disappear.
- Strip unused tools from the loaded set and note the reduction in sinks.
- Build a before and after table for every chain in this series against your scoped agent. Same attack, impact after scoping. That table is your defensive portfolio piece.
Point 5 is the capstone of the practical defense. A single table showing every attack landing and reaching nothing, by scoping alone, is the clearest proof that the right answer to an unsolvable problem is to make solving it worthless.
Day 26 adds the layer scoping cannot provide on its own, runtime detection and what to actually log, so that when a scoped injection still does something, you can see it, reconstruct it, and respond, closing the gap between prevention and visibility.
