MCP architecture allows AI agents to reach enterprise file systems and databases. It can also connect them to SaaS platforms using credentials that many identity programs may not have in their inventory. The Cloud Security Alliance reports that regulators are increasingly requesting agent control logs.
The design choices that accelerated adoption also created activity many security stacks weren’t built to inspect. Tool descriptions can include instructions that users don’t see, while local server activity often stays off the network. MCP architecture can also let agents inherit credentials outside an identity program’s inventory.
To understand that exposure, start with how the architecture works and where its trust boundaries need additional controls. If you’re already fielding board questions about AI agents, you’ve seen how quickly this gets tangled. This article also walks through how to close the gap through workforce governance and runtime protection.
Key takeaways
- MCP’s host-client-server design allows models to discover and invoke external tools, but tool instructions can enter model context before users approve an action.
- The primary security gaps are poisoned or changeable tool descriptions, local servers that evade network monitoring, and inconsistent authorization that can expose shared credentials and privileges.
- Effective MCP governance combines a current server and agent inventory with deny-by-default policies, intent-aware enforcement, pre-execution controls, human review for consequential actions, and identity-linked audit records.
- Protocol updates improve some authorization mechanics but don’t eliminate Shadow MCP, prompt injection, or tool poisoning, so you still need an independent enforcement layer.
What is MCP architecture?
MCP architecture is a client-host-server model with three roles that together determine where consent, permissions, and tool access get enforced. It follows a client-host-server model with three distinct roles:
- Host: The application the user interacts with, such as Claude Desktop, an AI-enabled IDE, or a CI/CD pipeline. The host creates client instances and manages connection permissions and consent requirements as the security policy point.
- Client: An instance spawned by the host that connects to exactly one server and brokers requests between the model and that server.
- Server: The process that exposes tools, resources, and prompts to the model through its connected client.
MCP is an open standard connecting AI models to enterprise systems. It emerged in late 2024 and has since been adopted by major model providers and platform vendors, making it a common integration point for agentic workloads.
Each server offers three primitives: tools, resources, and prompts. Tools are the most consequential for security because they’re designed to control models. This means the language model can discover and invoke tools automatically.
When a client calls tools/list, the server injects tool descriptions directly into the model’s context window. The approval dialog has not fired at that point. That discovery step happens before a human approval step occurs.
The July 28, 2026 specification revision, the largest revision to date, made the protocol fully stateless. That removes the single session-establishment moment where security checks used to concentrate.
You Can’t Secure What You Can’t See
WitnessAI gives you network-level visibility into every AI interaction across employees, models, apps, and agents. One platform. No blind spots.
Explore the PlatformWhere MCP requires additional security controls
MCP architecture ships with trust boundaries you have to shore up outside the protocol. Controls trailed adoption as MCP use expanded. Three properties of MCP architecture explain why that scale concerns security leaders.
1. At the discovery step, where tool descriptions reach the model
Tool poisoning operates through the discovery step. Instructions embedded in a tool description are invisible to the user at the interface layer but fully readable by the model. They take effect the moment tools/list returns. The injection occurs without invoking a tool, so the approval dialog users typically expect doesn’t appear.
Tool poisoning and supply chain attacks are cataloged as distinct risk classes. Shadow MCP servers are another. The rug pull variant compounds the problem: a server can silently change a tool’s description after the user has approved it. The protocol offers no authenticity verification, so approval granted on day one says nothing about day thirty.
2. At the local stdio boundary, where servers evade network inspection
Local stdio servers stay off the network, so network-layer controls have little to see. A local stdio server runs as a subprocess with the launching application’s operating system privileges. It communicates through inter-process channels on a single machine.
Network controls have little to observe because local stdio traffic remains on a single machine. This limitation affects proxies and CASBs, as well as DLP tools designed for network traffic.
The official specification is blunt about the consequence: “Arbitrary code execution. Attackers can execute any command with MCP client privileges. No visibility. Users have no insight into what commands are being executed.” The impact depends on deployment configuration and server trust, but the risk illustrates why additional enterprise controls are required.
The architecture creates this limitation, though configuration can affect its scope. Developers installing MCP servers in Claude Desktop or VS Code create Shadow AI deployments that browser-based monitoring has limited visibility into. Cursor installations can do the same. Long-lived API keys can then sit on laptops, outside enterprise IAM and rotation policies.
3. At the authorization layer, where identity rarely follows the agent
The 2025-06-18 specification made OAuth 2.1 mandatory for remote deployments. In practice, authorization in MCP remains optional, as not every implementation uses it, per NSA guidance issued in May 2026.
MCP authorization remains an area that enterprises should evaluate carefully. Depending on deployment architecture, user identity may not consistently propagate end-to-end. As a result, a server can run with one shared credential set across users. An attacker who can steer the model borrows that authority without directly stealing credentials.
CVE-2025-6514, rated CVSS 9.6, let a malicious server execute operating system commands
Knowing Which AI Tools Are in Use Is Just the Start
WitnessAI goes beyond app discovery. Observe classifies the intent behind every AI interaction across employees and agents, so you can build smarter policies based on real risk, not guesswork.
Explore ObserveSecuring MCP architecture through AI risk management
AI risk management gives your team audit trails they can review against governance policies and compliance checklists. It combines visibility and intelligent policy with runtime enforcement and audit trails of what happened. Four controls, applied in sequence, address the gaps above.
1. Build a live inventory of agents and MCP servers
Allowlisting depends on knowing what exists, so discovery comes first. That means identifying agentic sessions at the network level for remote connections and cataloging local agent frameworks and IDE plugins.
You can then map which MCP servers and downstream systems each agent reaches. Inventory work can reveal prohibited public use of GenAI that existing controls failed to capture.
Once inventoried, servers and tools move to deny-by-default allowlists. Alerting when a tool description changes after approval shortens the window a rug pull can exploit.
2. Classify intent instead of matching keywords
Intent-based classification helps detect poisoned tool descriptions and staged exfiltration attempts that keyword-based approaches often miss. A poisoned tool description rarely carries a regex signature. A staged exfiltration prompt also rarely includes the word “confidential.” Keyword and regex matching may struggle to distinguish a legitimate summarization request from data theft dressed as one. The difference lives in conversational context and purpose.
Intent-based classification, powered by intent-based machine learning engines, analyzes what the user or agent is actually trying to do. This approach is better matched to the threat. Enforcement should also offer more than a binary allow-or-block. Warning a user or routing a sensitive query to an approved internal model protects data without halting work.
3. Put runtime guardrails between agents and execution
Discovery and policy govern what connects; runtime guardrails govern what happens next. Pre-execution protection scans prompts and tool calls before an agent acts. This provides bidirectional protection across what goes into a model and what comes back. Response protection scans outputs before they reach users or downstream tools.
Actions such as deleting records or sending external communications can be difficult to reverse. The same applies when an agent commits transactions. A human checkpoint at execution time limits how far a compromised agent can go in terms of actions like those.
These guardrails complement existing network security controls by inspecting conversational context those controls weren’t originally designed to parse
Runtime AI Threats Need Runtime Defense.
WitnessAI’s enterprise AI firewall delivers bidirectional runtime defense, blocking prompt injections, jailbreaks, and data exfiltration before they reach your models or your customers.
Explore Protect4. Keep audit trails that tie agent actions to people
The OWASP MCP Top 10 identifies lack of audit and telemetry as a distinct MCP risk class.
To meet that standard, record prompts, responses, tool calls, and the human identity behind each agent invocation in an immutable audit trail. An agent that promises a refund or commits a contract term can create a legal obligation. It also creates a brand-facing statement.
The same attribution record can support Legal and Compliance reviews. Marketing teams can use it too. These audit trails link each agent action to the person who initiated it. Reviewers then have a clear account of the incident.
Blocking AI Isn’t a Strategy. Governing It Is.
WitnessAI enforces intent-based policies, routes prompts to the right models, and redacts sensitive data in real time so your teams keep moving while your data stays protected.
Explore ControlClosing the MCP visibility gap before agents scale
You can adopt MCP architecture without consistent enterprise visibility, and many teams already have. The specification delegates consent and access control to MCP implementors handle. It also delegates data protection. You’re still responsible for an enforcement layer, even if you haven’t built one yet.
With inventory, intent-based intelligent policies, runtime guardrails, and attribution in place, you can show boards and examiners clear evidence of AI control. WitnessAI’s platform provides security and AI teams with a shared framework.
To see how these controls apply to your own MCP deployments, schedule a demo with our team.