AI system integration gets specified as though it were one connection: point the model at the data. In practice you are building five, and the four that get left out of the estimate are the ones that decide whether the thing survives its first quarter.
- Context in. What the model is allowed to read, and how it reaches it.
- Actions out. What the system is allowed to write, and to which system of record.
- Identity and permissions. Who the model is acting as, and what that identity may see and do.
- State and audit. What was retrieved, what was generated, what was done, and whether you can reconstruct it three months later.
- The human gate. Where a person sits in the path, on which subset of cases, with what information.
Anyone quoting you for the first one alone has quoted a demo. If you want the general shape of this work before the detail, we set it out in AI integration, explained.
What standardised in December 2025, and what it fixed
The connector layer did genuinely change, and it is worth knowing why before assuming it changed more than it did.
The Model Context Protocol was introduced by Anthropic in November 2024 as an open way for AI applications to discover and call external tools. On 9 December 2025 it was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, with AWS, Bloomberg, Cloudflare, Google and Microsoft among the platinum founding members. Anthropic's announcement on the day put the ecosystem at more than 10,000 active public servers, with client support across ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. Treat that as a dated snapshot rather than a running total: public counts since then range from roughly two thousand to over twenty thousand depending entirely on whether you are counting a curated registry, every listing on an aggregator, or servers that actually answer when probed. The direction is not in doubt and the precise number is not worth arguing about.
What that solves is a combinatorial problem. Before a common protocol, connecting a models to b tools was a times b pieces of bespoke glue, each with its own auth, its own error semantics and its own maintainer. With one protocol it is a plus b. That is a real reduction and it is the reason integration work got cheaper at the edges over the last eighteen months.
What it does not solve is everything on the list above except the first. A protocol standardises how a tool is described and invoked. It does not decide what your model may write to, whose identity it borrows, what gets logged, or who checks. Those remain design decisions you make, and they are where the effort actually lands.
The security position, stated honestly
This is the part that a post written by an integration firm usually skips, so: the protocol layer standardised faster than its security did, and there is peer-reviewed work saying so.
A threat-modelling study by Huang and colleagues at the New York Institute of Technology, published in the Journal of Cybersecurity and Privacy in May 2026, examined seven major MCP clients systematically and identified tool poisoning, where malicious instructions are embedded in the metadata describing a tool, as the most prevalent and impactful client-side vulnerability. Their test artefacts and threat model are published openly, which is more than most writing on this subject offers. It found most tested clients had insufficient static validation and poor parameter visibility, meaning the user approves a tool description that does not show them what the tool will actually make the model do. The disclosed vulnerability record backs this up: CVE-2025-6514, an OS command injection in the widely used mcp-remote client, carried a CVSS score of 9.6.
The single most useful concept for deciding whether you are exposed is not a CVE list. It is what Simon Willison named the lethal trifecta in June 2025: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally. Each is fine alone. All three together mean any attacker who can get text in front of your model can potentially get your data out, and this is structural rather than a bug, because a language model has no reliable way to distinguish instructions it was given from instructions embedded in data it was asked to read. The academic literature has since adopted the framing directly.
The practical rule follows from the framing rather than from any product: break one leg of the trifecta on every integration you build. If the agent reads untrusted inbound email, it does not also hold write access to your banking or your CRM, and it does not make outbound calls to arbitrary addresses. If it needs all three, a person approves the action. That is a design constraint, not a control you can buy, and detection products do not substitute for it.
Where AI system integration actually goes wrong
Assume the connection works on day one. These are what break it in month three, and none of them are AI problems.
- Non-idempotent writes. The model retries, or the queue redelivers, and you have two invoices, two emails, two credit notes. Every write path needs an idempotency key and a deduplication check, and this is the single most common defect we see in AI integrations built quickly.
- Retry storms against rate limits. Model calls fail more often than database calls and in more interesting ways: timeouts, truncation, refusals, malformed output. Naive retry logic against a rate-limited API turns a transient failure into an outage. Exponential backoff with jitter and a circuit breaker, as with any other remote call.
- Schema drift. Your source system adds a field, renames one, or changes a date format. Nothing errors. The model quietly infers something different and the output degrades silently for six weeks. Quality gates that fail loudly on shape changes are the fix, and they are the same gates good data pipelines have always needed.
- Partial failure in a multi-step chain. Step four fails after steps one to three have already written to three systems. Either the chain is a transaction with compensating actions, or it is a sequence with a defined rollback, or you have designed a system that leaves your records inconsistent under load.
- Unbounded cost. A loop with no step ceiling and no token budget is a billing incident waiting for a bad input. Cap steps, cap tokens, alert on spend per run, and treat a run that exceeds either as a failure rather than as something to absorb.
- Non-reproducible output. Six months on, someone asks why the system did that. Without the retrieved context, the prompt version, the model version and the tool calls logged together, you cannot answer. This is also why the model must never hold the answer itself, which we argued at length in why your AI should never be the source of truth.
Notice how much of that list is ordinary distributed-systems discipline. That is the point. The novel component is one call in the middle. The engineering around it is the engineering you already know, applied to a dependency that is slower, more expensive and less deterministic than the ones you are used to. It is the case for boring AI infrastructure arriving from the integration side.
Specify these five before anyone writes code
- The read boundary. Name the systems, the tables or endpoints, and the rows the model may see. "Access to the CRM" is not a boundary.
- The write boundary, separately. Which system of record can this thing change, under what conditions, and what is the reversal path. Most integrations should start read-only and earn write access later.
- The identity. A dedicated service identity with least privilege, never a borrowed staff account. If the model acts as a person, your audit log is wrong and your permissions are whatever that person happens to have.
- The retention and residency answer. Which provider processes the data, in which jurisdiction, and under what contract. In South Africa this is a POPIA question before it is an architecture one, and we covered the ground in POPIA, GDPR and AI.
- The human gate, with a number attached. Which cases route to a person, what percentage of the rest gets sampled, and who reads the corrections. If the answer is "we will review the exceptions", that is half a design.
The pattern underneath all of this is the one we keep arriving at: constrain the thing. Production systems built this way are not less capable, they are less surprising, which is the property you are actually buying. The distinction between a bounded workflow and an open-ended agent, which we set out in agents vs workflows, is the same distinction showing up in the integration layer.
If you are scoping this work and want the estimate to survive contact with production, that is what our AI integration engagements are built around: the four connections nobody quoted for.
FAQ
What is AI system integration? It is the work of connecting an AI model to the systems a business already runs, so that it can read real data, act on real records, under a controlled identity, with an audit trail and a defined point of human review. It is distinct from building or tuning a model, and it is normally the larger share of the effort and the cost.
Does MCP mean integration is now a solved problem? No. The Model Context Protocol standardises how tools are described and invoked, which turns a combinatorial integration problem into a linear one. It became a vendor-neutral standard under the Linux Foundation's Agentic AI Foundation in December 2025. It does not decide permissions, write boundaries, logging, review or failure handling, and those are where the work is.
Is MCP safe to use in production? It is usable with design discipline, and it should not be treated as secure by default. Peer-reviewed threat modelling published in 2026 identified tool poisoning through malicious tool metadata as the most prevalent client-side weakness, and serious CVEs have affected widely used components. Assume any connected tool description is untrusted input.
What is the lethal trifecta? A threat model named by Simon Willison in June 2025: an AI agent that simultaneously has access to private data, processes untrusted content, and can communicate externally. Any one is manageable; the combination allows attacker-controlled text to exfiltrate data. The reliable mitigation is architectural, removing one of the three, rather than filtering for malicious instructions.
Why do AI integrations fail after they work in testing? Usually for reasons that have nothing to do with the model: duplicate writes from retries, schema changes upstream that fail silently, partial failures midway through a multi-step chain, and costs that scale with a bad input. These are ordinary distributed-systems problems applied to a slower and less deterministic dependency.
Should the AI have write access to our systems? Start without it. Read-only integrations deliver most of the early value at a fraction of the risk, and they let you measure output quality before an error becomes an incorrect invoice. Add write access one path at a time, with idempotency, a reversal route and a human gate on anything expensive to undo.
References
- Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation (December 2025; the donation to the Linux Foundation, ecosystem size and platform support). https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
- Huang, C., Huang, X., Tran, N. P. and Milani Fard, A.: Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning, Journal of Cybersecurity and Privacy 2026, 6(3), 84 (published 5 May 2026; seven MCP clients tested, tool poisoning identified as the most prevalent client-side vulnerability). DOI 10.3390/jcp6030084. https://www.mdpi.com/2624-800X/6/3/84
- Preprint version of the same work, for open access. https://arxiv.org/abs/2603.22489
- Willison, S.: The lethal trifecta for AI agents: private data, untrusted content, and external communication (16 June 2025). https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
- Cloud Security Alliance: research note on MCP tool poisoning and IDE auto-execution (1 July 2026; disclosed vulnerabilities including CVE-2025-54135 and CVE-2025-54136, and the classification of tool descriptions as supply-chain assets). https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-tool-poisoning-auto-execution-20260701/
- Pan, M. Z. et al.: Measuring Agents in Production (survey of practitioners and 20 case studies across 26 domains; bounded autonomy and predefined workflows dominate production deployments). https://arxiv.org/abs/2512.04123
Written by JP, Sixees Labs. Last reviewed August 2026.