3.1 Capability Bloat & Least Privilege by Removal

Picture handing a new hire a keyring on their first day. It doesn't just open their own office — it opens the supply closet, the server room, the executive suite, and the building's front gate. Most of those keys will sit unused for the entire time they work there. But every one of them is a door that COULD be opened, by mistake, under pressure, or by someone who manipulates the new hire into opening it for them. The keyring is more generous than the job requires, and that generosity is pure downside: it can never help them do their job better, and it can always be misused.

That keyring is exactly what a tool set is to an agent. Every tool you register — a function the model can call, a database it can query, an account it can modify — is a capability. Domain 2 taught you to write great descriptions so the model calls the RIGHT tool from the ones it has. Domain 3 asks a different question first: should it even HAVE that tool? Giving an agent more tools, or more powerful tools, than its role genuinely requires is called capability bloat, and it is the starting point for almost everything else in this domain — because every integration decision that follows assumes you've already right-sized what the agent can touch.

Capability bloat doesn't announce itself. Nobody deliberately builds an over-privileged agent; it accumulates. A support bot gets a refund tool added "just in case," then a delete-account tool for an edge case that happened once, then a raw database-query tool because someone needed it for a demo. Each addition seemed reasonable in isolation. The result, months later, is an agent that CAN do far more than the workflow it actually serves, and nobody can point to the moment that happened.

It's tempting to file capability bloat under "security" and move on. Resist that — the exam (and real production systems) will hand you scenarios where the visible symptom is reliability or cost, and the underlying cause is the same overloaded keyring. Bloat taxes an agent on three axes simultaneously, and a good architect names all three, not just the scary one.

• 1.Security — a hijacked or confused agent can invoke a destructive capability it never needed. This is a least-privilege violation before it is a bug or an exploit: the door was unlocked long before anyone tried the handle.
• 2.Reliability — more tools mean more chances to pick the wrong one. As the tool set grows and descriptions start to overlap (recall Domain 2's misrouting problem), tool-selection accuracy quietly degrades. A refund tool sitting unused isn't just a risk — it's a plausible-looking wrong answer waiting for an ambiguous request to trigger it.
• 3.Cost and context — every tool definition, used or not, is sent to the model on every single request and consumes context-window tokens for the privilege of being available. An agent with 40 tools pays that tax on turn one, even if it only ever calls three of them.

Notice how the three costs reinforce each other. A bloated tool set is slower to reason over (reliability), more expensive to run (cost), and more dangerous when something goes wrong (security). Trimming the tool set to exactly what a role needs improves all three at once — which is why "remove the unneeded tools" is so often the right answer even when a question is framed purely as a security or purely as a cost problem.

So you've spotted a tool the role doesn't need. The instinctive fix is often to make it SAFER rather than to take it away: add a confirmation dialog before it runs, log every call for later review, require a manager's approval. These aren't bad ideas — but notice what they have in common. None of them remove the capability. The refund tool still exists, still sits on the keyring, still CAN be invoked. You've made misuse more visible or slightly harder; you haven't made it impossible.

This is the distinction the exam leans on hardest in this task statement: detective controls versus removal. A confirmation prompt is a compensating control — it adds friction at the moment of use. An audit log is a detective control — it tells you AFTER THE FACT that something happened. Both are genuinely useful layers in a defense-in-depth strategy. But the principle of least privilege isn't about friction or visibility — it's about scope. Least privilege by removal means the tool simply is not part of the agent's configuration at all. There is no door to try, confirm, or log, because the door was never installed.

Go back to the support-agent example: if the role is "read tickets, draft replies," then issue_refund and delete_account should not appear anywhere in that agent's tool list — not gated behind a confirmation, not wrapped in extra logging, just absent. If a genuine business need later arises for refunds, that's a deliberate decision to expand the role and its tool set, made explicitly — not a default the agent quietly inherited months ago.

Let's make this concrete with the scenario the exam returns to again and again: a support agent configured with read_tickets, draft_reply, issue_refund, and delete_account. In practice, staff in this role only ever read tickets and draft replies — the refund and delete tools were added early on and never removed. Four remediations get proposed in a typical review meeting. Only one of them is a genuine least-privilege fix.

Here's why the other three proposals, however sensible-sounding, are distractors. "Add logging to the refund and delete tools" gives you a record after misuse happens — valuable for forensics, useless for prevention. "Keep all tools but add a confirmation prompt before refunds and deletions" adds friction a confused or manipulated agent can still click through — it doesn't change WHAT the agent is capable of, only how loudly it announces doing it. "Replace the agent with a larger, more instruction-following model" is the most tempting trap of all, because it sounds like a genuine capability upgrade — but model size and instruction-following ability have nothing to do with authorization scope. A smarter model with the same four tools is still an agent that CAN issue refunds and delete accounts; it is simply a smarter agent that can do so.

You now have the full picture: what capability bloat is, the three costs it inflicts at once, why removal beats guarding, and how to spot the distractors in a remediation question. The fastest way to internalize "role first, tools second" is to actually run the audit.

A right-sized tool set is also the precondition for the next lesson. Once an agent's capabilities match its role, the next question is whether the IDENTITY behind each call is verified and scoped correctly — which is exactly what authentication and authorization, 3.2, are about.