Model Context Protocol Has a Security Debt

The Model Context Protocol (MCP) has moved from a developer convenience to a serious integration layer in the AI stack. It solves a real problem: assistants are far less useful when they cannot read files, query databases, open tickets, search internal docs, or call domain-specific tools. MCP gives teams a common way to expose those capabilities without writing a different connector for every model vendor and chat client.

That standardization is useful. It is also why security teams should pay attention now. A protocol that lets an AI client discover tools, read resources, and pass prompts into external systems is not only a developer interface. It is an authorization surface, a supply-chain surface, and a data leakage surface. Because it often sits between a conversational model and sensitive business systems, failures may look less like classic API bugs and more like workflow mistakes: the assistant trusted hostile instructions, called the wrong tool, or moved private data into the wrong place.

The concern is not that MCP is uniquely unsafe. The concern is timing. Companies are racing to connect AI assistants to daily work, and MCP is arriving as the neatest way to do it. Anthropic’s documentation describes MCP as a standard for giving LLM applications context through servers and clients (Model Context Protocol introduction). That framing is right, but it also means MCP lives at the boundary where context can become action. Boundaries are where mature software programs spend years adding guardrails.

MCP is plumbing, not magic

MCP defines a common shape for tools, resources, and prompts. Tools are executable functions, such as creating a ticket or running a query. Resources are data the model can inspect, such as files or records. Prompts are reusable instruction templates. In practice, an MCP server becomes a gateway that exposes part of another system to an AI client.

This is cleaner than one-off plugins hidden inside each chat product. A shared protocol can make integrations easier to inspect, test, and reuse. But plumbing spreads. Once one useful server exists, teams ask for more: GitHub, Slack, Google Drive, Notion, Jira, PostgreSQL, observability tools, deployment systems, and internal dashboards. Each server adds the same questions: what is the model allowed to do, under whose identity, with what approval path, and with what audit trail?

The demo version is often read-only search. The production version may update customer records, post messages, trigger builds, or run shell commands. The protocol can carry both. The difference is not the protocol name. The difference is the control plane around it.

The old API model only partly fits

Traditional API security assumes a known caller hits a known endpoint. The request is shaped by application code. Permissions tie back to a user, role, or service identity. Logs capture enough metadata for investigation. Engineers reason about validation, injection, access control, and rate limits.

AI tool use changes the call. A user may ask a broad question, the model may decide which tool to call, and the tool output may become part of the next model input. That loop creates space for indirect prompt injection: hostile instructions hidden in a document, web page, issue comment, support ticket, or email that the assistant later reads. OWASP’s Top 10 for LLM applications treats prompt injection, sensitive information disclosure, excessive agency, and supply-chain risk as core issues, not edge cases (OWASP Top 10 for LLM Applications).

MCP does not remove those risks. It can make them easier to centralize, but only if teams treat MCP servers as policy enforcement points rather than thin wrappers around powerful APIs. If a server exposes a `send_message` tool, the model should not be the only thing deciding whether a message leaves the company. If a server exposes a `query_database` tool, the model should not receive unrestricted results because it asked nicely.

Tool descriptions are not security boundaries. A natural-language description that says “use only for approved tickets” may help the model, but it is not authorization. Security belongs in code, identity, configuration, and review.

A practitioner test: trace authority first

When I evaluate an AI workflow for production use, I rarely start by asking which model is smartest. I start by tracing authority. What identity does the tool use? Can the user see the same data without the assistant? Can the model combine two low-risk actions into one high-risk action? What happens if a document tells the model to ignore prior instructions? Where is the approval recorded?

In one prototype, the assistant only needed to summarize support tickets and draft replies. On paper, that was safe: no autonomous refunds, no account changes, no outbound email without review. The weak point was the connector. It used a broad service token because that was faster than mapping each request to the current user. The model was not misbehaving; the integration was overpowered. A harmless summarizer had inherited access to tickets outside the test group’s scope. The fix was scoped credentials, server-side filtering, and logs tying each tool call back to a human request.

That is the MCP lesson in miniature. The visible novelty is the protocol. The hard work is familiar: least privilege, isolation, review, observability, and change management.

Reuse creates supply-chain risk

MCP encourages reuse, which means teams will download or copy servers written by others. Some will come from vendors. Some will be open source. Some will be quick internal projects that become permanent because they work. This is how software supply-chain risk usually grows: through many small dependencies that nobody fully owns.

