MCP in Production: What to Check Before an AI Agent Touches Real Systems

The Model Context Protocol (MCP) makes it simple to connect an AI model to tools: a database, a CRM, a Shopify admin or a ticketing system. A demo takes an afternoon. What engineers keep running into comes after the demo: which tools the agent can see, what it may do without asking, and how anyone knows it chose the right tool.

The MCP specification covers more of this than many teams realise. Here is what it says, and the controls we add on top.

What the specification says

From the MCP tools specification and its security best practices:

• A person can refuse a call. "There SHOULD always be a human in the loop with the ability to deny tool invocations." Clients should ask for confirmation on sensitive operations and show the tool's inputs before calling the server.
• Tool descriptions aren't trusted by default. Clients "MUST consider tool annotations to be untrusted unless they come from trusted servers." A tool that calls itself read-only might not be.
• No token passthrough. A server "MUST NOT accept any tokens that were not explicitly issued for the MCP server." Passing a user's token straight through to another API is named as an anti-pattern.
• Sessions aren't authentication. Servers that implement authorisation must check every incoming request and must not rely on sessions to authenticate. Session IDs must be secure and unpredictable.
• Consent per client for proxies. A server that sits in front of a third-party API must get consent for each client. Otherwise it becomes a "confused deputy", acting with someone else's permissions.
• Narrow scopes. The specification lists wildcard scopes such as *, all or full-access as a common mistake.
• Servers check and limit. Servers must validate tool inputs, enforce access controls, rate limit calls and sanitise what they return.

Controls we add before go-live

A reviewed list of servers. The agent connects only to servers someone on the team has read. A community MCP server is code running with your credentials, so review it like any other dependency.

Fewer tools per agent. Every extra tool is another chance to pick the wrong one. Split broad agents into narrow ones: one reads orders, another drafts refunds for a person to approve.

Confirmation for anything that writes. Reads can run freely. Anything that sends, refunds, deletes or changes a price waits for a person to approve it, with the exact inputs on screen.

A log of every tool call. Record the tool name, server, arguments, result, time taken and who approved it. When a customer asks why something happened, that log is the answer.

Tests for tool choice as well as answers. A common failure is a sensible reply built on the wrong tool call, or five calls where one would do. Keep a set of real requests with the tool calls you expect, and run it on every prompt or model change.

Tool output treated as untrusted. Text returned from a web page, an email or a support ticket can contain instructions. The agent should read it as data, and the server should sanitise it.

A separate key for each agent. Give each agent its own narrowly scoped credentials, so one can be revoked without stopping the rest.

Before go-live

• Every connected server is on the reviewed list.
• Each agent has only the tools its job needs.
• Every write action asks a person first and shows its inputs.
• Tokens are issued for the MCP server, never passed through.
• Every tool call is logged with its approver.
• The tool-choice test set runs in CI.
• Each agent's credentials can be revoked on their own.

Our AI systems practice builds agents with these controls in place from the first release. For the patterns behind them, read AI integration in production, and for connecting agents to your existing tools, see our API integration engineering.