What is the Model Context Protocol (MCP)?

It turns the tool list an agent can reach into something portable, discoverable at runtime and usually authored by someone other than the team that owns the agent.

That last clause is the security story. MCP made agents more useful and, at the same time, moved a large part of an agent's effective authority into configuration files that nobody reviews.

Why does MCP matter now?

MCP spread because it solved an unglamorous problem. Before it, connecting an agent to Jira, a database, a browser and a filesystem meant four bespoke integrations, four auth models and four sets of bugs. With MCP, a host application speaks one protocol and the integrations become servers that anyone can publish.

Adoption followed the same path as the rest of agent tooling. In the 2026 Stack Overflow survey, 73% of respondents used coding assistants and agents daily, and coding assistants and agents were the top AI use case at 66% (Stack Overflow Developer Survey 2026). The tool layer grew underneath that usage, and it grew in public package registries rather than through internal review.

The result is a large, uneven supply chain. A survey of 5,200 open-source MCP servers found that 88% require credentials, 53% rely on long-lived static secrets, only 8.5% use OAuth, and 79% pass API keys through environment variables (State of MCP Server Security 2025, Astrix). A separate study of 1,899 servers found 7.2% with general vulnerabilities and 5.5% showing MCP-specific tool poisoning (MCP at First Glance, arXiv:2506.13538).

The attack surface is not theoretical. A command injection flaw in the mcp-remote client, reachable when connecting to an untrusted server, was rated CVSS 9.6 (CVE-2025-6514). Tool poisoning, where instructions are hidden in a tool description rather than in the data, was demonstrated against Cursor reading SSH keys and configuration files (Invariant Labs). In a study of 20 agents and 45 live servers, o1-mini was steered by a poisoned tool 72.8% of the time, and no model refused more than 3% of attacks (MCPTox, arXiv:2508.14925).

Free Agent Exposure Report: see which MCP servers and clients are already on your endpoints, read-only and in minutes: alyria.ai/agent-exposure-report.

How does MCP work?

MCP is deliberately small. It defines a message format and a lifecycle, and leaves policy to everyone else. That is why it is easy to implement and why governance has to come from outside the protocol.

Host, client, server. The host is the application a person uses, such as an IDE or a desktop assistant. Inside it, one client per connection speaks the protocol to a server. The server exposes capabilities. A host with five servers has five clients and a tool list assembled from five suppliers.

Three primitives. Tools are callable functions with a JSON schema, and they are the part that changes systems. Resources are readable content addressed by URI. Prompts are reusable templates the host can surface. From a security view, tools carry the action risk, resources carry the data reach, and prompts carry an instruction channel.

Transports. Servers run either as a local subprocess over standard input and output, or remotely over HTTP. The local case is why endpoint visibility matters: a stdio server is a process on a laptop that never appears in network logs.

Capability negotiation. During initialisation the client and server exchange supported features, and the tool list arrives at runtime. An agent's effective capabilities are therefore a function of configuration plus whatever the server reports today, which can change without the agent's code changing.

How is MCP different from an API or a plugin?

A REST API is designed for code that knows what it wants. An MCP server is designed for a model that chooses at runtime from descriptions written in natural language. Three differences carry security weight.

Dimension	REST API integration	Plugin or SDK	MCP server
Who decides what to call	The developer, at build time	The developer, at build time	The model, at runtime
How capabilities are described	OpenAPI schema and documentation for humans	Typed interface in code	Tool name, schema and prose description the model reads
Discovery	Known endpoint per service	Compiled in	Negotiated at connection time, can change between sessions
Credential model	App secret or OAuth client	Usually app-level	Often per-server key in config, increasingly OAuth
Failure mode	Wrong call by code	Wrong call by code	A tool the owner did not expect, described persuasively
Governance point	API gateway and code review	Build pipeline	Registry, endpoint visibility and per-call policy

In practice: An API gateway governs calls your code makes. MCP governs calls a model chooses, which is a different problem with a different control point.

What are the main risks in MCP?

The risks cluster around three questions: what a server is, what it holds, and what it can reach once connected. OWASP's MCP Top 10, still in beta, is the most concrete checklist available.

Tool poisoning and instruction channels

