The Model Context Protocol solved a real integration problem for AI agents. It did not solve authorization — and treating the two as the same thing is how agent deployments get quietly overexposed.
The problem MCP actually solves
Before late 2024, every AI application that wanted to connect a language model to a database, a file system, or a SaaS API had to write a custom integration for that specific combination. Anthropic introduced the Model Context Protocol (MCP) as an open standard to fix this: a common client-server interface so any MCP-compatible model can discover and call tools exposed by any MCP-compatible server, without bespoke glue code for each pairing.
That part of the story is genuinely useful and widely adopted since. It is also the part everyone already knows. The part that matters more for anyone actually running agents in production is what MCP deliberately leaves unspecified.
What the specification does not decide for you
MCP defines how a model discovers a tool, how it calls that tool, and how the tool’s result comes back. It does not define who is allowed to invoke which tool, under what conditions, with what data, or what happens when the tool’s own output cannot be trusted. Those are authorization and provenance questions, and the protocol hands them to whoever implements the server and the client — which in practice means they get handled inconsistently, or not at all.
This shows up in a few recurring patterns that security researchers and practitioners have already documented publicly:
Tool descriptions as an injection surface
An MCP tool’s name and description are themselves untrusted text that gets fed into the model’s context. A malicious or compromised server can embed instructions inside that metadata, and a model that treats all context as equally authoritative may follow them.
Overbroad scopes by default
Many MCP server implementations expose a single API credential to every tool call, rather than scoping each tool to the minimum permission it needs. An agent that only needs to read a calendar can end up holding write access to the same account.
Trusted tool output
A tool’s return value is data, but nothing in the protocol stops a model from treating it as an instruction — the same confused-deputy problem that predates MCP, now with a standardized transport that makes it easier to chain across servers.
No native audit trail
MCP defines the call and the response. It does not require a durable, independently-verifiable record of which tool ran, with which parameters, under whose authorization, with what result — which is precisely what an incident investigation needs after the fact.
Where this connects to how IVE is built
We use MCP-style tool-calling in IVE’s own execution loop, and the four gaps above are exactly why the architecture does not stop at “give the model tools.” Two pieces we’ve already written about directly address them:
PROPOSED
POLICY CHECK
EXECUTION
RECEIPT
The Human Gate sits between “the model wants to call a tool” and “the tool actually runs,” so a broad or unexpected scope gets a policy check instead of a silent pass-through. The Execution Receipt gives every completed call the durable record MCP itself doesn’t require, so “what did the agent actually do” is answerable without trusting the agent’s own narration of events.
Both patterns are live in IVE’s current implementation, described in the linked pieces below.
Neither pattern is MCP-specific tooling — they’re architectural layers we built around tool-calling in general. We are not claiming to have patched the MCP specification itself, and per-tool scoping in our own server integrations is an ongoing hardening effort, not a finished state.
What this means if you’re integrating MCP servers
The practical takeaway isn’t “avoid MCP.” It’s that adopting the protocol doesn’t give you authorization or auditability for free — you still have to design for them, the same way you would for any tool-calling system, standardized transport or not. Questions worth asking before connecting a third-party MCP server to a production agent: what credential does this server actually hold, is it scoped to what the agent needs or to everything the underlying API allows, and if this tool call turns out to have been wrong, is there a record that lets you reconstruct why it happened.
Related: tool-level authorization is one layer. The data layer underneath it needs its own control — see why agents need Row-Level Security, not just scoped tools.