The Model Context Protocol and the Agent Tool Layer
By Satwik ยท June 2, 2026
MCP is an open protocol that standardizes how models connect to tools and data sources, turning bespoke integrations into a common interface. Standardizing the tool layer is a real advance and a real risk, because unscoped permissions and untrusted servers become a shared attack surface.
What MCP standardizes
The Model Context Protocol, introduced by Anthropic in late 2024, addresses a mundane but real problem. Before it, every connection between a model and an external tool or data source was a custom integration. Each agent framework had its own way to define tools, and connecting a model to a database, a file system, or a SaaS API meant bespoke glue code that did not transfer. MCP defines a common protocol so any compliant client (a model application) can talk to any compliant server (a tool or data provider) through a standard interface for exposing tools, resources, and prompts.
The analogy people reach for is a universal port for AI integrations, and it is apt. A single MCP server for, say, a ticketing system can be reused across any MCP-aware agent, and an agent can discover and use tools from many servers without custom code per tool. This is genuinely useful plumbing, and its rapid adoption reflects how badly the ecosystem needed a standard rather than a proliferation of incompatible tool schemas.
Why it mattered
Standardization compounds. Once there is a common protocol, an ecosystem of reusable servers grows, and building a capable agent shifts from writing integrations to composing existing ones. That lowers the cost of connecting models to real systems, which is the bottleneck that kept many agent projects from production. MCP is, in effect, the interoperability layer for the agentic era, and interoperability layers tend to become durable infrastructure precisely because everyone standardizing on them raises the cost of not standardizing.
The protocol also cleanly separates concerns. The model application handles reasoning and user interaction; the server handles the actual capability and its credentials. In principle this separation is good security hygiene, because it puts the tool's authority in the tool's process rather than smeared through the agent. The question is whether deployments actually use the separation that way.
The security angle: standardizing the tool layer standardizes the attack surface
Everything our lab has argued about tool-using agents applies to MCP, and MCP raises the stakes by making the tool layer uniform, discoverable, and widely shared. That is the double edge of any standard: a common interface for benign integration is also a common interface for malicious ones.
Unscoped permissions are the first concern. An MCP server is granted credentials and access to do its job, and the temptation is to grant broadly, full database access, full file-system access, a powerful API token, so the agent can do whatever a user might ask. But the agent's actions are driven by natural-language input that may be partly attacker-controlled through injection. An over-permissioned server hands broad authority to a system that can be socially engineered. Least privilege is the single most important control, and it is the one most easily neglected because narrow scoping is more work than a blanket grant.
The second concern is untrusted servers as a supply chain. If MCP servers are shared and installed the way software packages are, then installing one is running third-party code that receives your data and holds your credentials. A malicious or compromised server can exfiltrate everything it sees, and because it sits inside the agent's trusted tool set, its outputs are also injection vectors into the model's reasoning. This is the LoRA supply-chain problem transposed onto the tool layer: convenience drives adoption of opaque third-party components that operate with real privilege. Provenance, signing, and vetting of servers matter as much here as anywhere.
The third concern is the confused-deputy and tool-poisoning problem at protocol scale. A server describes its tools to the model, and those descriptions are text the model reads. A malicious server can write tool descriptions that themselves carry injected instructions, poisoning the agent's behavior the moment the tools are listed, before any tool is even called. More broadly, an agent connected to many servers composes their capabilities, and the union of permissions across all connected servers is the real attack surface, not any single server in isolation. A read tool on one server plus a send tool on another is exfiltration, regardless of which vendor shipped each.
The fourth concern is cross-server data flow. When an agent can read from one connected system and write to another, sensitive data can move across trust boundaries that were never meant to connect, driven by a model following instructions that may have been injected. The protocol makes it easy to wire systems together; it does not, by itself, enforce which flows are allowed.
Practical guidance
Scope every server to the minimum access its task requires, prefer read-only, and use short-lived, narrowly-scoped credentials rather than broad standing tokens. Treat server installation as a dependency decision with provenance, signing, and review, not a one-click add. Treat tool descriptions and tool outputs as untrusted input to the model, because a malicious server controls both. Keep human confirmation on consequential actions, and enforce policy on cross-server data flows at the application layer rather than trusting the agent to self-govern. Log every tool call across every server so the composed behavior is auditable.
MCP is the right kind of infrastructure and a real step toward a mature agent ecosystem. Our thesis is that it makes the tool layer a first-class security boundary, and the discipline that boundary demands, least privilege, provenance, and control over composed permissions, is exactly the discipline the rush to connect everything tends to skip.