Enterprise network defenders have spent decades calibrating one core assumption: human traffic is erratic and bursty, while machine traffic is periodic and predictable. Malware maintaining persistent access phones home on a schedule, and the regularity itself becomes the signal. Tools like RITA measure the statistical consistency of connection intervals and assign a beacon score. If the score crosses 0.8, a human analyst investigates. This heuristic has caught real adversaries. It has also become so central to security operations that anything machine-generated now carries an implicit suspicion.
The Model Context Protocol (MCP) blows a hole in that assumption. MCP is the emerging standard for communication between autonomous AI agents and remote tools. It runs over Streamable HTTP, using JSON-RPC 2.0 requests on port 443. When an agent executes a reasoning loop, say, calling a tool, evaluating the result, and calling another tool, it generates a dense burst of machine-speed HTTP POST requests. The traffic is authenticated, encrypted, and high-frequency. It is also legitimate. And it looks exactly like a Cobalt Strike C2 beacon.
The protocol that makes agents indistinguishable from malware
MCP is not exotic. It is an open specification published by the Linux Foundation's Agentic AI Infrastructure Foundation, defining a client-server architecture where AI applications invoke remote tools via structured JSON-RPC envelopes. Methods like initialize, tools/list, tools/call, and prompts/get are sent as POST requests to an /mcp endpoint. A single multi-step reasoning task, such as a ReAct loop, can produce dozens of sequential requests in rapid succession. The protocol also supports Server-Sent Events (SSE) and HTTP/2 stream multiplexing, which further alter the temporal flow profile.
From a network perspective, MCP traffic is indistinguishable from a compromised internal agent exfiltrating data, or an attacker-controlled remote server receiving stolen context in the JSON-RPC request body. The traffic runs over standard HTTPS on port 443. The TLS handshake carries no known malicious signature. The inter-arrival times between requests follow a lognormal distribution driven by LLM inference latency, not a strict periodic schedule. And there is nothing in the protocol itself that tells a network sensor "this is an AI agent, not a piece of malware."
Muhammad Abdullah Sohail at the University of Calgary decided to measure whether this similarity is theoretical or practical. His paper, accepted at the first IEEE ICNP Workshop on Network Infrastructure and Protocols for AI Agents (NIPA 2026), shows that it is entirely practical. Standard enterprise IDS tools do not flag MCP traffic as anomalous. Not because they are broken, but because MCP's default behavioral signature falls outside the parameter space these tools were designed to monitor.
Building a testbed to answer four questions
The study constructs a Docker-based testbed that isolates traffic generation, proxy interception, and sensor observation into separate Linux network namespaces. The sensor stack mirrors a common enterprise deployment: Suricata v8.x running the full, unmodified Emerging Threats (ET) Open ruleset (44,236 active rules), Zeek v6.x for flow telemetry and TLS fingerprinting, and RITA v5.x for offline behavioral beacon scoring. Each monitoring container attaches directly to the target server's network namespace to ensure line-rate packet capture without host-level contamination.
Eleven mathematically defined traffic profiles span three categories. Human behavior: a Weibull-distributed browsing control (P0). Benign automation: exponential API polling (P1). Simulated C2: two periodic profiles matching Cobalt Strike defaults (P2, P3) and an aggressive interactive shell profile. MCP agent states: task-driven lognormal reasoning (P4), orchestrated multi-agent pipelining (P5), initialization bursts (P6), orchestrated plus jitter (P7), HTTP/2 multiplexing (P8), User-Agent spoofing (P9a), and large-payload database dumps (P10). Each profile runs under three TLS conditions: Opaque (direct HTTPS, sensors see only encrypted flows), TLS-Inspected (mitmproxy terminates and re-encrypts, exposing plaintext to sensors), and Cleartext (unencrypted HTTP as a baseline control). Every combination runs five times for 60 seconds each.
Four research questions drive the experiment. Can sensors see MCP traffic features under different TLS conditions? Does Suricata generate alerts on legitimate MCP traffic? Does RITA's behavioral scoring differentiate MCP from C2? And do active evasion techniques like jitter injection or User-Agent spoofing change the sensor output?
The results: zero alerts, zero detection
Across all 33 profile-condition combinations, Suricata produced zero actionable alerts for any MCP profile under both Opaque TLS and TLS-Inspected conditions. The sole exception was a low-volume match in P6 and P7 under Cleartext, averaging 0.25 alerts per run, which manual PCAP inspection traced to a missing request header in the traffic generator, not a malware detection. No C2-category or data exfiltration rule ID fired in any configuration. The ET Open ruleset has no signatures matching MCP JSON-RPC patterns.
RITA assigned a beacon score of 0.0 to every MCP profile across all TLS conditions. This includes P5 (MCP Orchestrated), the most periodic and machine-like profile. The reason is not that RITA fails to analyze the traffic, but that MCP's inter-arrival distribution structurally differs from what RITA's heuristics were built to detect. RITA computes Bowley skewness (asymmetry in the inter-arrival distribution using quartiles) and Median Absolute Deviation (dispersion of polling intervals). These metrics are calibrated for low-skewness, low-variance periodic malware. MCP's lognormal inter-arrival times, driven by inference latency, produce high skewness and high MAD. The normalization model maps these values toward 0.0 rather than 1.0. The traffic does not look like a regular beacon to RITA; it looks like noise.
The C2 profiles (P2 and P3) also scored 0.0, but for a different reason. Each 60-second run produced fewer than 12 unique source-destination records in Zeek's conn.log, below RITA's minimum connection threshold for stable quartile estimation. This is a boundary condition of RITA's statistical model, not evidence that periodic traffic is undetectable. A separate calibration run using a published Cobalt Strike packet trace produced a score of 0.85, confirming the tool works as intended for the traffic it was designed to analyze.
Why the base-rate fallacy makes this worse
The study connects these findings to the base-rate fallacy, a well-known problem in network intrusion detection. When a network carries millions of legitimate connections and the true positive rate for a detection rule is anything less than perfect, even a small false positive rate generates an overwhelming volume of alerts. Sommer and Paxson argued in their influential 2010 paper that the closed-world assumption underlying machine learning for NIDS makes anomaly detection fragile in practice. MCP traffic amplifies this problem. If IDS tools start generating alerts on MCP traffic, the sheer volume of legitimate agent connections would flood analysts with noise, causing them to suppress the alerts. If the tools do not generate alerts, as the current results show, then malicious payloads traveling over MCP go undetected.
The threat model is concrete. A compromised enterprise AI agent, manipulated through indirect prompt injection or tool poisoning, could exfiltrate proprietary data over legitimate MCP tool calls. The network traffic would be structurally identical to benign agent activity. The JA3 fingerprint from the Python httpx client (cf712d3b01ab6bfd22ca983b4748ab2f) carries zero malicious associations in the Abuse.ch SSLBL threat intelligence database. The traffic is identifiably programmatic rather than browser-originated, but it carries no established threat reputation. A network defender looking at flow logs would see standard HTTPS traffic on port 443 from a known application fingerprint, producing no alerts and triggering no investigation.
The second scenario is a malicious remote MCP server. An attacker registers a tool endpoint in a public registry. An internal agent calls it, leaking sensitive context in the JSON-RPC request body. The traffic traverses the enterprise perimeter as normal HTTPS, evading both signature-based and behavioral detection. The third scenario, traffic misclassification, is the inverse: a benign enterprise agent whose machine-paced polling is incorrectly flagged as C2, generating alert fatigue that causes defenders to suppress legitimate alarms. The current results suggest this third scenario is less likely than the first two, because the tools are not flagging MCP traffic at all.
Why TLS inspection does not help
A natural response is to deploy TLS inspection middleboxes that terminate encrypted connections and expose plaintext to sensors. The study tests this directly. Under the TLS-Inspected condition, mitmproxy terminates the TLS session, re-encrypts it, and passes cleartext to the sensor stack. Suricata can now see the full JSON-RPC payload, including method names and nested parameters. Zeek extracts flow metadata. RITA processes the connection logs.
The result is the same. Suricata produces zero alerts. RITA scores 0.0. The reason is structural. TLS inspection gives sensors access to payload content, but the content itself is not malicious. It is JSON-RPC calls to legitimate tool endpoints. The ET Open ruleset does not contain signatures for MCP patterns because MCP did not exist when the rules were written, and because legitimate MCP traffic does not contain byte sequences associated with known malware families. Even with full payload visibility, the detection gap remains.
What TLS inspection does change is the information available for future detection. Under Opaque TLS, sensors see only IP addresses, ports, and flow-level metrics. Under TLS-Inspected, sensors see HTTP headers, method names, and JSON-RPC structure. This gives defenders more data to build custom rules, but those rules do not exist yet. The gap is not in visibility; it is in the rule and heuristic layers that interpret what sensors can see.
The JA3 fingerprint also remains unchanged across TLS conditions. The Python httpx client produces the same deterministic handshake hash regardless of whether the connection is intercepted. Under TLS-Inspected, defenders can additionally observe the User-Agent header, but MCP clients do not set a distinctive User-Agent by default, and spoofing one (as tested in P9a) does not affect flow-level behavioral analysis.
Active evasion is unnecessary
One of the more striking findings is that active evasion techniques tested in the study, jitter injection (P7) and User-Agent spoofing (P9a), produced no measurable change in sensor output. This is because the baseline MCP profiles already evade detection without any evasion. Temporal smearing via jitter is irrelevant when the un-smoothed lognormal distribution already falls outside RITA's detection range. User-Agent spoofing is irrelevant when RITA operates on flow-level connection metadata, not HTTP headers.
This is the opposite of the typical adversarial evasion scenario, where attackers add jitter, rotate domains, or use domain fronting to escape detection. With MCP, an adversary does not need to evade detection because the legitimate protocol already occupies the blind spot. The traffic does not look like C2 to existing tools. It does not look like anything. It is invisible in the sense that it produces no alert, no score, and no indication of activity worth investigating.
Proposed mitigations: tell the network what you are
The paper proposes two architectural mitigations to close the visibility gap without requiring broad TLS inspection.
First, Agent-Native ALPN Standardization. ALPN (Application-Layer Protocol Negotiation) is a TLS extension where the client advertises which application protocols it supports during the handshake. HTTP/2 uses h2, HTTP/1.1 uses http/1.1. The proposal is to standardize an MCP-specific ALPN token, such as mcp/1.0 or agent/rpc, so that enterprise gateways can identify agent flows at the handshake layer. This gives network policy enforcement points a way to flag, route, or inspect MCP traffic without decrypting it. The information is already exposed in the unencrypted ClientHello; it just needs to be registered and recognized.
Second, Schema-Aware Stateful Inspection Rules. Rather than relying on generic byte-pattern signatures, defenders could deploy Suricata Lua scripts or Zeek protocol analyzers that parse the MCP JSON-RPC state machine. Such a parser would understand the sequence of initialize, tools/list, tools/call, and prompts/get methods, and could flag anomalous patterns: excessive remote execution calls, tool arguments containing shell commands or SQL queries, or payload sizes consistent with data exfiltration. This moves detection from signature matching to protocol-aware behavioral analysis.
Both proposals require coordination between MCP specification maintainers and IDS vendors. The paper suggests a formal liaison between the MCP working group and the ET Open ruleset maintainers as a practical starting point. The ALPN approach is lower friction, because it requires only a standards registration and gateway policy update. The schema-aware approach is higher effort but produces richer detection capability.
Limitations of the testbed
The study is a controlled measurement, not a production deployment. The traffic generator produces mathematically defined distributions, not real agent workloads. Real MCP traffic would include variable response sizes, concurrent tool calls, authentication handshakes, and background heartbeats that could alter the temporal profile. The testbed uses five repetitions per combination, which the author acknowledges is a small sample for estimating continuous effect sizes, though sufficient for the binary outcomes observed (scores of exactly 0.0 or consistently below 0.8).
The ET Open ruleset is one of several available. Commercial rulesets or custom signatures might behave differently. RITA is a specific version (v5.x) of one beacon-scoring tool. Other tools, such as Arkime or custom ML-based classifiers, might detect patterns that RITA misses. The study does not test these alternatives. The scope is narrow by design: measure whether two widely deployed open-source tools flag MCP traffic under realistic enterprise configurations. The answer is no.
The testbed also does not model real-world network background noise. In a production enterprise, MCP traffic would coexist with thousands of other flows, DNS queries, and application traffic. This could either improve detection (if MCP traffic stands out in context) or worsen it (if it blends into a sea of legitimate HTTPS). The controlled environment isolates MCP traffic to establish a baseline; real-world behavior requires further study.
The traffic profiles cover a range of MCP behaviors but do not exhaustively represent all possible agent architectures. Long-running agents that poll infrequently, agents that batch requests, or agents using persistent SSE connections might produce different temporal signatures. The study focuses on the most common patterns: rapid sequential tool calls during reasoning loops.
What this means for enterprise security
The practical takeaway is straightforward. If your enterprise deploys MCP-based AI agents, your current IDS configuration almost certainly does not monitor their network traffic for malicious content. This is not because your security team made a mistake. It is because the tools they use were not built for this protocol, and the protocol's default behavior does not trigger the heuristics those tools rely on.
For security teams, the immediate action is awareness. MCP traffic on port 443 is not automatically benign. It could carry exfiltrated data, unauthorized commands, or responses from malicious tool servers. The fact that it produces no IDS alerts does not mean it is safe. It means the sensors are not looking at it in a way that would reveal problems.
For MCP implementers, the paper is a call to build security into the protocol rather than bolting it on afterward. The ALPN standardization proposal is a concrete, low-friction step that would give network defenders visibility without requiring them to break encryption. Schema-aware inspection rules are a longer-term investment but would enable detection of genuinely malicious payloads within MCP traffic, not just traffic that happens to be machine-generated.
For the broader security community, this paper is a case study in what happens when a new application protocol arrives faster than the monitoring ecosystem can adapt. MCP is being deployed in enterprise environments now. The detection gap is real today. Waiting for the IDS vendors to catch up is not a strategy.
Read the paper on arXiv