What you’ll be able to do
- Audit an agent’s tools, scopes and connected servers against the tasks its role actually performs
- Distinguish removing a capability from detecting or guarding its misuse, and know when each applies
- Split an over-powered agent into narrower roles when a single role genuinely needs a risky action occasionally
- Explain how capability bloat degrades tool-selection accuracy as well as security
What you need to know
What capability bloat looks like in production
Capability bloat is the gap between what an agent can do and what its role needs to do. It accumulates quietly: a team connects an MCP server for one useful tool and inherits fifteen; a prototype gets an admin API key "for now"; a generalist agent gains a refund tool because one workflow once needed it. Nobody decides to over-privilege the system. It just never gets pruned.
At Professional level, assume the model will eventually call any tool it has. A prompt injection in a retrieved document, an ambiguous user request, or an ordinary reasoning error can all trigger a call to a tool the designers "never expected it to use." If the tool isn't there, none of those paths go anywhere.
Removal beats detection and confirmation
Security controls come in layers, and the exam expects you to rank them correctly for an unneeded capability:
- Remove the capability. This eliminates the attack surface. Nothing to monitor, nothing to bypass.
- Constrain it: narrower scopes, parameter allow-lists, read-only credentials, rate limits enforced in the tool handler.
- Gate it: human approval or a deterministic policy check before execution.
- Detect it: audit logs and alerts after the fact.
Gating and detection are the right tools when the role does need the capability. When the role doesn't need it, they're compensating controls for a problem you could have deleted. Logging a destructive call tells you about the damage afterwards. A confirmation step relies on a human reading every prompt carefully, and approval fatigue sets in fast.
Prompts are not permissions
"Never call delete_account" in a system prompt is guidance, not enforcement. It reduces the probability of a call; it doesn't make the call impossible. Hard rules belong in configuration and code: the tool list the agent is given, permission rules in the harness (Claude Code's allow and deny rules in settings, for example), hooks that block a call before it runs, and authorization checks in the downstream service. A good test is to ask whether the control still holds if the model is fully manipulated. If it doesn't, it isn't a privilege boundary.
Least privilege has three layers
- Tool surface. Which tools appear in the request at all. Give each agent or subagent only the tools for its role, and select individual tools from an MCP server rather than exposing everything it offers.
- Credential scope. What the credential behind a tool can do. A
search_orderstool backed by a database user with write access is still over-privileged, because a bug or injection in the handler inherits that access. - Data reach. Which records the tool can touch. A per-tenant or per-user filter enforced server-side stops a correctly scoped tool from reading another customer's data.
Auditors look at all three. Teams usually prune the first and forget the second.
When a role really needs the risky action
Sometimes the support agent legitimately needs refunds, but only in a minority of cases. Don't hand the conversational agent the refund tool with a broad credential. Common patterns:
- Split roles. The front-line agent can only propose a refund as a structured request. A separate, narrowly scoped executor (or a human) validates it against policy and carries it out.
- Constrain in code. The refund handler enforces amount limits, order ownership and idempotency, whatever the model asked for.
- Escalate past a threshold. Above a limit, the action routes to human approval. The approval is a deliberate control on a needed capability, not a patch over an unneeded one.
Bloat also costs accuracy
Capability bloat isn't only a security problem. Every tool definition takes up context and competes for selection. Large, overlapping tool sets make the model more likely to pick a near-miss tool or call one it didn't need. Pruning to the role's real needs usually improves tool-selection accuracy and cuts token cost, so least privilege and reliability point the same way. That's a useful argument when a stakeholder pushes back on removing tools "just in case."
Running a capability audit
Inventory every tool the agent can reach, including everything on each connected MCP server. For each one, name the workflow that needs it and the credential behind it. Anything without a named workflow is a removal candidate. Anything whose credential exceeds the tool's purpose is a scoping fix. Repeat the audit whenever a server is upgraded, because a new server version can add tools you never reviewed.
Key concept
If a role doesn’t need a capability, remove it. Logging, confirmations, prompt instructions and bigger models only compensate for privilege you could have deleted.
Questions present an over-equipped agent and offer monitoring, approvals, prompt rules or a stronger model next to "remove the tool" or "scope the credential." When the scenario says the role never needs the capability, removal is the answer. When it says the role sometimes needs it, look for constraint in code, role splitting or threshold-based approval.
Practice scenario
run_query, drop_table, grant_access and export_to_bucket. Analysts only ever ask for read-only reporting queries. The platform team proposes leaving the server as is and adding an alert whenever drop_table or grant_access is called.Work it through, then open this
An alert fires after the table is dropped or access is granted, so it detects damage rather than preventing it. The role is read-only reporting, so expose only the read tools the assistant needs (for example run_query and schema lookup) and leave out the administrative and export tools. Then check the second layer: run_query should run under a read-only database role, so a crafted DROP inside a query string can’t succeed either. Keep logging on what remains, as a detective control on capabilities the role does need. As a bonus, cutting from 22 tools to a handful usually makes tool selection more reliable.
Build exercise — Run a capability audit on one agent
Advanced · 40 min
What you’ll learn
- Mapping every reachable tool and credential to a named workflow
- Separating removal candidates from scoping fixes and gated-but-needed actions
- Moving a prompt-only rule into an enforced control
-
Pick a real or sample agent and list every tool it can reach (including all tools on each connected MCP server), the credential behind each, and the workflow that needs it.
- Why: Bloat hides in servers connected wholesale and in credentials nobody revisited after the prototype.
- You should see: At least one tool with no named workflow, and at least one credential broader than its tool’s purpose.
-
Classify each entry as keep, remove, rescope, or keep-but-gate, and write a one-line justification for every keep-but-gate.
- Why: Gating is legitimate only for capabilities the role needs. Writing the justification exposes gates that are really standing in for removal.
- You should see: A shorter tool list, narrower credentials, and only a few gated actions, each tied to a real workflow.
-
Find one rule currently enforced only by the system prompt (“never do X”) and move it into configuration, a hook, or the tool handler. Test it with an adversarial prompt that tries to make the agent do X.
- Why: A privilege boundary has to hold even when the model has been manipulated.
- You should see: The call blocked by the harness or handler regardless of what the model asks for.
Exam traps
Adding audit logging to a dangerous tool the role never needs, instead of removing it
Logging is detective: it records the incident after it happens. For an unneeded capability, removal eliminates the risk.
Relying on a system-prompt instruction to stop the agent from calling a tool it still has
Instructions shift probabilities and can be overridden by injection or error. Enforce hard limits in configuration, hooks and handlers.
Treating a confirmation prompt as equivalent to not granting the capability
Confirmations depend on attentive humans and wear down with approval fatigue. They fit capabilities the role needs, not ones it doesn’t.
Connecting a whole MCP server because one of its tools is needed
You inherit every tool the server exposes, now and in future versions. Expose only the tools the role uses and re-review on upgrades.
Choosing a larger model to make an over-privileged agent follow the rules
Model capability doesn’t change authorization scope. A more capable model with a destructive tool still has the destructive tool.
Scoping the tool list tightly but leaving the credential behind it broad
A read-only tool backed by a write-capable credential is one bug or injection away from writes. Scope the credential to the tool’s purpose.
Sources
- Claude Developer Platform Docs
- Model Context Protocol
- Anthropic, Claude Certified Architect – Professional Exam Guide v1.0 (July 2026)