Network-Level Detection of Unsanctioned MCP Clients

Security teams can find unauthorized MCP servers running on their networks by watching for four specific traffic patterns: capability-negotiation handshakes at session start, OAuth flows (or their telling absence), tool-call sequences that invoke shell or file-access functions, and data egress to destinations outside the normal baseline. These signals are visible at the network layer regardless of whether an engineer installed the client with IT's blessing or not. Detection doesn't have to wait for an inventory to catch up to reality. The rest of this piece lays out what those signals look like, where they fall short, and how to turn them into actual enforcement rather than another alert queue nobody reads.

Why MCP traffic differs from ordinary HTTPS

MCP clients produce a recognizable sequence of protocol behaviors, and ordinary browser sessions or REST API calls just don't generate it. That sequence is what lets you detect at the network level, even before you ask whether a client authenticated properly.

Part of what makes this traffic distinct is structural. In a conventional client-server setup, the client asks and the server answers. NSA/DoD guidance published June 2026 points out that MCP often flips this: servers query and execute actions for the clients connected to them, not the other way around. That reversal produces traffic patterns that no legacy proxy was built to classify, because proxies were designed around the assumption that clients pull and servers serve. MCP breaks that assumption at the protocol level.

The messaging structure itself adds another layer of distinctiveness. Sessions open with structured capability negotiation, then move into tool-call sequences, and role-tagged message content runs through all of it. Even when all of this rides over HTTPS and looks encrypted and ordinary from a distance, the shape of the exchange, the timing, the sequence of handshake-then-calls, stands apart from how a browser or a typical API client behaves. This matters because MCP has stopped being a niche integration pattern. NSA/DoD guidance from June 2026 names AutoGen Studio, Harvey AI, Agentverse, and Copilot as production examples already running in business, finance, legal, and software-development environments. The traffic is already crossing enterprise networks at volume. The opportunity to catch unsanctioned use at the network layer is already live, not theoretical.

Why unsanctioned MCP clients evade endpoint controls

MCP clients are easy to stand up, and that ease means they proliferate without security teams ever learning they exist. Security teams typically know about only a small fraction of the MCP servers actually running on their networks, because nothing about spinning up a new client requires asking permission first.

Part of the problem traces back to the protocol's own design. The original spec shipped with no mandatory authentication built in, and the MCP security best-practices document published July 2026 still leaves it to individual operators to implement auth on their own. That means a client can connect to a server and start calling tools without ever presenting a credential, and nothing in the protocol itself stops it.

Endpoint tools can't close this gap on their own. Local stdio-transport servers stay silent on the network until the moment a model call fires, and by then the tool call has already run on the machine. Any detection approach that waits for a packet to cross a monitored boundary arrives after the fact. The same blindness occurs with coding agents, because they call provider APIs directly using private keys, and with desktop apps, because their traffic looks, from the outside, like any other HTTPS session. Domain-classification tools built for browser-based chat traffic don't know what to do with either case, because neither one presents the signatures those tools were trained to flag.

Network signals that detect MCP clients

MCP clients generate at least four categories of signal in network traffic, and each one is detectable on its own. Taken together, they are specific enough to fingerprint unsanctioned usage with high confidence, well before anyone has to reason about intent.

The first is the capability-negotiation handshake. When a session opens, the client asks the server what tools it offers, and the server answers with structured metadata: names, descriptions, parameter schemas. SentinelOne's MCP security guide describes inspecting this exact phase at the gateway level, where policy rules check what a server is requesting and block it if the permissions look excessive, before a single tool call happens. This handshake has no real analogue in ordinary REST or GraphQL traffic. Its shape alone makes it a reliable classifier for MCP sessions.

The second signal lives in authentication. When auth is present, MCP clients run OAuth 2.0 flows with redirect patterns, state parameters, and token exchanges, all described in the MCP security best-practices document. The confused-deputy attack, where a malicious client harvests an authorization code by slipping a forged redirect URI into an active consent session, appears in network monitoring as an anomalous OAuth callback sequence. Just as telling is when the OAuth flow never happens. A client that reaches tool-call activity without any preceding authentication exchange is either badly configured or running without sanction.

The third signal comes from the tool calls themselves. Each invocation carries a role, message content, and a tool identifier, and the sequence and pace of these calls says a lot. When calls to shell-execution or file-access tools arrive in rapid succession, that looks nothing like a sanctioned workflow. NSA/DoD guidance flags arbitrary code execution, covering CWE-77, CWE-78, CWE-94, and CWE-95, as a high-severity MCP risk category, and shell-invoking tool calls are the network-visible step right before those outcomes land. Servers that quietly redefine their tools mid-session, after the initial handshake, trigger a second capability exchange partway through, a pattern known as a rug pull, and that mid-session renegotiation is itself an unexpected event worth catching.

