What You Need to Know
A tool is a capability wired into an agent's configuration. Least privilege gives an agent only the tools its role needs. Capability bloat is every tool beyond that. A mitigation limits harm but leaves the tool wired. Where removal is available, choose it over mitigation every time.
An electrician's office runs an agent that reads job bookings and drafts customer replies. It also has refund and delete-bookings tools, which that role never needs.
Every Unnecessary Tool Costs Twice
A tool the role never needs is pure risk with zero benefit. It costs twice.
Security. If a tool is wired, the capability exists, whatever the system prompt says. Model error, user manipulation or prompt injection can reach it. Attack surface is what the configuration permits, not what the instructions request. A "never issue refunds" prompt leaves the electrician's refund tool reachable.
Performance. Every tool definition takes up context on every request. Overlapping or vaguely described tools confuse the model's choice between them. A bloated toolset is slower and less accurate as well as less safe. The electrician's agent carries two unused definitions on every message. Anthropic's tool-writing guidance says more tools do not always lead to better outcomes. Its tool-search documentation says tool selection degrades once a documented threshold of available tools is exceeded.
A lean configuration wins on both. A role needing many capabilities gets progressive discovery (objective 3.8), not a monolithic catalogue.
Start From the Role's Task List
Judge a configuration like database grants: from the role's task list, never from the platform's capability list. Anything the workflow does not need comes off. An agent that only reads and drafts, like the electrician's, justifies exactly those two capabilities, however useful a refund tool might be to somebody else. Anthropic's guidance applies the same rule to tool design: build a few thoughtful tools for specific high-impact workflows rather than wrapping every available endpoint.
Removal Beats Mitigation
Mitigations are real controls aimed at the wrong problem. Naming the category rules each one out quickly:
| Offered control | Category | What it cannot do |
|---|---|---|
| Audit logging | Detective | Finds abuse after the damage; the capability stays wired |
| Confirmation prompt | Compensating | Adds friction to a capability that should not exist |
| System-prompt prohibition | Instruction | Constrains behaviour, not capability; one manipulation from failing |
| Removing the tool | Elimination | Nothing; the risk no longer exists to detect, guard, or prohibit |
For the electrician, a log records a bad refund after the money has gone, and a confirmation prompt leaves refunds possible. Removal makes them impossible.
Consolidate What Survives
Least privilege is not only subtraction. Overlapping or vaguely described tools confuse selection and waste context, even when each is justified. Consolidate related operations into fewer clearly described, task-scoped tools, and namespace them under common prefixes so the model can tell them apart. A few well-named tools beat a long tail of granular near-duplicates. The electrician's three near-identical booking lookups would become one.
In the exam
The guide's own Domain 3 sample is this objective in miniature. A support agent that only reads tickets and drafts replies is also wired with refund and delete tools. The keyed answer removes them. Most questions here follow that shape: a configuration, four candidate changes, one that reduces risk. The double payoff of a lean configuration is why the exam keys it so consistently.
The Keyed Answer Removes
The guide's sample plants these distractors: logging (detective), a confirmation prompt (compensating) and a larger model. A larger model is irrelevant, because model capability has nothing to do with authorisation scope. When the stem says the role never needs the capability, eliminating that privilege wins every time.
Current tool-search threshold figures are dated snapshots, kept in the Domain 3 quick reference.
Exam Traps
Adding audit logging to a tool the role never needs, instead of removing it
Logging is a detective control: it discovers abuse after the damage is done. The unnecessary capability remains wired and exploitable, while removal costs nothing and eliminates the risk entirely.
Relying on a system-prompt prohibition to prevent a wired capability being used
An instruction is not an access control. If the tool is in the configuration the capability exists, reachable through error, manipulation, or prompt injection. Only removing or scoping the tool changes what is possible.
Choosing a larger, more instruction-following model to fix an over-privileged configuration
Model capability has nothing to do with authorisation scope — the refund tool is equally wired under every model tier. This is the guide's own planted distractor, testing whether you can tell a capability problem from a configuration one.
Wiring the platform's full capability catalogue so the agent 'can handle anything'
Past the task-scoped set, each added tool costs context on every request and degrades tool selection. The agent becomes slower and less accurate while its attack surface grows — more tools is not more capable.
Practice Scenario
An internal HR agent can read employee records, update them, generate letters, and export payroll data to CSV. It exists solely to answer questions from employees about their own leave balances. Which change best reduces risk?
Build Exercise
Tool-Surface Audit With Least-Privilege Justification
What you'll learn
- How to inventory an agent tool surface against the role task list
- How to name the control category of every mitigation and the gap it leaves
- When to remove, scope, or consolidate a tool
- How to write a per-tool justification that survives review
- Take an agent you operate — or design one — and list its full tool surface as configured, one line per tool
Why: The audit starts from what is wired, not what is intended. Most surfaces are larger than their owners remember.
You should see: A complete tool inventory, including the tools nobody has thought about since setup.
- Write the role task list, then classify each tool: required for a named task, or not
Why: Least privilege reasons from the task list forward, never from the capability list backward.
You should see: Every tool tagged with the task that justifies it, or flagged as unjustified.
- For every mitigation currently guarding a tool — log, confirmation, prompt rule — name its control category and what it cannot prevent
Why: Detective, compensating, and instruction controls each leave the capability wired. Naming the category is the exam skill for eliminating distractors.
You should see: A category label per mitigation and one sentence on the gap it leaves.
- Remove or scope every tool not justified by a task, and consolidate overlapping tools into fewer, clearly-described ones
Why: Removal eliminates risk that mitigation only manages, and consolidation improves selection accuracy while shrinking the surface.
You should see: A smaller toolset in which every survivor has one clear purpose and no near-duplicate.
- Write one sentence per surviving tool justifying it against a named task; if the sentence will not write, the tool comes off
Why: The justification sentence is the audit artefact — and the exact reasoning the exam asks you to perform on configurations you did not build.
You should see: A one-line justification per tool, each naming a task from step two.
Sources
- Writing effective tools for agents — Anthropic
- Tool search tool — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 3 — Anthropic