{"id":68,"date":"2026-09-17T08:43:38","date_gmt":"2026-09-17T08:43:38","guid":{"rendered":"https:\/\/www.0xprathamesh.com\/blog\/?p=68"},"modified":"2026-09-21T06:03:34","modified_gmt":"2026-09-21T06:03:34","slug":"agent-traffic-looks-like-c2-beacon-detection-gap","status":"publish","type":"post","link":"https:\/\/www.0xprathamesh.com\/blog\/agent-traffic-looks-like-c2-beacon-detection-gap\/","title":{"rendered":"Your Agent Looks Like Cobalt Strike: The Detection Gap in Agent Traffic"},"content":{"rendered":"

A paper submitted yesterday measured what enterprise detection does with legitimate agent traffic, and the answer is nothing.<\/strong> Model Context Protocol tool calls structurally and temporally resemble command-and-control beaconing, and across eleven traffic profiles and three TLS conditions, Suricata content matching and RITA behavioural scoring returned a consistent 0.0 beacon score and near-zero alerts.<\/p>\n

Answer first:<\/strong> this is not a failure of the detectors. It is the inversion of an assumption the whole detection discipline is built on. Machine-like cadence has been an Indicator of Compromise for as long as analysts have been writing rules. Legitimate agents are machine-like cadence, and they are authenticated, and they are supposed to be there. When hostile and legitimate behaviour measure the same, no rule can separate them, and the control has to move somewhere else.<\/p>\n

What was actually measured<\/h2>\n

The paper is When Agents Look Like Beacons: NIDS Evasion by Model Context Protocol Traffic<\/em>, submitted on 16 September 2026 and accepted at the first IEEE ICNP workshop on network infrastructure and protocols for AI agents. It is six pages, and the method is worth stating precisely because the conclusion depends on it.<\/p>\n

    \n
  • A controlled Docker testbed simulating eleven mathematically defined traffic profiles<\/strong>, so the cadence of each is a parameter rather than an accident.<\/li>\n
  • Three TLS conditions<\/strong>: opaque, TLS-inspected, and cleartext. This matters because it separates what content inspection can see from what flow analysis can see.<\/li>\n
  • Suricata<\/strong> for signature matching under the Emerging Threats Open ruleset, and RITA<\/strong> for behavioural beacon scoring. These are the two things an enterprise actually deploys for this problem, one content-based and one behavioural.<\/li>\n
  • Jitter applied as temporal smearing, to test whether the obvious evasion countermeasure changes the outcome.<\/li>\n<\/ul>\n

    The result: MCP traffic evaded detection in every configuration<\/strong>, with a consistent 0.0 behavioural beacon score and near-zero content alerts. Jitter did not change it. TLS inspection did not change it.<\/p>\n

    There is a detail in there that I think is the most useful sentence in the paper, and it is easy to read past. Opaque TLS obscures the HTTP content, which is the thing content rules need. But opaque TLS exposes<\/em> the traffic to flow-level temporal analysis, which is the thing behavioural scoring needs. So the encryption posture does not hide the agent. What defeats the behavioural scorer is that its heuristics are tuned for malware, and the inter-arrival distribution of a generative model’s reasoning loop is lognormal<\/strong> rather than periodic. A reasoning loop and a jittered beacon are both irregular, and the scorer is looking for the thing that makes them distinguishable.<\/p>\n

    \n\"A
    The two patterns, and the columns that were supposed to separate them.<\/figcaption><\/figure>\n

    Why the signal inverted<\/h2>\n

    Detection engineering rests on a simple asymmetry. Normal human activity is irregular in a particular way, and automation is regular in a particular way, and the second one is worth alerting on because in most networks the only sustained automation was the adversary’s.<\/p>\n

    That last clause is where the assumption lives, and it has quietly stopped being true. An enterprise now runs sustained automation on purpose: agents polling tool servers, assistants calling APIs, workflows waking on schedules. Every property that made the automation signal useful is now a property of the estate’s legitimate traffic.<\/p>\n

    The paper’s framing is that this traffic arrives authenticated<\/em>, which is the part that makes it genuinely hard rather than merely noisy. A beacon from a compromised host is usually a violation of something. A tool call from an approved agent is a violation of nothing. It is the system working, at machine speed, over the same protocol family a threat actor would use, with a timing signature that is irregular for a legitimate reason nobody’s heuristic models.<\/p>\n

    The trilemma nobody wants to choose from<\/h2>\n

    Once the signal has inverted, a defender has three options and each one is bad in a different way.<\/p>\n

    Alert on the pattern.<\/strong> Machine-like cadence fires for every agent in the estate, continuously. The queue fills with the estate’s own traffic, analysts start triaging by source, and the genuine beacon is one row among thousands that look identical. This is alert fatigue with a specific cause, and it is how detection programmes get switched off.<\/p>\n

    Whitelist the pattern.<\/strong> Suppress the class to stop the noise, and a real implant using the same cadence now operates inside the blind spot built for the agents. This is the option teams actually take, because it is the one that makes the queue manageable, and it is the one that converts a noisy control into no control at all.<\/p>\n

    Separate the two.<\/strong> Find the feature that distinguishes an assistant from an implant. The measurement is that the usual candidates, interval regularity, destination reputation, payload shape, authentication state and volume, hold the same value in both rows. The one column that looked promising, timing distribution, is irregular in both cases for different reasons.<\/p>\n

    \n\"The
    The three options, and where the control has to go instead.<\/figcaption><\/figure>\n

    The pivot: from detection to inventory<\/h2>\n

    I want to state the general principle before applying it, because it is the part that outlasts this paper.<\/p>\n

    When hostile behaviour and legitimate behaviour are indistinguishable at the telemetry layer, no detection rule can carry the load.<\/strong> A rule has to decide between two things, and if they present identically the rule has nothing to decide on. Adding sensitivity does not help, because sensitivity only moves the error from false negatives to false positives. The control has to move to a layer where the distinction exists, and in this case it does exist, just not in the traffic.<\/p>\n

    Three properties survive, and none of them requires telling an agent from an implant.<\/p>\n

    Inventory.<\/strong> Enumerate the agents that exist and the endpoints each may reach. This is not a heuristic, so it cannot be defeated by looking like something else. An unlisted process making tool calls is the finding, regardless of whether its traffic is regular, irregular, encrypted, or inspected. The measurement in the paper is an argument for treating agent egress as a known-good baseline you maintain, rather than as a pattern you search for.<\/p>\n

    Attribution.<\/strong> Record which principal each connection belongs to and which agent it came from, at the network layer. This is the property the traffic genuinely lacks, which is why the paper’s proposal is a declaration rather than a signature. A conversation traceable to a person and an agent can be reviewed after the fact. A conversation traceable only to a cadence cannot be reviewed at all, which means an incident review has nothing to work with even when the incident is found.<\/p>\n

    Pinned egress.<\/strong> Allow each agent the destinations it needs and refuse the rest. This is the only one of the three that stops the attack rather than detecting it, and it works precisely because it does not depend on distinguishing the traffic. A beacon cannot hide inside a traffic class it is not permitted to use in the first place. If the agent’s allow-list is four endpoints, an implant riding the agent’s cadence still only reaches four endpoints.<\/p>\n

    What the paper proposes instead<\/h2>\n

    Their recommendation is a network indication standard for agents, and the shape is worth understanding because it is the same move as the three above: make the signal declarative.<\/p>\n

    Two parts. An Agent-Native ALPN<\/strong>, so the protocol announces itself during the TLS handshake and a defender does not have to infer from behaviour that this connection is an agent at all. And standardised out-of-band headers<\/strong> carrying agent identity and purpose, so the attribution question is answered by the protocol rather than reconstructed from telemetry.<\/p>\n

    The reason this is the right shape and not a hopeful one: if defenders must infer<\/em> agent identity from measurements, they are inferring it from measurements that an attacker can also satisfy. Declaring it moves the cost of deception from mimicking statistics to lying in a field that can be verified against an inventory. That is a much better place to put the burden.<\/p>\n

    What does not follow<\/h2>\n

    Being careful about scope, because this result is easy to overread.<\/p>\n

    It is a six-page workshop paper, and the authors state that their finding is within their testbed scope: eleven synthetic profiles, one IDS, one behavioural scorer, one ruleset. “Suricata with ET Open did not catch this” is a measured statement. “No detection can catch this” is not in the paper and is not true, since a deployment with a curated ruleset, flow metadata and an agent inventory is already doing several of the things recommended here.<\/p>\n

    It is also not an argument that MCP is a bad protocol, or that agents should not be deployed. The traffic is described as resembling C2 because both are machine-paced polling over TLS, which is a description of the measurement and not an accusation.<\/p>\n

    And it is not an argument that defenders should stop writing detection content. Detection still catches the cases where something is<\/em> a violation: the wrong credential, the unexpected destination, the agent calling an endpoint nobody allows. The finding is narrower and more uncomfortable than that. It says the specific class of signal called machine-like cadence has stopped being an indicator, and anyone whose rules rest on it is now measuring their own infrastructure.<\/p>\n

    What still works: baselines that belong to one agent<\/h2>\n

    There is a version of detection that survives this, and it is worth separating from the version that does not.<\/p>\n

    A global heuristic asks whether a flow looks like a beacon, using a population baseline and a malware-shaped template. That is the control the paper measured, and it cannot work here because the population now contains both kinds of traffic and they match on every column the template checks.<\/p>\n

    A per-agent baseline asks a different question: does this<\/em> agent, which I have named and whose normal I have recorded, deviate from its own history. That control is available only if the inventory exists, and this is the connection worth making explicit. The inventory is not just a compliance artefact. It is the precondition that makes a detection rule possible at all in a class where population-level detection has stopped working.<\/p>\n

    Three signals become usable once you have that baseline, and none of them requires distinguishing an assistant from an implant in the abstract.<\/p>\n

      \n
    • First-seen destinations.<\/strong> The agent has talked to eleven endpoints for six months. A twelfth appears. That is a finding, and it does not matter whether the twelfth looks like a beacon, because the observation is about change rather than about shape.<\/li>\n
    • Volume and cadence relative to that agent’s own normal.<\/strong> A reasoning assistant’s call rate tracks the work it is given. A rate that tracks nothing, or that holds steady through hours in which no work is being requested, is the deviation. The comparison is against the agent, not against the estate.<\/li>\n
    • Credential and identity drift.<\/strong> The agent connects with a different principal, a different user agent string, or from a host it has never run on. These are cheap to record and immune to the mimicry problem, because mimicking a destination list is a much higher bar than mimicking a timing distribution.<\/li>\n<\/ul>\n

      The operational consequence is that this shifts work from the detection engineering queue to the asset inventory, which is a worse place to be organisationally and a better one technically. Nobody enjoys maintaining an inventory. But an inventory is a control that does not decay when the estate adopts new automation, and the detection rule resting on a cadence template decays a little further every time another agent is deployed.<\/p>\n

      How to test this in your own estate<\/h2>\n

      You do not need a testbed. You need a week of flow data and three questions.<\/p>\n

      First, find out whether your detectors are seeing agent traffic at all.<\/strong> Take the last seven days of flows to your tool servers and your model endpoints, and check how many generated a signature alert or a behavioural score above zero. If the answer is none, the paper’s measurement holds in your environment, and the question becomes what your rules are actually doing.<\/p>\n

      Second, ask what would happen if the traffic were hostile.<\/strong> This is the uncomfortable one, and it is the reason to run it. Pick a single agent, and ask what in your detection stack would fire if that exact flow were a beacon rather than an assistant. If the answer is nothing, you have measured your own coverage with respect to this class, and no amount of tuning changes it, because the class is not distinguishable.<\/p>\n

      Third, count the agents you cannot name.<\/strong> For each destination your estate talks to over tool-calling protocols, can you say which agent made the call and which person authorised it? Every destination where the answer is a shrug is a place where detection is your only control and detection has been shown not to work. That column, and not the alert count, is the output of this exercise.<\/p>\n

      Evidence to look for in your own stack<\/h2>\n\n\n\n\n\n\n\n\n
      Question<\/th>\nWhat to look at<\/th>\nWhy it matters<\/th>\n<\/tr>\n<\/thead>\n
      Do our detections fire on agent traffic?<\/td>\nSignature alerts and behavioural scores for flows to tool servers and model endpoints over the last week<\/td>\nZero alerts on a class you know is present means the rule set does not model the class, not that the class is absent<\/td>\n<\/tr>\n
      Can we distinguish an assistant from an implant?<\/td>\nThe candidate features: interval regularity, destination reputation, payload shape, authentication state, volume<\/td>\nThe paper’s finding is that these hold the same value in both cases, so any rule resting on them is measuring the estate’s noise floor<\/td>\n<\/tr>\n
      Do we have an agent inventory?<\/td>\nA list of agents with the endpoints each is permitted to reach, and an owner for each<\/td>\nThis is the control that does not depend on telling the two apart, and it is the one most estates cannot produce<\/td>\n<\/tr>\n
      Can we attribute a connection to a person?<\/td>\nNetwork-layer records linking each agent connection to a principal and an agent identity<\/td>\nWithout it an incident review cannot say who or what acted, which makes the finding unreportable even when it is found<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Frequently asked questions<\/h2>\n

      What does the paper actually claim?<\/h3>\n

      That Model Context Protocol tool traffic structurally and temporally resembles command-and-control beaconing, and that within a controlled testbed of eleven traffic profiles and three TLS conditions, Suricata signature matching under the Emerging Threats Open ruleset and RITA behavioural beacon scoring did not flag it. The authors report a consistent 0.0 behavioural beacon score and near-zero content alerts, and they are explicit that the result is scoped to their configuration.<\/p>\n

      Why does TLS inspection not solve this?<\/h3>\n

      Because the problem is not hidden content. With opaque TLS the content is unavailable to signature matching, but the flow timing becomes available to behavioural analysis, and the timing is where the overlap lives. Decrypting the traffic gives the content rules something to read, and the paper’s finding is that the content does not contain a violation: the calls are authenticated and the protocol is being used as designed.<\/p>\n

      Does this mean MCP is insecure?<\/h3>\n

      No, and it is worth separating the two claims. This is a visibility finding about how agent traffic appears to network monitoring, not a vulnerability in the protocol. The traffic resembles C2 because both are machine-paced authenticated polling over TLS, which is a description of the measurement rather than a defect. A protocol cannot be criticised for looking like the thing it structurally is.<\/p>\n

      What should be done instead of tuning the rules?<\/h3>\n

      Move the control to layers where the distinction exists. Maintain an inventory of agents and the endpoints each may reach, so an unlisted agent is a finding regardless of how its traffic looks. Record attribution at the network layer so a connection can be traced to a person and an agent. And pin egress so a beacon riding the agent’s cadence still only reaches the destinations the agent was allowed.<\/p>\n

      What is an Agent-Native ALPN?<\/h3>\n

      It is the paper’s proposal for a transport-level indication that a connection belongs to an agent, announced during the TLS handshake rather than inferred from behaviour. Paired with standardised out-of-band headers carrying agent identity and purpose, it lets a defender read an agent’s identity from the protocol instead of guessing it from traffic statistics. The principle is that a declared signal can be verified against an inventory, while an inferred one can only be mimicked.<\/p>\n

      Does this apply if we do not run MCP?<\/h3>\n

      The specific measurement is about MCP, but the mechanism generalises to any sustained, authenticated, machine-paced polling from approved software. That includes scheduled jobs calling partner APIs, synchronisation daemons, and any orchestration that runs on an interval. If your detection content treats machine-like cadence as suspicious, you already have the false-positive problem this paper measures, with or without agents.<\/p>\n

      Why this one matters more than the usual advisory<\/h2>\n

      Most of what I write about here is a control that was absent, skipped, or resolved against the wrong source. All three are fixable by changing code. This one is different in kind: the control is present, correctly written, properly tuned, and structurally incapable of the job, because the signal it depends on has been made legitimate by the estate’s own adoption.<\/p>\n

      That is a harder conversation than a patch, and it is the one worth having. The uncomfortable version of the finding is that adoption made the indicator useless, so the cost of deploying agents includes a cost to the detection programme, and that cost is paid whether or not anyone accounts for it. Teams that write it down find the trade manageable. Teams that discover it during an incident find it is not.<\/p>\n

      Companions that sit alongside this piece: the three ways the MCP and agent-tooling surface fails<\/a>, and where an agent’s authority actually comes from<\/a>.<\/p>\n

      Primary sources<\/h2>\n
        \n
      • When Agents Look Like Beacons: NIDS Evasion by Model Context Protocol Traffic (arXiv 2609.19091, 2026-09-16)<\/a><\/li>\n
      • MITRE ATT&CK TA0011: Command and Control<\/a><\/li>\n
      • MITRE ATT&CK DET0444: Detection of Command and Control Over Application Layer Protocols<\/a><\/li>\n
      • Cloudflare One: identifying inspected MCP traffic and controlling direct connections<\/a><\/li>\n
      • Cloud Security Alliance: Agentic C2, AI Agents as Command-and-Control Infrastructure (2026-04-17)<\/a><\/li>\n
      • ATR-2026-00010: malicious content in MCP tool responses<\/a><\/li>\n<\/ul>\n

        <\/p>\n

        One next action<\/h2>\n

        If you run an agent that executes tools, AgentCrash<\/a> is an open-source harness that crash-tests it in a synthetic workplace: synthetic tools, visual evidence and regression tests. It is built for exactly this problem, turning a containment claim into something you can run against the system instead of arguing about it in review.<\/p>\n