Least privilege and authorization, removing capabilities beats watching them

An internal template connects every new agent to all nine of the company’s MCP servers, with read and write permissions, “so nobody gets stuck”. Months later, an agent whose only job was to summarize a meeting posts the notes to a company-wide channel because a document asked it to. Nobody attacked it with any sophistication: it had the capability and used it.

Capability bloat

Capability bloat shows up in two ways, and both are fixed by removing, not adding:

• Tools the role doesn’t use. A support agent that reads tickets and drafts replies doesn’t need to issue refunds or delete accounts. Every extra tool is attack surface and tokens spent on every request.
• Overlapping tools. Three search tools over the same index, with almost identical descriptions, make the model call several of them, repeat searches or pick the wrong one. Consolidate them into a single tool with clear parameters.

The rule is least privilege: each agent gets only the tools, servers and permissions its role needs, and read-only credentials wherever reading is enough. That way, even if a prompt injection shows up again, the possible damage is minimal.

Controls that eliminate and controls that compensate

Control	What it does with the risk
Remove the tool or permission	Eliminates it
Read-only credentials, minimal scopes	Limits it
Human confirmation before the action	Compensates for it
Logs and auditing	Detects it afterwards
Prompt instruction (“never post”)	Suggests avoiding it

Confirmations and logs are useful as extra layers, but if the role doesn’t need the capability, the right answer is to remove it.

Authorization: with the identity of whoever is asking

The other classic gap is in how the server reaches the data. If an MCP server accesses the HR API with a service account that can see every employee record, any user can ask for a colleague’s salary and get it. A filter on the reply or a line in the system prompt doesn’t fix that: the model already has the data.

Authorization uses the end user’s identity (for example, with a delegated token) and is enforced at the data layer, where the access rules already live. The model should never be able to fetch something the user can’t see.

In a remote MCP server with OAuth there are two rules from the specification that the exam uses:

• The server validates the token audience: it only accepts tokens issued for it. A valid signature and expiry are not enough.
• Token passthrough is forbidden: if the server has to call another API, it does so as a client, with its own token for that API, not with the one it received.

The usual traps

• Logging the dangerous tools “to audit later” instead of removing them.
• Requiring human confirmation for every call, even reads: it slows everything down and people end up approving without looking.
• Compensating for overlapping tools with examples in the prompt or a router in front.
• Moving to a larger model “that follows instructions better”: size doesn’t change the scope of the permissions.
• Closing an authorization gap with a prompt instruction or an output filter.
• Moving the token into the URL or extending its lifetime.

In the exam

If the scenario lists what the role “only needs” and what the agent “can also” do, look for the option that removes the excess. If it describes a user seeing someone else’s data, look for where the user’s identity gets lost: the answer is to propagate it and enforce access in the API, not in the model. And if a token is accepted “even though it was issued for another service”, the answer combines validating the audience and using its own token downstream.