Tool descriptions are instructions the model treats as authoritative. An attacker who controls a description, or who can inject into one through the data a server returns, can steer behaviour without touching the agent. That is MCP03 in the OWASP list, and it is covered in detail in Tool poisoning.

Token and secret exposure

MCP01 covers token mismanagement. In practice this means API keys in mcp.json files, keys in environment variables, keys committed to dotfiles repositories, and one long-lived token shared by every agent on the machine. 53% of surveyed servers relied on long-lived static secrets, which describes the default state rather than an edge case.

Supply chain

MCP04 covers the supply chain: unmaintained servers, dependency confusion, install scripts, and typosquatted package names. A server is software with the agent's authority, installed by whoever needed it that afternoon. The mcp-remote vulnerability shows how a client, not just a server, can become the entry point.

Missing authentication and authorisation

MCP07. Servers built for a demo often accept any caller, or accept a shared key with full scope. When several agents connect to the same server, the server's own log is the only record and it may not say which agent called.

Shadow servers

MCP09. A server added in a config file by one engineer is invisible to everyone else. It usually has broader access than the team would approve, because it was configured to be useful, not to be bounded.

Context over-sharing

MCP10 covers context injection and over-sharing. A server that returns a whole document body when one field was needed hands the agent data it should never hold, and that data becomes prompt content, log content and potentially exfiltration material.

In practice: Most MCP incidents start as a convenience decision: one line in a config, one key in an environment variable, one server nobody registered.

How to implement MCP safely

The protocol will not enforce any of this. The controls live in the registry, the credential path and the runtime decision.

1. Build a registry before you build a blocklist

List every server in use, who added it, its version, the credentials it needs and the tools it exposes. Then decide which ones are approved. A blocklist of known-bad servers is always behind; an approved list with a review path is not.

Tip: Ask for the server's tool list, not its README. The tool descriptions are what the model will follow.

2. Pin versions and review updates

A server update can add a tool, change a description or add a scope. Treat the version bump as a change that needs review, and keep the old version available so a rollback is trivial.

3. Broker credentials instead of storing them

Servers should receive short-lived credentials at the moment of use, scoped to the tools in play. Nothing in an agent's config file should be a durable secret, because config files get copied into dotfiles repositories and shared between machines.

Tip: Start with the servers that hold the highest-value API keys. That is usually source control, cloud control planes and ticketing, in that order.

4. Decide per call, not per server

Allowing a server is not the same as allowing every tool it exposes. Decide at the tool level, check the arguments, and deny by default for state-changing tools that no policy mentions.

5. Separate read from write

A server that reads a ticketing system and a server that closes tickets are different risks. Where a server offers both, split the capability in policy even if the server does not.

6. Watch the local ones

A stdio server has no network fingerprint. Visible process trees, config inventory and client-to-server attribution are the only ways to see it. This is the gap most gateway deployments leave open.

7. Test with hostile servers

Connect a deliberately hostile server in a lab and confirm what the agent does, what policy blocks, and what reaches the audit log. A test suite built only from well-behaved servers measures nothing.

8. Plan for removal

Every approved server needs an owner and a removal path. Old servers keep working after the project that needed them ends, with credentials that outlive the justification.

Where MCP decisions apply in the agent lifecycle

Design

Decide whether the agent needs tools at all before deciding which ones. The lethal trifecta question, private data plus untrusted content plus external communication, belongs here, because the server list is where it gets answered.

Note: A server with write access to a public system plus read access to internal data is the trifecta in one config line.

Development

Choose transports deliberately. Local stdio servers are easier to run and harder to see. Remote servers need real authentication rather than a shared key.

Pre-deployment testing

Test the tool descriptions as inputs. Confirm that a hostile description is not silently accepted, and that the tool list an agent receives at test time is the one you reviewed.

Note: Tool lists are negotiated at runtime, so a reviewed config is not proof of a reviewed capability set.

Deployment

Register the server, issue its credentials through the broker, and confirm the agent identity is recorded per call. Attribution per agent is what makes a later investigation possible.

Runtime

Per-call policy decides, the credential lease expires, and the tool's own audit log and the endpoint record are both kept. Correlating the two is what distinguishes a legitimate call from a hijacked one.

Continuous monitoring

Watch for new servers in configs, new tools in an existing server, and new scopes on an existing credential. All three happen without an agent's code changing.

