10 MCP Security Risks and the Controls That Stop the Damage

An engineer adds a GitHub MCP server to her coding agent, pastes in a personal access token that reaches every repository she can see, and gets back to work. Six months later she changes teams. The token still works, and her agent still reads issues from public repositories that anyone on the internet can write to.

MCP security risks are the ways an AI agent's connections to tools and data through the Model Context Protocol can cause harm. They range from malicious servers and planted instructions to unowned credentials and authorized users whose agents act at machine speed. Each one ends the same way, as a tool call running on someone's access. Below you'll find ten threats mapped to the access behind them, the risk class most threat lists skip, and five numbers that size your own exposure.

Why does MCP create new security risks?

MCP creates new security risks because it gives a model that reads untrusted text a way to act with real credentials. An agent client connects to MCP servers, each server exposes tools the model can call, and each server holds a credential that decides what those calls can reach.

Nearly every MCP risk lives where those two meet. Everything the model reads, from tool descriptions to GitHub issues, support tickets, web pages, and email, can steer what it does. Each tool call it makes runs on some person's or service's access, and a steered call inherits whatever that access allows. A traditional integration runs fixed code against a fixed API, while an agent picks its tool and its input at runtime, based on text it read seconds earlier.

The protocol handles part of MCP security. As the specification defines it, model context protocol security covers how clients and servers connect and how remote servers validate the tokens they receive. Which servers you run, what they can reach, and who answers for them are left to you

10 MCP security threats mapped to the access they reach

Most published lists of MCP security risks order them by technique, which tells you how an attack works and little about how much it can hurt you. Each threat below comes with the access that turns it into an incident and the control that caps the damage.

Score each threat two ways as you read: the most privileged access an exploited call would run on in your environment, and whether the action it takes can be undone. Work the threats where both answers are worst first, whatever the technique happens to be called. The same two scores sort the MCP security issues on your own list.

Don't skip the second score. Lumos Labs expects containment and reversibility to become as important as prevention, because a read you can audit next week and a deletion with no backup are different problems. The same technique can trigger either one, so the triage has to follow the outcome.

Keep your three most-used MCP servers in mind as you go. The threats they match are where your own triage starts.

1. Tool poisoning and line jumping

Tool poisoning hides instructions in the descriptions an MCP server publishes for its tools. Many clients load those descriptions into the model's context as soon as they connect, so the instructions start shaping the agent's behavior before any tool runs. Researchers call that head start line jumping.

Access that turns it into an incident

A poisoned description can only do what the agent's access allows. An agent that can write to production, run shell commands, or read files on the engineer's machine can turn hidden instructions into changed infrastructure or stolen credentials. Limit it to read-only tools on one project, and the same instructions become a nuisance.

Control that caps the damage

Connect agents only to approved servers, and pin each one to the version you reviewed, two of the easiest MCP security best practices to put in place. Then decide each call on what it touches, so an instruction hidden in a description can't reach files, credentials, or production targets the task doesn't need.

2. Rug pulls and trojanized packages

A rug pull happens when a server you approved changes its tools or code after the review. A trojanized package is a lookalike copy of a legitimate server that ships malware from the first install. Both exploit trust granted to a name and never tied to a reviewed version.

Access that turns it into an incident

Local servers usually run on developer laptops with the engineer's own privileges, so anything the engineer's shell can read is in reach of a server that turns malicious. That includes SSH keys, cloud CLI sessions, and tokens in config files, and the damage grows with each long-lived secret on the machine.

Control that caps the damage

Tie every approval to a specific version, and treat any change to a server's tools or code as a new request. Keep long-lived secrets off developer machines. A bad update that finds only short-lived, narrowly scoped credentials has much less to steal.

3. Malicious connection flows

Some attacks land during the connection itself, before the agent sees a single tool. A malicious server can feed a client crafted OAuth discovery data or redirects, and vulnerable clients have run injected commands or sent their secrets to the wrong authorization server. These flaws live in client libraries and SDKs, so any agent built on a vulnerable version inherits them.

