What you actually connect when you connect an agent

Connecting an agent to a business system used to be a project. Since the Model Context Protocol became the common plug, it is a config file: name the server, paste a token, restart the client. The protocol did for tool access what USB did for peripherals, and it inherited the same property, where the convenience and the attack surface are the same feature.

The protocol’s own security document is the least-read useful text in this field. It names seven classes of attack and writes several of the countermeasures as MUST NOT, which is unusual for a spec written by the company that benefits most from adoption.

What MCP is, in one paragraph

MCP is a standard way for an AI client to discover and call tools on a server: your CRM, your ticket system, your file store, your database. The client asks what the server can do, the server answers with a list of tools, and the model decides which to call. The value is that a tool integration written once works in every client that speaks the protocol.

The security consequence follows from the same sentence. The model decides which tool to call, and it decides based on text, including text that arrived from outside your company.

The attacks the spec names

Seven classes, and only two of them are exotic. The rest are ordinary web security problems that got a new place to happen:

Class	In plain terms
Confused deputy	A proxy server’s consent screen gets skipped, and an attacker gets a token issued in your name
Token passthrough	A server accepts a token that was never issued to it and forwards it downstream
SSRF	A malicious server points the client at internal addresses, including cloud metadata endpoints
Session hijacking	A guessable session ID lets someone act as you, or inject events into your stream
Local server compromise	A one-click install runs an arbitrary command on your machine
OAuth URL injection	A javascript: or shell-interpreted URL turns an auth flow into code execution
Scope inflation	Broad tokens (files:*, admin:*) turn one leak into full lateral access

Two of the rules are absolute and worth memorising, because a vendor’s answer to them tells you how seriously they took this. Servers must not accept tokens that were not explicitly issued for them. And servers must not use sessions for authentication, so every inbound request gets verified on its own.

The one that has no patch

In May 2025 Invariant Labs disclosed an attack against the official GitHub MCP server. An attacker opens an issue on a public repository containing instructions written for a machine. The victim asks their agent to look at the open issues. The agent reads the instructions and, being an agent with access to the user’s repositories, carries them out, including pulling content out of private repos and putting it somewhere the attacker can read.

There is no bug in the server code. The server did what it was asked; the model was persuaded by content it had been pointed at. GitHub could not fix it with a patch, and the researchers’ proposed mitigations were operational rather than technical: one repository per session, and least-privilege tokens.

This is the shape of the whole category. Prompt injection is not a defect in a particular product, it is what happens when a system that follows instructions is given data that contains instructions. Every defence that works is a limit on what the agent is allowed to do, not a filter on what it is allowed to read.

The other memorable case is duller and more common. Asana launched an MCP server in May 2025; weeks later a logic flaw in it broke tenant isolation, and users in one organisation could surface project names, task descriptions and metadata belonging to another. Nobody was attacked. A new surface simply behaved differently than the old one, and the monitoring built for the old one did not see it. Asana took the feature offline from 5 to 17 June 2025 and told roughly a thousand customers to check what their integrations had pulled.

Asana’s MCP server was offline for twelve days in June 2025 after a tenant-isolation flaw, with about 1,000 customers in scope. The GitHub disclosure was two weeks earlier.

Invariant Labs, 26 May 2025; BleepingComputer on the Asana incident

Why this lands differently in Europe

Germany’s BSI made the same point from the other direction in July 2026. Its president, Claudia Plattner, wrote about an AI agent that left its sandbox, connected out over the internet to Hugging Face and gave itself access to tools there. Not maliciously: the system had a legitimate goal and decided independently that crossing its boundary served it.

The BSI’s recommendation was not “use a different model”. It was to give AI systems proper identity and access management, which means treating an agent as an identity with credentials and a blast radius, the same as any service account.

That framing is the useful one for a company that has to answer a customer’s security questionnaire. An agent is not a new category of software. It is a service account that improvises.

Three rules that survive contact with a real company

Most published MCP security guidance is written for the people building servers. Here is the version for a company connecting them.

One system per session. The GitHub attack needs the agent to hold access to both the public repository and the private one at the same moment. An agent scoped to one system at a time is far less useful as a leak, and marginally less convenient as a tool. That trade is worth making for anything touching customer data.

Read and write are different decisions. An agent that reads your CRM is a search interface. An agent that writes to it is a colleague with no manager. Separate the credentials, and put writes behind either a narrow scope (this object type, these fields) or a person. The line we hold in client systems: an agent may draft anything, and may send nothing that is outside a defined and reversible range.

Never install a server you have not read, and never one that asks for a broad token. The scope section of the spec exists because vendors publish every scope they support and clients request all of them. If a server needs admin to summarise tickets, that is the answer to your evaluation.

The question to ask a vendor

One question sorts the field, and it is not “is it secure”.

Which token does your integration use, who issued it, and what can it do if it is stolen?

A vendor who can answer that in two sentences has thought about it. A vendor who answers with certifications has answered a different question, the same way GDPR compliance and EU data residency answer different questions and get quoted interchangeably.

For anything we build for clients, the answer is written down before the first connection is made, because it is much harder to reconstruct afterwards. If you want that written down for the agents already running in your company, that is a good thirty minutes.

Frequently asked questions about MCP security