MCP servers are creating a security problem most teams haven't noticed yet
MCP servers let AI agents access your APIs without custom code. Most weren't built for production security. That gap between "works in demo" and "safe at scale" is where the liability lives.
Teams are adopting the Model Context Protocol to let AI agents interact with APIs without custom integration work. The promise is efficiency—agents can pull customer data, send notifications, execute workflows across multiple systems. But most available MCP servers weren't built for production security. That gap between "works in demo" and "safe at scale" is where the liability lives.
I'm seeing three failure modes that keep showing up: servers with no real authentication, agents with way too much access, and attacks that compromise the agent to exploit everything downstream.
How MCP actually works
Anthropic built the Model Context Protocol to standardize agent-API interaction. An MCP server sits between your AI agent and a system's API, translating function calls into a format the agent understands from its training data. When an agent needs customer records or wants to trigger a notification, it goes through the MCP server.
This abstraction layer removes the complexity developers usually handle. The agent interprets API documentation and executes calls programmatically. No custom integration needed for each new connection.
That's the value proposition. It's also the attack surface.
Three ways this breaks
MCP adoption accelerated before security caught up. Many servers originated as quick builds—individual developers, beta programs, proof-of-concept demos. They solve the interoperability problem but create new vulnerabilities.
Poor authentication exposes your data
Some MCP servers ship with weak authentication or none at all. A server handling sensitive corporate data needs production-grade security. When authentication is missing or trivial to bypass, you're one exposed endpoint away from unauthorized access to everything that agent can touch.
Early at Silver Spring Networks, I approved a dataset integration without verifying the security controls. Three months later we discovered the access logs showed queries we never authorized. The remediation cost $200K and took four weeks. Now I use a four-question security protocol that takes 15 minutes upfront.
Excessive permissions violate least privilege
The second problem is agents getting access to more than they need. An agent designed to scan new emails for urgent items and text one user shouldn't have access to all historical emails, personal files, calendar entries, and the ability to message anyone in the organization.
That misalignment between stated purpose and actual capabilities expands your attack surface. When an agent has blanket access, a single compromise affects everything it can reach.
At Atlassian, we scaled requirements for 5,000+ marketplace partners. The ones who succeeded built permissions into their architecture from day one. Companies that granted broad access initially spent months in remediation when audits caught the gaps.
Agent compromise amplifies the damage
Even with a secure MCP server, the connected agent remains vulnerable to prompt injection and data poisoning attacks. An attacker feeds the agent malicious instructions to trick it into unauthorized actions.
A compromised agent can exfiltrate data using its legitimate tools. It queries your CRM or HR database, retrieves records, sends them back to the attacker. Worse, the agent can be manipulated into revealing its own credentials—API tokens that give the attacker direct, persistent access bypassing the agent entirely.
Engineering controls that matter
For teams building with MCP servers, three controls are non-negotiable:
Restrict agent access to minimum required scope. When evaluating platforms, prioritize granular permission controls. Even if an agent gets compromised, narrowly defined capabilities limit the blast radius.
Build user confirmation prompts into the workflow at the code level. Before any high-stakes or irreversible action, the agent pauses for explicit human approval. This creates a technical check against errors and malicious instructions.
Conduct actual due diligence on third-party MCP servers. Select platforms from organizations demonstrating security commitment—maintenance schedules, transparent vulnerability management, adherence to modern security practices. "Works in the demo" isn't the same as "safe in production."
What legal and compliance teams need to do
AI agents using MCP to access sensitive data fall under existing data governance and third-party risk management policies. This requires specific legal oversight:
Enforce third-party risk management for all AI tooling vendors. Review security certifications (SOC 2, ISO 27001), data processing agreements, incident response capabilities. Legal teams own this to mitigate vicarious liability.
Create written policies defining which data categories AI agents can access. This governance mandates technical implementation of least privilege, requiring legal and business collaboration to classify data and approve access rights. Agent permissions can't violate internal policies or external privacy regulations.
Review and approve the tools an agent can use through a governance process. Legal, risk, and product teams must collaborate to define and document authorized scope. Any expansion of capabilities or data access triggers formal risk assessment and approval.
Where this goes
The Model Context Protocol shifts API integration from human developers to AI agents. That creates efficiency gains and novel risks in the same motion.
Start by inventorying all agent-based tools in your environment and limiting their data access according to least privilege. Then monitor two fronts: the security maturity of third-party MCP platforms you're using, and the evolution of agent-focused attack vectors like prompt injection.
The integration speed that makes MCP valuable is also what makes it risky. Teams building governance infrastructure now will move faster than teams retrofitting it later.
This is issue-spotting and strategic analysis, not legal advice for your specific situation. Regulatory requirements vary by jurisdiction—confirm with counsel familiar with your specific market.
