Design MCP tool permissions around the assumption that the model can be tricked. Expose only the tools a task needs, split read from write, scope credentials to the user and the task, require approval for consequential calls, enforce authorisation on the server and log every call.
What does the protocol itself say?
The Model Context Protocol specification (revision 2025-06-18) says that for trust and safety there should always be a human in the loop with the ability to deny tool invocations, and that applications should make exposed tools clear, show indicators when tools run and present confirmation prompts. It does not mandate a specific interaction model, so permission design is your job. Its security best practices page also names the confused deputy problem and forbids token passthrough, where a server accepts a client's token and forwards it to a downstream API without validating that it was issued to the server.
Check the latest revision of the specification before you build, since it evolves.
How should you split tools?
Classify each tool by what it can change:
- Read only, low sensitivity: search public docs, list open issues.
- Read, sensitive: read customer records, fetch secrets metadata.
- Write, reversible: create a draft, open a pull request.
- Write, irreversible or external: send email, delete data, make payments, change access.
Do not combine classes in one tool. A single "run_query" tool that accepts any statement is a read and a delete at once. Prefer narrow tools with typed arguments, such as "get_invoice by ID", over generic ones.
How should credentials work?
Use per user or per task credentials with the smallest scope. Do not give the server a shared admin key. Validate that tokens were issued for your server, and do not pass client tokens through to downstream services. If the server acts on a third party API through an OAuth proxy, follow the specification's guidance on consent for each client to avoid the confused deputy problem. Prefer short lived tokens and rotate them.
Where do you enforce the rules?
OWASP's excessive agency guidance names three root causes: excessive functionality, excessive permissions and excessive autonomy. It recommends minimising extensions and their functionality, limiting permissions, requiring user approval for high impact actions and implementing complete mediation, meaning authorisation in downstream systems instead of relying on the model to decide. Put checks in the server and in the target API. The model's judgement is not a control.
A constructed example: a support agent has a "refund" tool. Server side rules cap each refund, require an order owned by the verified customer, block more than three refunds per hour, and ask a human for anything over a limit. Even a fully hijacked agent can do bounded damage.
What should you log?
Record the user, session, tool name, arguments, result summary, approval decisions and the policy that applied. Alert on first use of a tool, calls outside normal hours, repeated denials and unusual argument shapes. Keep logs somewhere the agent cannot write.
What about third party servers?
Treat tool descriptions from servers you do not control as untrusted input, because they enter the model's context. Pin versions, review changes to descriptions and allow list servers per team. Safeguard's MCP Guardrail can apply policy to tool calls at runtime, and the Safeguard MCP server itself is available on every plan with unlimited tool calls.
What to do
- Inventory every tool and classify it by what it can change.
- Replace generic tools with narrow, typed ones.
- Issue per user, short lived, minimum scope credentials and never pass client tokens through.
- Add human approval for irreversible, external or high value actions.
- Enforce limits and authorisation in the server and downstream APIs.
- Log every call with arguments and decisions, and alert on anomalies.
- Pin and review third party servers and tool descriptions.
Quick check
Does MCP include built-in permissions?
The specification describes authorization and security practices and says a human should be able to deny tool calls, but it leaves the interaction model to implementers. You design the permission system.
What is token passthrough?
It is when an MCP server accepts a client's token and forwards it to a downstream API without checking it was issued to the server. The specification forbids it.
Sources
- Model Context Protocol: Tools
- Model Context Protocol: Security best practices
- OWASP Gen AI Security Project: LLM06 Excessive Agency
Last reviewed: 18 October 2026.