Access that turns it into an incident

The prize is whatever the client holds or can run, from its own secrets and authorization codes to commands on the developer's device. With command execution, one bad server can reach the tokens the client stores for other servers.

Control that caps the damage

Keep agent clients and MCP SDKs patched, since these fixes ship as library updates. Allow connections only to approved servers, so an unknown server never gets the chance to start an authorization flow.

4. Prompt injection through content

Prompt injection hides instructions in content the agent reads while doing its job, such as issues, support tickets, email, and web pages. The model can't reliably tell an attacker's text from the user's request, and anyone who can write to a source the agent reads can try it.

Access that turns it into an incident

Injection becomes a leak when one session holds three things at once: private data, untrusted content, and a way to send data out. An agent that reads a public issue tracker while holding access to private repositories and permission to post publicly has all three. Take away any one, and the injected instruction has nothing to steal or nowhere to send it.

Control that caps the damage

Scope tokens to the task, so a session reviewing one repository can't read the others. Block external writes from sessions that have read sensitive data. Any call that would send private content somewhere public should wait for a decision.

5. Static and over-scoped server credentials

Many MCP servers, especially the ones that run locally, authenticate with a personal access token or API key that someone pasted into a config file or environment variable. The person picks the scope during setup, often the broadest one so the integration works the first time. Unless someone sets an expiry, many of those tokens never expire, the same problem service account security has fought for years.

Access that turns it into an incident

A pasted token reaches whatever its creator could reach, often far more than the agent's task needs. It can survive role changes and departures, because offboarding often stops at the identity provider and doesn't reach a token pasted into a file. Anything that can read the config file, including another agent, holds that access too.

Control that caps the damage

Give every server credential a named owner, a scope that fits the task, and an expiry, the same basics AI agent lifecycle management applies to the agents themselves. Prefer credentials issued for that specific server through your identity provider, and keep secrets out of plain-text config files.

6. Confused deputy and token passthrough

A confused deputy is a server that gets tricked into using its own access for someone who shouldn't have it. Token passthrough is the related mistake of accepting a token issued for some other service and forwarding it downstream. Both break the link between the person asking and the access being used.

Access that turns it into an incident

A proxy server holding one powerful credential for a third-party API can be tricked into handing that access to an attacker who skipped the consent step. A server that passes foreign tokens along also leaves downstream logs that can't say who made the call.

Control that caps the damage

Require servers to act on the person's verified identity. Before a server uses a shared credential on someone's behalf, it should check consent for that specific client. It should also reject any token that wasn't issued for it.

7. Server-side authorization bugs

When you connect to a vendor-hosted MCP server, the vendor's code decides which customer's data each request can see. A logic flaw in that code can expose one organization's data to users at another, with nothing on your side going wrong.

Access that turns it into an incident

A hosted server holds access for many customers at once, so its bugs cross tenant lines. Whatever data your people's agents have connected to it is exposed to the flaw, whether or not your agents did anything unusual. The more you send the server, the more a single bug can reveal.

Control that caps the damage

Share the minimum data each hosted server needs, and review it like any other vendor with a live connection to your accounts. Keep your own record of which people's agents called each server, when, and with what, so you can scope exposure the day the vendor discloses a bug.

8. Shadow and local servers

An employee can add an MCP server to a coding agent on a laptop in about a minute, with no ticket and no approval. Local servers usually run as a child process of the agent client and don't open a network port. Nobody else knows they exist.

Access that turns it into an incident

An unknown server gets no review, so nobody checks what it can reach or which credentials it reads. It runs with the engineer's privileges and whatever tokens sit in the environment, and network scans and gateways won't surface it.

Control that caps the damage

Discover servers where the calls run, at the agent client on each device. Compare what you find against the approved list. Route each unknown server into the same review as any other request, and answer faster than a local install takes.

9. Calls outside MCP

Coding agents also run shell commands, edit files, and drive authenticated browser sessions, often in the same session as their MCP calls. Those built-in tools reach the same data and apps an MCP server would, so an agent blocked on one path can often take another.

