Is MCP ready for production? What to check before connecting an agent to your systems

The Model Context Protocol changed underneath most of the advice written about it. The 2026-07-28 specification made MCP stateless, removed sessions, and deprecated dynamic client registration. Meanwhile Stacklok's survey of 300 senior leaders found 41% already running MCP in limited or broad production — and 64% of software respondents naming security as the top obstacle.

MCP is ready for production. Most MCP deployments are not. This is what to check before you connect an agent to the systems your business runs on.

What is MCP, and who controls it now?

MCP is an open protocol that lets an AI application call tools and read data from other systems through one standard interface instead of a custom integration per vendor. Anthropic created it, and in December 2025 donated it to the Agentic AI Foundation, a Linux Foundation fund whose platinum members include AWS, Google, Microsoft and OpenAI.

The Linux Foundation announcement placed MCP alongside Block's goose and OpenAI's AGENTS.md as founding projects. That matters for a buyer: MCP is no longer one vendor's format, and betting on it is no longer betting on one vendor.

Scale followed. The MCP project's July 2026 release post reports Tier 1 SDKs at "close to half-a-billion downloads a month". When we paged the official MCP Registry API on 3 October 2026, it returned roughly 13,800 server entries.

What changed in the 2026 specification?

The current version removes protocol sessions entirely, so every request stands alone; adds headers that let gateways and firewalls route MCP traffic; and tightens authorisation so credentials are bound to the server that issued them. Several older features — sampling, roots, logging — are deprecated with at least twelve months' notice.

For anyone securing a deployment, three changes matter most:

• Stateless by design. There is no Mcp-Session-Id any more. The security guidance that used to address "session hijacking" now addresses state handle hijacking: servers "MUST NOT treat possession of a state handle as authentication".
• Routable traffic. New Mcp-Method and Mcp-Name headers mean an API gateway can allow, deny or log individual tool calls without parsing the body. That makes central policy enforcement practical.
• Stricter OAuth. Clients must validate the token issuer, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.

Separately, the Enterprise-Managed Authorization extension became stable in June 2026. Staff sign in once through the company identity provider, and access to every MCP server can be revoked centrally — the difference between a governed rollout and a spreadsheet of personal tokens.

What has actually gone wrong with MCP so far?

The documented failures share one cause: an agent with access to private data read instructions planted in content it was processing, then used another tool to send that data somewhere. In almost every case the server code worked as written. The flaw was in what the agent was allowed to combine.

The record so far:

Invariant Labs described the GitHub case as "not a flaw in the GitHub MCP server code itself, but rather a fundamental architectural issue". That is the useful lesson: patching servers fixes the CVEs, but only deployment design fixes the class.

What is the lethal trifecta?

It is the combination of three capabilities that makes prompt injection dangerous: access to private data, exposure to untrusted content, and the ability to communicate externally. An agent with all three can be instructed by anyone who can put text in front of it to send your data to them.

The term is Simon Willison's, and his warning about MCP is direct: it "encourages users to mix and match tools from different sources that can do different things." A CRM server is safe. A web-browsing server is safe. Connected to the same agent, they form the trifecta.

OWASP now names this risk class formally: prompt injection is LLM01 in the Top 10 for LLM applications, and its December 2025 Top 10 for Agentic Applications leads with agent goal hijack and tool misuse.

The practical rule: never give one agent all three legs. If it reads customer emails, it should not also be able to send email or call arbitrary URLs without a human approving each action.

What should you check before connecting an agent to business systems?

Check identity, scope, combination, approval and logging — in that order. Each agent should act as a specific user with that user's permissions, hold the narrowest scope that does the job, never combine untrusted input with outbound channels, require approval for irreversible actions, and leave an audit trail of every tool call.

1. Does every call run as a real user? The better vendor servers already work this way. Salesforce's hosted MCP servers, generally available since April 2026, apply existing permissions — "CRUD, FLS, sharing rules" — so "every transaction runs as the authenticated user". Avoid servers configured with one shared admin credential.

2. Is the scope minimal? The specification's security best practices name "wildcard or omnibus scopes" as a mistake and recommend starting minimal and stepping up. In the Supabase case the agent ran with a service role that bypassed row-level security entirely. Read-only access would have prevented it.

3. Is token passthrough ruled out? The specification is categorical: servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server." A server that forwards your token to another API breaks both security boundaries and the audit trail.

4. Which tool combinations exist? List every server each agent can reach and mark which ones carry untrusted content and which ones can send data out. Stripe's own MCP documentation warns users to "exercise caution when using the Stripe MCP with other servers to avoid prompt injection attacks".

5. Does a human approve irreversible actions? The specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations". Stripe requires confirmation for refunds and outbound payments. Pinterest, whose internal MCP platform handles about 66,000 calls a month for 844 users, makes approval mandatory "before any sensitive or expensive action".

6. Is every call logged? Inputs, outputs, the user, the time. When something goes wrong, a log is the difference between an incident report and a guess. In Stacklok's survey, 60% of software respondents already use audit logging and monitoring; the other 40% are the ones to worry about.

7. Are servers pinned? A server can change its tool descriptions after you approve it — Invariant Labs calls this a "rug pull". Pin versions, review updates, and treat the public registry as a directory rather than a vetted store; its own launch post says moderation is community-driven.

Which systems should you connect first?

Connect read-only internal systems first: documentation, issue trackers, reporting databases. Stacklok's software respondents connect exactly these most often — version control (63%), documentation (62%) and issue tracking (54%). Systems that move money, message customers or change records come later, behind approval.

A sensible order for a mid-sized business:

1. Read-only knowledge: wiki, help centre, product docs.
2. Read-only operational data: CRM records, order history, reporting views.
3. Drafting with approval: replies, quotes, CRM updates staged for a person to confirm.
4. Bounded actions: low-value, reversible writes with limits and logging.

Each step should earn the next, measured by how often a person corrects what the agent proposes. We use the same test in which AI automation applications reach production.

Where does the real work sit?

Mostly underneath MCP. A server exposes whatever the system behind it holds; if your CRM and finance system disagree about who a customer is, the agent will confidently act on whichever it reads first. Clean, permissioned data with clear ownership is what makes an MCP connection safe and useful.

That is why connecting an agent is usually a business systems and data foundations project before it is an AI one. The agent itself — scope design, approval flows, evaluation — is the AI automation and agent engineering layer on top.

For regulated firms, the logging and approval design above is also evidence. Financial services teams in particular will be asked to show who authorised what an agent did, and that is the remit of AI governance and assurance. Every extra tool call is also a billed call; we covered that in what an AI agent costs to run.

The short version

The protocol is mature, governed by a neutral foundation, and supported by the major vendors. The incidents to date came from deployments that gave one agent private data, untrusted input and an outbound channel at the same time, often with an admin credential.

Run every call as a real user, keep scopes minimal, separate the trifecta, approve irreversible actions, and log everything. If you want that designed against your own systems before anything is connected, it is part of the automation blueprint.