Governed MCP servers: tools Claude can’t misuse
The danger with autonomous tool use isn’t a model “going rogue” — it’s an over-broad tool with no limits. A governed MCP server makes misuse structurally impossible: allowlists over blocklists, per-call caps, scoped, short-lived credentials, and an audit trail for every action.
Model Context Protocol (MCP) is the cleanest way to give a model real tools — query a database, send a message, move money. But the same wiring that makes an agent useful makes it dangerous if you hand it a tool that can do anything. The fix is not a smarter model; it is a governed server.
Governance here means the server, not the prompt, enforces what is allowed. A prompt can be talked around; a policy layer cannot.
Where MCP actually goes wrong
Almost every incident I have seen traces back to one of two design smells, not to the model behaving unexpectedly:
- Over-broad tools. A single
run_sqltool with write access is a loaded gun. The model doesn’t need to be malicious to drop a table — an ambiguous instruction is enough. - Ambient authority. Handing the server a long-lived admin key means every tool inherits god-mode. The blast radius of any mistake is the whole system.
Treat the agent as an untrusted client that happens to be clever. You would not give an unknown API caller unrestricted DB access; the agent gets the same scepticism.
Allowlists over blocklists
Blocklists fail because you can never enumerate every bad action. Allowlists flip the default to deny: expose narrow, intention-revealing tools (book_slot, refund_order) instead of generic ones (run_sql). Each tool does one thing, validates its own inputs, and rejects anything outside its contract.
This also makes the agent better — a small set of well-named tools is far easier for the model to use correctly than one powerful escape hatch.
Per-call caps and rate limits
Even a narrow tool needs limits. A refund_order tool should cap the amount, require an order that exists, and rate-limit how many refunds run per minute. Put these checks in the server so they hold regardless of what the model was convinced to request.
- Bound every numeric argument (amount, quantity, page size).
- Rate-limit and add a daily ceiling per tool.
- Require confirmation tokens for irreversible writes.
Scoped credentials, idempotency & audit trails
Give each tool its own short-lived, least-privilege credential — a token that can book but not delete. Make every write idempotent so a retried call can’t double-charge. And log every tool call with inputs, outputs and the decision that allowed it.
The audit trail is what turns “something weird happened” into a five-minute investigation. It is also what lets you ship autonomy with a straight face: you can prove, after the fact, exactly what the agent did and why it was permitted.
A tool the model literally cannot misuse beats a prompt that politely asks it not to. Push safety down into the server, not up into the instructions.
Key takeaways
- Most MCP risk comes from over-broad tools and ambient authority, not rogue models.
- Expose narrow, single-purpose tools and deny by default.
- Cap every argument, rate-limit, and gate irreversible writes.
- Use scoped short-lived credentials, idempotent writes, and a full audit trail.
Frequently asked questions
What is an MCP server?+
An MCP (Model Context Protocol) server exposes tools and data to an AI model through a standard interface, so an agent can take real actions like querying a database or calling an API.
How do you stop an AI agent from misusing a tool?+
Enforce limits in the server rather than the prompt: narrow allowlisted tools, per-call caps, scoped short-lived credentials, idempotent writes and a complete audit trail.
Should MCP tools be idempotent?+
Yes. Idempotent writes mean a retried or duplicated call produces the same result, which prevents double-charges and duplicate records when the model retries.