Access that turns it into an incident

Shell and browser actions run on the engineer's own access, from CLI sessions and environment variables to signed-in web apps. None of that activity passes through an MCP gateway or appears in MCP logs. MCP-only controls are blind to it.

Control that caps the damage

Put one decision point in front of each tool call the agent makes, covering shell, file, and browser actions along with MCP. The same rules about targets and sensitive data then apply whichever path the agent takes.

10. Authorized damage

Some MCP incidents have no attacker behind them. An employee asks an agent for something reasonable, and the agent takes a permitted action that turns out to be consequential, at machine speed. The credential is valid and the call is allowed.

Access that turns it into an incident

The damage scales with the access the person holds, including admin and write access the task never needed. An agent can repeat a risky change across hundreds of records or settings in the time a person would make one. Standing admin roles turn a small mistake into a company-wide one.

Control that caps the damage

Right-size the human access agents borrow, starting with admin roles on production and customer-data apps, which is where AI agent access management starts. Set rules on sensitive targets that apply to every caller. Put a person in front of actions that can't be undone.

How do you measure your MCP security risk?

You measure MCP security risk with five numbers you can pull in an afternoon, each one tied to the numbered threats above. Together they turn MCP security concerns into a baseline you can report, and they’re the first evidence an AI agent identity governance program can show an auditor.

‍

The first and fourth numbers are the hardest to get by survey, since nobody can report a server they don't know they're running. Once Lumos MCP Governance is on, servers and tool usage appear as people work, approved or not. Both numbers then come from observed calls starting on the first day.

Produce all five before your next security review and put them on one page. Next quarter, the same page tells you whether the risk went down.

Four access moves that cut every MCP security risk at once

Shrinking the access behind agent calls works across the whole list at once, while patching techniques fixes one threat at a time. Four moves cover the model context protocol security risks above, and none of them depends on knowing the next technique's name.

1. Right-size the human access agents borrow, starting with admin roles on production and customer-data apps, which shrinks threats 4 and 10.
2. Give every server credential an owner, a scope that fits the task, and an expiry, which takes most of the value out of threats 2, 3, and 5.
3. Decide each call where it runs, against the person behind it and the target it touches, which covers threats 1, 8, and 9.
4. Put a person in front of any action that can't be undone.

Shrinking access only works if it doesn't create a queue, because a queue is what pushes engineers toward installing whatever works. Tekion used Lumos to cut back access sprawl while automating onboarding across more than 200 apps, and it fields more than 1,500 requests a month with 95% of tickets resolved without manual intervention. Tighter access and fast access can come from the same program.

To turn these four moves into a policy with owners, enforcement points, and evidence, use our guide to an MCP governance policy for enterprise teams. It maps each clause to the control that can see the activity it governs.

Govern the access behind every MCP tool call

Think back to the engineer at the top of this piece, whose agent still reads public issues on a token that outlived her old role. Her setup doesn't need a new attack technique to go wrong: a poisoned tool description, an instruction planted in an issue, or a well-meant bulk change would all run on that same token. The next MCP threat list will name techniques nobody has heard of yet, and each of them will still end as a tool call on somebody's access. That's the part of the problem that stays the same from one disclosure to the next, which makes it the part worth your team's time.

So start with what you can measure this week. Pull the five numbers and put them on one page, and you'll know how many servers run without approval, how many tokens have no owner, and how many admins run agents. Then spend the month on the access moves those numbers point to, starting with standing admin roles and static server tokens, and you'll have limited the damage of attacks nobody has invented yet. Agents act at machine speed on whatever access they find, so each week a stale token stays live is a week of exposure you've already measured and chosen to keep.

Lumos MCP Governance gives you that view without rerouting traffic or reconnecting a single server. A hook in supported agent clients checks each tool call before it runs, ties it to the person behind the agent, and records the server, the tool, and the verdict, including servers employees added on their own laptops. Visibility starts on the first day, so your numbers come from real calls, and the rules you write later decide each call before it reaches production. Book a demo to see what your agents can reach today.

‍