The fourth signal is egress. MCP servers pull together credentials and data from multiple enterprise services and hand them back in tool responses, so a bulk payload heading to an unfamiliar external destination is a real exfiltration indicator. Because MCP traffic volume across enterprise networks has grown so fast, baselines for normal egress are only now becoming possible to establish. Any deviation above that baseline toward a new destination carries real weight as a signal.

Platforms that sit at the MCP gateway layer, Runlayer among them, inspect these exchanges as they happen, and they classify client behavior right at the handshake and capability-negotiation stage. That turns MCP's structural distinctiveness into an actual control point before any tool ever executes, not a pattern someone notices in a log three days later.

The limits of network inspection

Network inspection sees what crosses a monitored boundary. It has two real blind spots, and naming them is what keeps the rest of this argument honest.

The first gap is local execution. Stdio-transport MCP servers generate no inspectable traffic until the model call fires, and by the time anything crosses a proxy, the tool has already run on the endpoint. No amount of network visibility recovers that missed window.

The second gap is semantic. Prompt injection and tool-poisoning payloads are syntactically valid MCP messages, so network inspection alone can't tell a poisoned tool description from a legitimate one, and you have to read the actual content for meaning. SentinelOne's security guide makes this point directly: traditional perimeter security fails against MCP attacks that operate at the level of natural language, and catching those requires behavioral analysis and context-aware controls that go beyond packet inspection. Supply-chain attacks sharpen this problem further. The February 2026 fake Oura MCP package delivered a malicious server, and once you installed it, it behaved exactly like a sanctioned client from the network's point of view. The traffic looked like any legitimate connection, until behavioral anomalies gave it away.

Network signals form one detection layer among several. They catch unsanctioned clients that endpoint tools miss, but they don't replace endpoint controls, authentication enforcement, or behavioral analysis of content. All four need to work together.

How real attacks have produced detectable network artifacts

Looking across documented MCP incidents turns up a consistent pattern: the network artifact appeared right alongside the damage, and in several cases, a gateway or proxy positioned in the right place would have caught it before the fact.

CVE-2026-33032 hit nginx-ui in March and April 2026, with a CVSS score of 9.8. The MCP breach timeline for this incident shows that the message endpoint accepted command-execution requests with no authentication challenge. Any proxy logging traffic to that endpoint would have seen tool calls arriving with no OAuth exchange preceding them, which is precisely the absence-of-auth signal described above.

Azure DevOps MCP, disclosed in April 2026 with a CVSS score of 9.1, involved Microsoft's @azure-devops/mcp package exposing work items, repositories, pipeline configurations, API keys, and authentication tokens, all without requiring credentials. Unauthenticated tool-call sequences hitting an endpoint handling that volume of sensitive data are exactly the kind of network-observable anomaly the handshake and auth signals are built to catch.

June 2026 brought an agentjacking incident through Sentry MCP, where an attacker embedded shell commands inside fabricated Sentry error events, forged using a public DSN credential, that agents then executed automatically. Those agents then made outbound connections that reached unexpected destinations after processing the poisoned content, which appears in network monitoring as a detectable egress anomaly, the same category of signal described in the fourth section above.

The SmartLoader campaign, running through the fake Oura MCP package in February 2026, delivered StealC malware that harvested credentials and browser passwords from infected machines. The bulk credential exfiltration to an external command-and-control destination that followed is almost a textbook case of the egress-volume signal network monitoring is built to catch.

Coverage and gaps in current detection tooling and guidance

The tooling available for network-level MCP detection is still young, but you can map it out clearly enough. Each approach covers a defined slice of the problem and hands off to something else at its edges.

Qualys TotalAI runs a three-tier approach: external probing at the network perimeter for characteristic headers and structured capability responses, host-level inspection for servers reachable internally, and runtime indicators that confirm MCP usage even when there's no network exposure to see. It covers remote servers well, but it has less visibility into deployments running entirely locally.

Microsoft's Defender and Intune combination, under the Agent 365 banner that went generally available May 1, 2026, includes Shadow AI Discovery, which sweeps for unmanaged local agents across more than 35 agent types, local and remote MCP servers included. That coverage stops at local stdio servers, since those generate no network traffic for Defender to see.

Bifrost Edge takes a different approach entirely: it reads MCP configuration files for supported applications, including Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor, and builds a fleet-wide inventory of what's configured. This is configuration inventory, not live traffic inspection, so it tells you what's set up to run, not necessarily what's running right now or what it's doing.