A weak MCP server can do more than return bad data. It can mishandle credentials, log sensitive prompts, expose unsafe tools, or translate a narrow request into a broad backend API call. Even a good server can drift as the system it wraps changes. A new permission in the upstream SaaS product may quietly expand what the server can do.

Treat MCP servers like other sensitive dependencies. Pin versions. Review code. Track maintainers. Keep secrets out of local config files where possible. Run servers with constrained permissions. Require an owner. If the server can touch production systems, it deserves production-level review.

NIST’s AI Risk Management Framework is useful because it emphasizes governance, system context, measurement, and ongoing controls rather than treating AI risk as model behavior alone (NIST AI RMF 1.0). MCP deployments need that lifecycle view. A server that is safe during a pilot can become unsafe when connected to a broader user group, a more capable model, or a different client.

Consent needs to be specific

Many AI clients will ask users for permission before tools run. That sounds simple until the approval text becomes vague: “Allow assistant to access Drive” or “Run database query.” Users cannot make meaningful decisions from labels that broad. They need to know what will be accessed, why, what will be changed, and whether the action can be undone.

AI tool calls add a twist because the user may not have selected the tool; the model selected it as part of a plan. A better consent flow is concrete: “Search these five documents for renewal dates” is far more useful than “Access files.” For write actions, approval should show the exact proposed change. For high-risk actions, approval should happen outside the same chat loop so a poisoned document cannot simply talk the assistant through the click.

Regulation points in the same direction. The EU AI Act pushes organizations toward traceability, risk controls, and human oversight for higher-risk AI uses (EU AI Act overview). MCP-based agents that affect customers, employees, finances, or operations will not get a pass because they are “just integrations.”

Logs should explain why, not only what

Classic API logs say endpoint X was called at time Y by identity Z. Agentic workflows need more context. Investigators also need to reconstruct why the tool was called. What user request started the chain? What resources did the model read? What arguments were passed? Was there human approval?

Design event records that answer operational questions without becoming a new data dump: user ID, client ID, server ID, tool name, resource identifiers, policy decision, approval status, timestamp, result class, and a bounded reason string.

Without this, an incident may look like a normal API call from a service account even though the real cause was a poisoned document read three steps earlier.

Sandboxes beat heroic prompts

Safe MCP deployments should assume models make mistakes. That assumption leads to practical choices.

Prefer user-delegated identity over broad service accounts. If the assistant is helping Alice, the server should usually see Alice’s permissions, not an all-access bot token. Split read and write tools. A server that can read tickets does not automatically need to close them. A server that can draft an email does not automatically need to send it.

Put policy near the MCP server. Do not rely on every client to behave perfectly. A server can enforce allowlists, row-level filters, rate limits, argument validation, and approval requirements. It can also block tool calls that mix untrusted content with sensitive actions.

Isolate execution. If a server runs local commands, accesses files, or handles credentials, run it in a constrained environment. Containers, restricted filesystem mounts, sandboxed processes, and short-lived tokens are boring controls. Boring is good.

Finally, test with hostile content. Put adversarial instructions inside documents, comments, calendar invites, and web pages. See whether the assistant follows them. More important, see whether the server would allow damage if it did.

The near-term playbook

Organizations should not ban MCP by default. They should classify it correctly: MCP servers are integration services with AI-facing interfaces. If they touch production data, treat them like production software.

Start with inventory. List every MCP server in use, including local developer machines if those servers connect to company systems. Record the owner, repository, version, credentials used, exposed tools, connected clients, and data classes. Then assign risk tiers. A read-only server for public docs is not the same as a server that can query customer databases or deploy code.

For higher-risk servers, require scoped identity, code review, secret management, logging, and a rollback plan. Add human approval for irreversible or externally visible actions. Build tests for prompt injection and data leakage. Review tool descriptions as user experience, not policy: they should help the model choose correctly while the server enforces what is allowed.

MCP is useful because it makes AI integrations less chaotic. But standardization accelerates adoption, and adoption exposes weak assumptions. The next phase should not be fear. It should be engineering discipline. If companies build MCP deployments with narrow authority, clear consent, strong logs, and hostile-input testing, the protocol can become a stable layer in the AI stack. If they treat it as a quick way to give models more power, they will rediscover old security lessons through new incidents.