How to Secure MCP Tool Calls in Production
An MCP connection gives an agent a way to use a tool. It does not tell you whether a particular action is appropriate for the task a person approved.
An MCP connection gives an agent a way to use a tool. It does not tell you whether a particular action is appropriate for the task a person approved.
A support assistant might be allowed to read a ticket and draft a response. That does not automatically authorize it to export the entire customer database or send the draft to a new address found inside the ticket. The tool can work correctly while the action is still wrong.
To secure a tool call, check the action before it reaches the service that will carry it out. Validate its arguments, bind it to the approved task and target, and enforce the decision outside the language model. Keep a record of what ran, not only what the model proposed.
Start with the task, not the tool name
Write down the smallest useful task. For example: read ticket 184, prepare a response for the existing customer, and save it as a draft. Then identify the permitted account, ticket, recipient and operation.
A policy that says "email is allowed" is too broad for that task. Drafting a reply and sending an attachment to a new recipient have different effects, even if the same service supports both. A tool name is a starting point for review, not a substitute for checking the actual arguments and destination.
Treat tool descriptions and annotations as claims
MCP tools can carry annotations about whether they are read-only, destructive or idempotent. Those hints can improve the interface, but the MCP specification says clients must treat annotations as untrusted unless they come from trusted servers.
A read-only label does not enforce read-only behavior. Check what the server can actually access, which credentials it holds and which operations the client exposes. A third-party server with broad local privileges can be dangerous even when its advertised tool list looks harmless.
Use separate, limited credentials where possible. Avoid giving a support workflow an administrator credential simply because it makes installation easier. Restrict network and filesystem access as well as the model-facing tool list.
Put a check at the execution boundary
Resolve the requested action into concrete parameters before approval: which account, operation, resource, recipient and environment? Apply the relevant authorization policy there. Do not rely only on a system prompt telling the model to behave.
For sensitive actions, show the person the actual effect they are approving. "Delete these three test records" is meaningfully different from "let the agent manage the database." If parameters change after approval, check them again before execution.
Content returned by a tool is data to inspect, not authority to expand the task. A ticket, document or repository file can contain instructions placed by someone other than the user. Reading it should not silently grant permission to send, delete or expose information elsewhere.
Test both allowed and denied paths
Create a disposable fixture before testing destructive behavior. Use synthetic records, dummy secrets and a destination that cannot deliver data to a real third party.
First run the intended task. The permitted action should complete, with a visible result. Then ask for an out-of-scope action using the same integration. A denial message is not enough: verify that the underlying service did not receive the action and that the target data stayed unchanged.
Try alternative tool paths too. If the agent can bypass a checked database tool through an unrestricted shell, the protected path does not establish system-wide protection. Record that limitation instead of hiding it behind the successful test.
Keep a useful execution record
Capture the task reference, resolved tool arguments, policy version, decision and resulting service action. Avoid putting raw secrets or unnecessary personal data into logs. A request log proves what was asked; a service result or target-state check helps establish what happened.
Retries need explicit handling. A successful action repeated after a timeout can create a second message or payment unless the operation is safely deduplicated. Tool annotations can inform that review, but they do not make a service idempotent.
The practical release check is small: the intended action completes, an unauthorized action never dispatches, a retry does not duplicate the effect, and an alternate path cannot bypass the control. Name any part you have not tested. That is more useful than calling the whole MCP setup safe.
Sources supporting this guide:
Say yes to the AI your business wants.
Book a 30-minute call. Bring your agents and your rules.