What stops enterprises from adopting MCP safely?

Enterprises struggle to adopt the Model Context Protocol (MCP) because agents gain tool access that needs identity, permission limits, audit and protection against manipulated inputs. The protocol standardizes how tools connect. It does not decide who may use which tool, so your organization has to.

What is MCP, briefly?

MCP is an open protocol that lets AI applications connect to external tools and data through servers that expose capabilities. A model or agent asks a server to run a tool, such as reading a ticket or querying a database, and receives a result. The specification includes an authorization section that describes how clients obtain access to protected servers using OAuth based flows.

That helps with connecting. Enterprises care just as much about what happens afterwards.

What are the main challenges?

1. Inventory. Developers can add an MCP server to their editor in minutes. Security teams often cannot answer which servers are in use, who runs them or what they can reach.

2. Identity. Is the tool call made as the user, as a shared service account or as the agent itself? A shared token with broad scope makes every call look the same in logs and gives a compromised agent wide reach.

3. Permissions. Servers may expose many tools, including write and delete actions. Teams rarely want an assistant to have every one of them on every task.

4. Untrusted content. Tool results and documents can contain instructions written by someone else. An agent that reads a web page or ticket may treat that text as a command. OWASP's guidance on large language model risks lists prompt injection as a top concern for this reason.

5. Data movement. A tool that reads a customer record and a tool that sends email can, together, move data out. The risk is in the combination.

6. Audit. Compliance reviewers need to see who asked for what, which tool ran and with what result. Chat logs alone rarely give this.

7. Third party servers. Servers written by outsiders are software supply chain components. They need the same review as any dependency: source, maintainers, update path.

A constructed example

A support team connects an assistant to a ticketing server and an internal wiki server. A customer ticket contains text telling the assistant to look up "the admin runbook" and paste it into its reply. The assistant, with a broad token, complies. No exploit was needed. The failure was a read tool with wide scope, no screening of tool output, and no rule that sensitive documents stay out of customer facing replies.

What controls help?

• Register every server. Keep a catalogue with owner, purpose, tools exposed and data reachable. Block unregistered servers at the managed device level if you can.
• Use per user or per agent identity. Prefer short lived, narrowly scoped credentials to shared long lived keys.
• Allow list tools. Enable only the tools a task needs. Separate read from write.
• Require approval for high impact actions, such as deleting data or sending external messages.
• Treat tool output as untrusted input. Screen it, and never let it expand the agent's permissions.
• Log every call with identity, tool, arguments and outcome, and store logs where agents cannot change them.
• Review servers like dependencies, with pinned versions and change review.

Safeguard offers an MCP server with unlimited tool calls on every plan, and an MCP Guardrail that applies policy to tool use. These are examples of the control categories above, not a replacement for your own server catalogue.

How to check or apply this

1. Ask each engineering team which MCP servers they use. Write down the answers.
2. For each server, list tools and mark the ones that write, delete or send.
3. Replace any shared token with per user access where the server supports it.
4. Pilot approvals on write actions for one team.
5. Add an MCP review to your third party software intake.
6. Test with a harmless planted instruction in a test document and see whether an agent follows it.

Quick check

Sources

• Model Context Protocol, Authorization specification (2025-06-18)
• OWASP Top 10 for Large Language Model Applications
• NIST SP 800-218, SSDF

Last reviewed: 18 October 2026.