Capability Bloat & Least Privilege by Removal
CoreEvaluate tool and agent configuration for capability bloat · Difficulty 2/5
Explanation
Every tool exposed to an agent is both a capability and an attack surface. **Capability Bloat** — giving an agent more tools, or more powerful tools, than its role genuinely requires — is a design flaw that shows up on three axes at once.
The Three Costs of Capability Bloat
- Security — a hijacked or confused agent can invoke a destructive capability it never needed. This is a least-privilege violation before it is anything else.
- Reliability — more tools mean more chances to pick the wrong one; tool selection accuracy drops as the tool set grows and descriptions overlap.
- Cost/context — every tool definition consumes context-window tokens on every single request, whether or not it is ever called.
The Fix: Least Privilege by Removal
The architect's fix is least privilege by removal: give an agent only the tools its role genuinely needs, and remove the rest entirely. Detective controls (audit logs) and compensating controls (confirmation prompts) are useful complements, but they do not shrink the attack surface — only removal does. If a support agent's role is to read tickets and draft replies, refund and delete-account tools should not exist in that agent's configuration at all, regardless of how well they are logged or gated.
Common exam traps
- Answering "add logging" or "add a confirmation prompt" to a least-privilege question. Those are detective/compensating controls; least privilege means *removing* the unneeded capability, not instrumenting it.
- "A bigger, more instruction-following model fixes over-privilege." Model size and capability are unrelated to authorization scope — a smarter model with the same excess tools is still over-privileged.
Key Takeaways
- Capability bloat harms security, reliability, and cost/context simultaneously
- Least privilege means removing unneeded capabilities, not guarding them with logging or confirmations
- Detective controls (audit logs) and compensating controls (confirmation prompts) do not shrink the attack surface
- Model size or instruction-following ability is unrelated to authorization scope
- Tool selection accuracy drops as the tool set grows and descriptions overlap
Glossary Terms
A client-declared filesystem scoping mechanism. The MCP client specifies which file:// URI paths (roots) a server may access. Servers declare which roots they need; clients grant a subset. Roots are a protocol-level declaration enforced by server compliance, not by OS sandboxing.
A skill frontmatter field that whitelists which tools a skill can use during its execution. Enforces the principle of least privilege for skills. Use specific tool names or MCP server patterns (e.g., 'mcp__github__*' allows all GitHub MCP tools).
A security principle applied to agent tool design: give each agent and subagent only the minimum tools required to complete its specific task. Reduces blast radius if an agent is compromised or makes an error. Implemented via AgentDefinition tool lists and skill allowed-tools.
The practice of writing tool definitions (name, description, input schema) that enable Claude to reliably select and use tools correctly. Key principles: precise descriptions that distinguish similar tools, explicit input format requirements, clear boundary examples, and documented error return formats.
The design flaw of giving an agent more, or more powerful, tools than its role genuinely requires. Capability bloat harms security (a hijacked agent can invoke a capability it never needed), reliability (tool-selection accuracy drops as the tool set grows and descriptions overlap), and cost (every tool definition consumes context tokens on every request). The fix is least privilege by removal -- eliminating the capability entirely -- not adding logging or confirmation prompts around it.
Related Concepts