- In short
- In a coordinator/subagent deployment, each subagent should receive only the tools its specific task requires. Scoping tool access this way establishes a trust hierarchy that limits the blast radius of a compromised or misdirected subagent. Tool scoping is a separate design decision from context isolation: subagents that do not share conversation history can still be over-granted tool access unless it is scoped independently.
Least privilege, applied across a multi-agent system
The necessity discipline that governs a single agent's tool set scales up to multi-agent systems, and the exam treats applying it there as its own skill. In a coordinator/subagent deployment, the coordinator delegates work to subagents, each with a narrow task. The least-privilege rule says each subagent should receive only the tools its specific task requires, not a copy of the coordinator's full set. Scoping tools this way is what establishes a trust hierarchy across the system: the coordinator may hold broad capability, but each subagent holds only what its slice of the work needs.
The payoff is blast radius. If a subagent is compromised, whether through prompt injection in the data it processes or through being misdirected by a flawed instruction, it can only reach the tools it was scoped to. A research subagent that can only read documents cannot delete records or send messages, because those tools were never in its set. Scoping converts a potential system-wide breach into a contained one.
- Scoped tool access in orchestrator-subagent systems
- A least-privilege pattern in which each subagent in a coordinator/subagent deployment receives only the tools its specific task requires, establishing a trust hierarchy that limits the blast radius of a compromised or misdirected subagent. It is a design decision distinct from context isolation.
The trust hierarchy limits blast radius
Think of the trust hierarchy as concentric permissions. The coordinator sits at the centre with the broadest view, and each subagent occupies a smaller ring holding exactly the tools its task justifies. A subagent that summarises fetched documents needs read and maybe search tools; it does not need write access to a system of record. Granting it only what it needs means a failure inside that subagent, however it arises, is bounded by the ring it sits in.
Contrast this with the convenient anti-pattern: handing every subagent the coordinator's full tool set so implementation is uniform. That collapses the hierarchy. Now any single compromised subagent has the whole system's capability, and the blast radius of one misdirected worker is the entire deployment. Scoping is the difference between a contained incident and a system-wide one.
Tool scoping and context isolation are different decisions
This is the sharp distinction the exam tests. Subagents in these systems often have isolated contexts, meaning they do not share conversation history with the coordinator or with each other. It is easy to slide from "their contexts are isolated" to "therefore their capabilities are isolated too." They are not the same thing. Context isolation governs what a subagent knows; tool scoping governs what a subagent can do. A subagent can have a perfectly isolated context and still be handed the full tool set, in which case it knows little but can do everything.
So the two must be designed separately. Isolating context does not scope tools, and scoping tools does not isolate context. A secure multi-agent design makes both decisions deliberately: give each subagent its own context and its own minimal tool set, matched to the task.
What the exam trips candidates on
Two traps recur. The first is giving every subagent the coordinator's full tool set for implementation convenience, which flattens the trust hierarchy and makes any single compromise a whole-system compromise. The second is the conflation trap: assuming that because subagents do not share conversation history, they also cannot share tool access. Tool access is a separate grant and must be scoped independently. The credited answer scopes each subagent to its task and treats context isolation and tool scoping as two distinct controls.
Worked example
A coordinator delegates to three subagents: one researches documents, one updates a CRM record, and one emails the customer. To keep the code simple, the team gives all three the coordinator's full tool set. They argue this is safe because each subagent runs in its own isolated context. Evaluate the design.
The design is not safe, and the isolated-context defence is the second trap in plain form. Isolated context means the three subagents do not share conversation history, which is a genuine and useful property, but it says nothing about what each can do. All three were handed the coordinator's full tool set, so each can research, write to the CRM, and send email regardless of the narrow task it was given. The research subagent, whose job is only to read documents, can nonetheless write records and send customer emails.
That matters because the research subagent is the one most exposed to untrusted input: it reads external documents, which is exactly where a prompt-injection payload could ride in. If it is subverted, its blast radius is the full tool set, so it could modify CRM records or send emails to customers, none of which its task requires. The fix is to scope each subagent to its task: the researcher gets read and search tools only, the CRM subagent gets the write-record tool only, and the email subagent gets the messaging tool only. That restores the trust hierarchy and bounds any single compromise to the small set that subagent legitimately holds. Context isolation stays as it was; tool scoping is added as the separate control it needs to be.
Common misreadings to avoid
Misconception
Giving every subagent the coordinator's full tool set is fine as long as it keeps the implementation uniform and simple.
What's actually true
Misconception
If subagents do not share conversation history, their tool access is effectively isolated too.
What's actually true
How this shows up on the exam
Expect a multi-agent scenario where subagents are either over-granted tools or where 'isolated context' is offered as if it settled the capability question. The reliable reading is that each subagent gets only the tools its task requires, that this trust hierarchy bounds blast radius, and that tool scoping is a control distinct from context isolation. This knowledge point extends the necessity test into multi-agent systems and connects to tool connections as attack surface and cost at the single-agent level. It also reinforces authorization model parity, since scoping tools is one place authorization is actually enforced.
In a coordinator/subagent system, a team gives all subagents the same full tool set, reasoning that the subagents' isolated contexts make this safe. What is the flaw?
People also ask
How should tools be assigned across subagents?
Does context isolation also isolate tool access?
How does scoping tools limit blast radius?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.