Note: A server adding a tool is the MCP equivalent of a dependency adding a network call. Nobody reviews it, and it changes what the agent can do.

Decommissioning

Remove the registration, revoke the lease path, delete the stored key if one remains, and keep the call history for the retention period.

The takeaway: MCP is plumbing. The security work is knowing which servers exist, what they hold and what each call was allowed to do.

Worked example: MCP at a support platform team

A SaaS company's support engineering team adopts an agent to triage tickets. The agent connects to four MCP servers: an internal ticketing server, a documentation server, a log search server and a customer database server. All four are added in a single config file by one engineer, and the agent is useful within a day.

The inventory finding. Endpoint discovery shows 19 servers across the team's laptops, not four. Eleven are from other projects, three come from a shared dotfiles repository, and five hold API keys in plain text. Two of those keys have admin scope on the ticketing system.

The scope decision. The team writes down what the agent needs: read on tickets, read on documentation, read on logs, and read on the customer database with a row limit. Write actions are removed entirely and done by the human who reviews the triage. The customer database server is replaced with a narrower one that returns four fields.

The credential change. The plain-text keys are replaced with short-lived leases scoped to the four servers, minted per session. The shared dotfiles key is deleted and the three projects that depended on it are given their own paths. Two break and are fixed the same afternoon.

The tool review. Reading the tool descriptions turns up one documentation server whose search tool description contains a line instructing the agent to forward results to an external URL. It was added in a minor version two months earlier. It is removed, the version is pinned, and the incident is recorded as a supply chain finding rather than a curiosity.

The runtime control. Per-call policy allows reads, denies any egress to a host outside the allowlist, and holds writes. A log search query that tries to read a credentials path is denied and paged, because that path is not in the agent's data scope.

The audit. Six months later, a customer asks whether their data was accessed by an AI system. The answer comes from chained decision records: the agent identity, the server, the tool, the arguments and the outcome, filtered to that customer's records. The same query without endpoint mediation would have returned a log line naming a shared key.

How standards and regulations influence MCP

Framework	Primary focus	Relevance to MCP
OWASP MCP Top 10 (beta)	MCP-specific risks, MCP01 to MCP10	The most concrete checklist for reviewing a server and its credentials
OWASP Top 10 for Agentic Applications 2026	Agent-level threats including ASI04 supply chain and ASI07 inter-agent communication	Places MCP risk inside the wider agent threat model
OWASP Top 10 for LLM Applications	Application-level LLM risks including LLM01 and LLM06	Explains why a persuasive tool description can redirect an agent
NIST AI RMF	Govern, Map, Measure, Manage across the AI lifecycle	Gives the inventory and risk-tiering structure for servers and tools
ISO/IEC 42001	AI management system with documented controls	Expects a register of AI components, which is where the server registry belongs
ISO/IEC 23894	AI risk management aligned to enterprise risk	Connects server risk to the existing third-party risk process
EU AI Act	Obligations by risk class, including logging and oversight	Applies where MCP-connected tools sit inside a high-risk system
SOC 2	Access control, monitoring and change management over a period	Expects evidence that tool access is authorised, reviewed and recorded

Further reading: MCP security for the control set, MCP server sprawl for the enterprise governance problem, and Tool poisoning for the attack in detail.

How Alyria handles it

Alyria is the endpoint agent-governance platform for the agents your people run, and MCP is where most of an agent's effective authority now lives. Beacon, the signed daemon on every machine, inventories MCP clients and servers, records which server each client connects to and which tools each server exposes, including the local stdio servers that never touch the network.

Lyra evaluates policy on every MCP call: which server, which tool, which arguments, which data and which destination. The decision happens locally at the Beacon, so a blocked call stays blocked offline and the answer arrives before the tool runs rather than after.

Umbra removes the key from the config file. Servers receive short-lived leases injected at the moment of use, sealed to the device's hardware key, so a copied dotfiles repository no longer carries working credentials. Spectra streams signed OpenTelemetry to Alyria Cloud or to your own SIEM, and each decision chains to the previous one, which makes the record verifiable without trusting the writer.

How exposed is your setup? Compass walks through your MCP and agent setup and returns a starting risk read: compass.alyria.ai.

The platform overview explains how Beacon, Lyra and Umbra fit together.