Security Risk Assessment Process for MCP Deployments

By early 2026, researchers had already catalogued close to 7,000 MCP servers sitting exposed on the open internet. Of those, 492 — identified by Data Science Dojo — had no real authentication or encryption at all, meaning anyone who stumbled across one could probably just walk in. That's the gap this piece is about, and I want to walk you through a layer-by-layer check that matches how MCP actually works under the hood, so your agents aren't running in production on good intentions and crossed fingers.

How fast the MCP attack surface has grown and what that pace signals for assessment urgency

Start with the numbers, because they tell the story better than I can. Between January and February 2026, researchers filed more than 30 CVEs against MCP servers, clients, and the tooling around them. Shell injections made up 43% of that total. One of them, CVE-2025-6514, scored a 9.6 on the CVSS scale and hit a single npm package with over 437,000 downloads. One bad dependency, and the whole enterprise ecosystem downstream of it was exposed before most companies had even run a first assessment.

Early malicious MCP packages demonstrated how long a compromise can sit undetected inside systems with real access to sensitive resources.

Put these together and a pattern shows up: the window between "we deployed an MCP server" and "someone found the hole in it" keeps shrinking. Waiting until after deployment to check for problems used to be a shortcut you could get away with. Now it's a bet you'll usually lose. Assessment before production is the one point in this whole lifecycle where you actually have the upper hand.

One more thing worth flagging: the NSA's guidance from May 2026 is formal U.S. government guidance aimed squarely at MCP, and it says plainly that adoption has outrun the safeguards meant to support it. With other protocols, formal government guidance has tended to flow quickly into vendor questionnaires and security reviews. Worth acting on now, not later.

The frameworks and taxonomies that a structured MCP risk assessment should draw on

No single document covers this whole surface. The gaps become apparent quickly when you try to map one framework's categories onto findings it was never built to describe. Build your assessment on just one framework and you'll have holes you don't even know about yet.

Start with the OWASP MCP Top 10, released in beta in 2025. It's the first framework built specifically for MCP, following on from OWASP's earlier Top 10 for LLM Applications (2023) and Top 10 for Agentic Applications (2025). It lists ten categories, MCP01:2025 through MCP10:2025: token mismanagement, privilege escalation, tool poisoning, supply chain attacks, command injection, weak authentication, poor telemetry, shadow servers, context over-sharing. Use it as your checklist, plain and simple.

Then there's the MCP-38 threat taxonomy, published on arXiv in 2026 (arXiv:2603.18063), which breaks the space into 38 distinct threat types. This one matters less for the list itself and more for the shared language it gives you. Two engineers describing the same finding should mean the same thing when they say it, and right now, without a shared vocabulary, they often don't.

For mapping findings to controls, the Cloud Security Alliance's AI Controls Matrix, from July 2025, lays out 243 control objectives across 18 domains. It doesn't favor any one vendor, which matters if your environment is mixed, and it fits onto whatever compliance structure your team already runs.

The NSA's May 2026 guidance gives you a floor, naming three headline risks: uncontrolled automated actions, missing input screening, and susceptibility to overload attacks. Treat it as the minimum bar every deployment has to clear, not the ceiling.

Four sources, four jobs. OWASP tells you what to look for. MCP-38 gives you a common vocabulary. CSA tells you what controls to apply. NSA sets the floor. Skip one and you're assessing with a blind spot.

Assessing the transport layer: authentication, encryption, and exposure mapping

Transport is where the client and server talk, and it's the first place to look, because it's the first place an attacker looks too.

Start with an inventory: every server, cloud-hosted, local, buried inside a CI/CD pipeline, plus the ones individual teams spun up on their own to move faster without asking anyone first. OWASP calls these shadow servers. A server that isn't in your central registry is an identity your security team can't account for, and the identities nobody's watching are exactly the ones that get hit.

Check authentication on each endpoint, one by one, since MCP doesn't require authentication by default. Sit with that for a second: the absence of an auth check is the starting condition, unless someone builds one in on purpose. Look for API keys or OAuth enforcement, confirm nothing sits open unauthenticated, and check token scope and lifetime while you're at it. A documented class of vulnerabilities here involves MCP servers acting on a user's behalf without checking authorization first, opening the door to privilege escalation through OAuth token confusion.

Confirm encryption runs end to end with TLS, and flag any path where traffic still moves in plaintext.

Then map the exposure perimeter: which servers face the open internet, which stay internal, which are localhost only. Apply controls in proportion to that exposure. Internet-facing servers get the strictest treatment, no delays, no deferrals.

What you end up with is a registry: every endpoint, its auth status, its encryption status, its exposure class. Everything downstream depends on that list being right. A gateway that enforces policy centrally cuts down on the odds of a developer misconfiguring something on their own, and that particular failure shows up constantly across real deployments.

Assessing the protocol layer: injection paths, tool registration integrity, and session token handling

This is where things stop looking like traditional API security. Traditional models assume static, predictable, human-triggered requests. MCP agents decide things on their own, pull in context that shifts under them, and chain tools together in sequences nobody scripted ahead of time. The protocol layer is where that decision-making runs into input nobody's checked.

Injection comes first. Agents build and run system commands, shell scripts, API calls, and code using input that might come from a user prompt, retrieved context, or some third-party source, and that input rarely gets checked before it runs. Local MCP servers often have access to files, dev tools, environment variables, package managers, and cloud CLIs, so when injection lands, it doesn't land small. That 43% shell-injection figure from earlier isn't an abstraction; it's what happens when nobody traced the path. Every tool invocation needs tracing, from where its input comes from to where it gets executed, with a note on where sanitization happens and where it doesn't.