Proofpoint's gateway routes all MCP traffic through a central proxy that enforces OAuth 2.0 authentication, controls which tools each user or agent can access, and inspects content for sensitive data or policy violations before requests ever reach the server. Among the named options here, it's the most complete real-time enforcement model, bounded by one requirement: the traffic has to actually pass through the gateway to be seen.

That gateway-position requirement is the throughline across all of these tools. SentinelOne's security guide frames centralized gateway architecture as the mechanism that keeps unauthorized MCP servers away from enterprise resources no matter how individual developers configure their local setups. Where the gateway sits, and whether traffic is forced through it, determines how much of this detection stack actually functions.

The shadow-MCP discovery gap, where security teams see only a fraction of what's actually running, is the problem an enterprise AI control plane is built to close. If you unify inventory and governance across all MCP usage, sanctioned and unsanctioned alike, the unauthorized deployments become visible before they turn into a detection emergency.

The July 2026 MCP spec revision's authentication changes

The July 2026 MCP specification revision introduces formal enterprise-managed authorization, so client identity now is a first-class part of the protocol, not something bolted on by individual operators. That gives network inspection a far more reliable anchor point than it had before.

Under the updated specification, published July 2026 as revision 2026-07-28, client credentials are now bound to the authorization server that issued them, and a client has to re-register if that issuing server ever changes. A client showing up with credentials from a different issuer than expected is now a structurally detectable anomaly, not just a suspicious pattern someone has to notice by hand.

The Microsoft Security blog, writing in June 2026, described the architectural shift this way: the latest release candidate makes requests carry what they need so a gateway can inspect and enforce on every single call, rather than trust a hidden session that nothing downstream can verify. That's the change that makes per-call network inspection workable at real scale, instead of something that only works for a handful of flagship integrations.

Enterprise-Managed Authorization, known as EMA, went stable in June 2026 and was formally placed into the extensions framework by the July 2026 spec. Organizations that adopt it can bind tool-call permissions directly to corporate identity. Unauthenticated or mis-authenticated calls become structurally distinguishable at the network layer rather than something a human analyst has to infer from behavior.

The Microsoft Security blog also cautioned that the spec gets revised on a regular cadence, and treating "we reviewed MCP last year" as settled is already out of date. Detection logic that depends on authentication signals has to get revisited with each spec release, because the signals themselves keep shifting as the protocol matures.

Building a governance layer around network detection to produce enforcement, not just visibility

Network detection without a governance layer produces alerts and nothing more. The signals described throughout this piece only become real control when they're tied to identity on every call, checked against an approved inventory, and logged in a record that can't be altered after the fact and will hold up to regulatory audit.

Approved-inventory enforcement turns detection into policy automatically. The NSA/DoD differential-scan approach produces a list of known servers, and any server that's not on that list but still produces MCP-characteristic traffic is by definition unauthorized. Once the inventory exists, the detection signal converts directly into a decision instead of sitting in a queue waiting for a human to judge it.

Identity binding at the call level builds on the July 2026 spec change. Pairing that per-call inspection with SSO and SCIM-provisioned identities means every single tool call can carry a traceable human or agent identity behind it. The access pattern becomes something that can be audited, not just something that was technically visible.

Just-in-time credential issuance addresses the long-lived-token problem directly. Rather than letting MCP servers hold onto long-lived OAuth tokens, the exact credential-sprawl failure mode documented across the Azure DevOps breach and others like it, a governance layer can issue short-lived, scoped credentials per session instead. That limits how much damage any single compromised session can do.

Regulatory alignment ties the technical work to compliance obligations that are already in force. NSA/DoD guidance and EU AI Act requirements, covering logging and cybersecurity obligations, both apply from August 2, 2026, and both require logging of AI agent actions. Tamper-proof audit logs tied to MCP tool calls satisfy both requirements at once, so you don't need to build two separate logging systems.

Runlayer is built as this kind of governance layer: a single platform combining access to a large catalog of MCP servers and OAuth credential handling with SSO and SCIM identity binding, just-in-time credential issuance, real-time detection for tool poisoning and intent drift, and audit logs traced through a standard observability framework that resist tampering. Real-time network-layer detection of anomalous OAuth flows, tool-call sequences, and data-egress patterns can catch confused-deputy attacks and exfiltration attempts as they happen, and pairing that visibility with enforcement at the gateway, where unauthorized tool calls get blocked outright, turns detection into prevention rather than a postmortem exercise.

Security teams that own the MCP gateway end up being the teams that make company-wide AI adoption possible, rather than the ones slowing it down. The same infrastructure that enforces policy is what gives employees a sanctioned path to use agents productively, with no need to go around security to get their work done.