Before the Model Context Protocol, every agent-to-system integration was bespoke. Connecting an agent to a ticketing system, a data warehouse and a document store meant three custom integrations, each with its own auth handling and error semantics. Change the agent framework and much of that work repeated.
MCP, introduced by Anthropic in November 2024 and often described as “USB-C for AI”, standardises that interface. A system exposes capabilities through an MCP server; any MCP-capable client discovers and uses them. The combinatorial integration problem collapses toward linear, which is why adoption has been fast and why the major agent frameworks converged on supporting it.
The scale of what is being connected is the part worth pausing on. IDC projects active enterprise AI agents growing from 28.6 million in 2025 to more than 2.2 billion by 2030. Whatever governance pattern you establish now is the one that scales.
What MCP genuinely solves
- Integration reuse — one server per system, usable by every agent in the estate.
- Portability — changing orchestration framework no longer means rewriting integrations.
- Discoverability — agents enumerate available tools rather than having them hardcoded.
- A useful chokepoint — the protocol creates a natural place to apply authorisation, logging and rate limiting.
It also composes with agent-to-agent protocols: a system might use A2A between agents while each agent uses MCP to reach its own tools.
Tool poisoning: the attack class MCP introduces
An agent decides which tool to call by reading its metadata — name, description, parameter schema. That trust relationship is the vulnerability.
In a tool poisoning attack, an attacker crafts or compromises tool metadata to contain hidden instructions the agent reads and the user never sees. What distinguishes this from earlier prompt injection research is persistence. Traditional prompt injection requires repeatedly delivering malicious content through a document, page or email. A poisoned tool description ships inside a package, a config file or a remote server — and works on every invocation, silently, across every session and every user, until somebody notices.
Security researcher Simon Willison, who has tracked prompt injection since 2022, has observed that the persistent difficulty is that the problem has been known for years without convincing mitigations emerging.
This is now formalised in defensive frameworks. The OWASP Top 10 for Agentic Applications, released in December 2025, sits alongside the LLM Top 10, with tool misuse and agentic supply chain vulnerabilities as named categories. Research using the MCPTox benchmark indicates malicious or manipulated tool definitions pass into agent contexts more readily than most teams assume.
Scale has followed adoption. A 2026 disclosure concerning MCP SDK transport handling reportedly exposed a very large number of vulnerable instances across IDEs, internal tools and cloud services — a reminder that early protocol design decisions create systemic risk later.
What MCP does not give you
Authorisation remains your design problem
The protocol standardises how tools are exposed, not who may invoke them. The consequential question — may this agent, acting for this user, perform this action on this record — is application-level design.
Agents inheriting broad service-account permissions are the standing risk, and standardisation makes accumulating that risk faster. The MCP specification’s 2026 update introduced incremental scope consent, letting clients request only the minimum access needed per operation rather than everything upfront. Using it requires an authorisation layer that understands tool-level semantics, not just network routing.
A semantic control layer
Post-incident analyses of agent compromises share an architectural root cause: nothing was evaluating whether what the agent was about to do was consistent with what it was authorised to do. Perimeter controls, network monitors and endpoint agents observed the traffic and recorded no violation, because they were never designed to see what the agent was being instructed to do.
Data-exposure boundaries
Once an agent can query a system, whatever it retrieves enters context and may surface in outputs or logs. Under India’s DPDP Act — Rules notified November 2025, full enforcement expected May 2027 — the operative questions are what a tool can return, what lands in trace logs, and how long those logs persist. Full-trace instrumentation is invaluable for debugging and quietly creates a new personal-data store with its own obligations.
A deployment pattern that holds up
Defence in depth is the only durable answer — no single control limits blast radius.
- Allowlist servers. Maintain an internal registry of approved MCP servers; do not let agents connect to arbitrary endpoints.
- Treat servers as dependencies. Review tool descriptions on adoption and re-review when a server updates, exactly as you would a dependency changelog.
- Bind identity. Propagate user identity to the tool call so authorisation evaluates against the actual person, not a shared service account.
- Scope credentials narrowly, per server, read-only wherever read-only will do. Adopt incremental scope consent where supported.
- Classify tools by risk and enforce human approval for destructive or irreversible operations — deletions, transfers, bulk modifications, outbound communications. The specification itself contemplates a human able to deny invocations.
- Log every invocation with enough context to reconstruct why it happened, with redaction rules defined before instrumentation scales.
- Monitor at runtime for behavioural anomalies rather than relying solely on static review.
The strategic read
MCP is becoming infrastructure, and that is a good outcome. Standard interfaces reduce lock-in and make architectures more portable than they were.
The mistake is treating adoption as primarily an engineering convenience. The protocol makes it dramatically easier to give agents access to enterprise systems, so the governance question arrives faster and matters more than when every integration was individually laborious.
The friction that used to slow this down was accidental, but it was doing real work. Standardisation removes it. Deliberate authorisation design has to replace it — and AI agents should now be treated as privileged identities, governed with the monitoring and least-privilege discipline applied to administrator accounts.
Frequently asked questions
What is MCP tool poisoning?
An attack where malicious instructions are hidden inside tool metadata — descriptions and parameter schemas — that the agent reads to decide which tool to call. Unlike conventional prompt injection it is persistent: it ships with the server or package and executes on every invocation until detected.
Does MCP handle authentication and authorisation?
Not on your behalf. MCP standardises how tools are exposed, not who may invoke them. Enterprise deployments need an authorisation layer understanding tool-level semantics, with user identity propagated to the tool call rather than agents acting through shared service accounts.
How should enterprises secure MCP deployments?
Defence in depth: an allowlist registry of approved servers, tool-description review on adoption and update, identity binding, narrowly scoped credentials, human approval gates for destructive operations, comprehensive invocation logging, and runtime behavioural monitoring.
Is MCP covered by security frameworks?
Yes. The OWASP Top 10 for Agentic Applications, released December 2025, includes tool misuse and agentic supply chain vulnerabilities as named categories covering these risks.