Tool poisoning shows up in a few forms. A Tool Poisoning Attack hides malicious instructions inside a tool's description at registration; the agent reads that description as trustworthy and carries out the attacker's steps like they're routine. A rug-pull is the same trick, just delayed: the operator changes the tool's description or behavior after approval, and MCP has no built-in way to flag that change, so the agent keeps trusting something that's no longer what it approved. Researchers have demonstrated exactly this pattern, where an agent keeps trusting an approved configuration even after the behavior behind it has been swapped out entirely.

There's also tool shadowing, where one malicious server's description warps how the agent treats tools from other, legitimate servers, slipping past whatever per-tool review you thought you had in place. Palo Alto's Unit 42 found that in a setup with five connected MCP servers, a single compromised one pushed attack success up to 78.3%. Risk in a multi-server environment compounds. It doesn't just add up.

Catching this means reviewing tool descriptions at registration for hidden instructions, setting up a hash or version check to catch changes after approval, and logging every pull of a tool description, no exceptions.

Session token exposure is the third piece. Hard-coded API keys, tokens that never expire, secrets sitting in model memory or protocol logs: all of it is retrievable through prompt injection, a compromised context window, or a leftover debug trace somebody forgot to strip out. CVE-2025-6514, the 9.6 mentioned earlier, worked by intercepting OAuth tokens through a malicious authorization endpoint before the session even finished establishing. Audit where tokens live, force short-lived rotation, confirm each token carries only the permissions it needs, and check that no secrets show up in logs or context windows.

That leaves you with an injection risk map by tool, a baseline for what a tool's description should look like, and a token handling audit. All three carry straight into the data layer.

Assessing the data layer: access scope, context boundaries, and what agents are actually permitted to touch

This layer covers tools, resources, and prompts, and it decides how bad things get if the first two layers fail. Think of it as the blast radius.

Map data access scope for every agent and every tool first. What can each agent read, write, invoke? Flag anything with access wider than the job calls for. Context over-sharing gets its own named risk in the OWASP MCP Top 10 for good reason: an agent holding more context than it needs is an agent with more surface for something to leak out of.

Check role-based access control next. RBAC for an AI agent is confirmation that what the agent's allowed to do reflects a decision somebody actually made, not a default that got inherited during setup and never looked at again. Ask whether current permissions were set on purpose, and write down who owns that decision for each grant. Privilege escalation, another named OWASP risk, happens when an agent ends up with more access than what was originally reviewed and signed off on. Trace every tool invocation path for a quiet route by which an agent could pick up permissions past its assigned role.

Cross-tenant isolation matters too. Documented cross-tenant data exposure incidents show what happens when this layer isn't locked down: one agent's context bleeds straight into another tenant's resources. Confirm the boundaries actually hold between agent sessions, between tenants, and between chained tool calls.

Check observability last. What real record exists of what an agent touched? Weak telemetry is a named OWASP risk because most teams, right now, today, have no live view of what their agents are doing. An audit log you read after something's already gone wrong only documents the incident; it doesn't stop it. Visibility only counts as a control if it's live, covering every tool call, not a summary you read once the session's over.

What you're left with is a data access matrix per agent, a record confirming RBAC was set on purpose, and a map of logging coverage. That's the evidence that your agents work inside boundaries somebody actually chose to draw.

Supply chain risk as a cross-layer threat that the layer-by-layer assessment must also address separately

Supply chain risk doesn't care about the layers we just walked through. It cuts across all of them, and it happens before any layer-specific control gets a chance to do its job. One compromised package can poison a tool description, steal a token, and widen data access, all from a single bad install.

Watch for typosquatting and fake package updates sneaking malicious code into MCP server dependencies. Watch for configuration poisoning, where insecure defaults or a tampered config file undercut security before the server ever goes live. And watch for package squatting: documented cases exist of packages that looked legitimate enough to get installed before anybody checked closely. With supply chain attacks, how long it takes someone to notice usually matters more than the initial compromise itself. With supply chain attacks, how long it takes someone to notice usually matters more than the initial compromise itself.

Verify where every MCP server package actually comes from: the registry, the maintainer's identity, the version history. Make sure no server is quietly pulling dependencies from an unverified community registry without review. Keep a registry of approved servers with pinned versions, and treat anything outside it as unverified until somebody checks it by hand. Watch for post-approval updates that change behavior without triggering a second look.

The Cloud Security Alliance's research traces how a supply chain compromise chains straight into tool poisoning and then credential theft. That's exactly why this needs to run alongside the layer assessments from day one, not get bolted on afterward. Lab testing across more than 45 real-world MCP servers found attack success rates above 60%, with the best-performing model hitting 72.8%. A lot of that surface traces back to weak supply chain hygiene, not bugs in the runtime itself.

Turning assessment findings into a pre-production control gate and ongoing governance posture

Everything from the three layers, plus the supply chain check, feeds into one checklist before anything reaches production: transport registry complete, authentication verified, tool descriptions baselined, RBAC set on purpose and documented, logging coverage confirmed, package provenance checked.

That gate has to be binary. A half-finished checklist reflects an ungoverned deployment, whatever label gets put on it afterward.

Once something's live, the work isn't over. Re-run tool description checks every time a connected MCP server pushes an update, since rug-pull attacks live specifically in the gap between initial approval and whatever comes after it. Keep logging live too: every tool call, every piece of data touched, every token used, recorded as it happens, not batched up for later. A report you read at the end of a session tells you what already broke. Watching while it happens is the only way to catch something before it spreads.