Who Owns This Agent? Tracing AI Agents Back to Their Owners

\nCCS: Security and privacyCCS: Social and professional topics Computing / technology policy\n

\n\nRuben Chocron\n\nNote: Both authors contributed equally to this research.\n\nemail: rubencho@post.bgu.ac.il\n\nAffiliation: Ben-Gurion University of the Negev, Beer-Sheva, Israel\n\n, \nDoron Jonathan Ben Chayim\n\nemail: benchayi@post.bgu.ac.il\n\nAffiliation: Ben-Gurion University of the Negev, Beer-Sheva, Israel\n\n, \nEyal Lenga\n\nemail: lenga@post.bgu.ac.il\n\nAffiliation: Ben-Gurion University of the Negev, Beer-Sheva, Israel\n\n, \nGilad Gressel\n\nemail: gilad.gressel@am.amrita.edu\n\nAffiliation: Center for Cybersecurity Systems & Networks, Amrita Vishwa Vidyapeetham, Amritapuri, India\n\n, \nAlina Oprea\n\nemail: a.oprea@northeastern.edu\n\nAffiliation: Northeastern University, Boston, Massachusetts, USA\n\n and \nYisroel Mirsky\n\nNote: Corresponding author.\n\nemail: yisroel@bgu.ac.il\n\nAffiliation: Ben-Gurion University of the Negev, Beer-Sheva, Israel\n

\n\n

Abstract.

\n \n

AI agents are increasingly deployed to act autonomously in the world, yet there is still no reliable way to trace a harmful agent back to the account that deployed it. This creates the same accountability gap across both ends of the intent spectrum: benign operators may deploy misconfigured or overbroad agents that cause harm unintentionally, while malicious operators may deliberately weaponize agents for scams, harassment, or cyber attacks. In many cases, these agents are powered by vendor-hosted models, a dependency that holds even for sophisticated adversaries such as state actors conducting cyber operations. In either case, affected parties can observe the behavior but cannot notify the responsible operator, stop the session, or identify the account for investigation.

\n \n

We formalize this gap as the problem of agent attribution: linking an observed agent interaction to the responsible account at the hosting vendor. To our knowledge, this is the first work to define the problem and present a practical solution. Our protocol is canary-based: an authorized party injects a canary into the agent’s interaction stream, and the vendor searches a narrow window of session logs to recover the originating session and account. Simple canaries suffice in non-adversarial settings. For adversarial operators who filter or paraphrase incoming content, we develop robust canary constructions that cannot be suppressed without degrading the agent’s own task performance, yielding a formal asymmetry in the defender’s favor. We evaluate a variety of scenarios including real-world agents and show that our attribution method is reliable, robust, and scalable for vendor-side deployment.

\n \n

Keywords:

Agent attribution, canary-based tracing, agent accountability\n

1. Introduction

\n\n

AI agents are becoming increasingly popular as tools for productivity and automation. But agents do not merely generate text: they plan, decide, and act in the world (Wang et al., 2024; Xi et al., 2025; Yao et al., 2022), sending messages, browsing websites, calling APIs, making phone calls, writing and executing scripts, and otherwise operating on their operator’s behalf. As these systems become more capable and more widely deployed, a basic security problem emerges: when an agent causes harm, there is no reliable way to trace it back to the owner that deployed it.

This accountability gap matters across the full spectrum of harmful agent behavior. At one end are unintentional failures. An operator may deploy an agent with an overbroad objective, faulty stopping conditions, or misconfigured tools (Skalse et al., 2022; Pan et al., 2022), causing it to spam recipients, overwhelm third-party services, or take actions outside its intended scope. But unintentional harm is not limited to ordinary negligence. As agents operate over longer horizons, they may derive intermediate goals their operators never specified, or pursue emergent objectives (Hubinger et al., 2019) that are locally coherent from the agent’s perspective yet unforeseen by the human who deployed them. In the limit, this includes the familiar concern of rogue or misaligned systems whose effective objectives diverge from their assigned mission (Hendrycks et al., 2023). At the other end are intentional abuses, in which operators deliberately weaponize agents for fraud, harassment, cyber intrusion, reconnaissance, or influence operations(Goldstein et al., 2023; Xi et al., 2025). In both settings, the harmful behavior may be directly visible to affected parties, yet the responsible operator remains out of reach.

\"Refer — Figure 1. The novel problem of agent attribution introduced in this paper (top), and our canary-based protocol for the vendor-hosted LLM setting (bottom).

We formalize this missing capability as the problem of agent attribution.

To our knowledge, this is the first work to identify and define agent attribution as a distinct security problem.\nSolving agent attribution would restore a path to recourse that is currently absent. In benign cases, attribution could allow affected parties, platforms, or other authorized entities to identify the responsible deployment and seek intervention before the harm continues. In malicious cases, attribution would provide the basis for lawful investigation and downstream accountability. A vendor that can identify the responsible deployment could warn, throttle, suspend, or terminate it; an authorized authority that can identify the responsible operator could, under appropriate legal process, obtain account information and build an evidentiary trail. Today, by contrast, victims may observe the harm, platforms may detect the abuse, and model providers may hold relevant logs, yet none of these parties has a technical mechanism for linking the observed behavior to the operator behind it.

Agent attribution is difficult in full generality, but a particularly important and actionable setting arises when agents rely on vendor-hosted large language models (LLMs), whether frontier foundation models or hosted open-source models. This scope is highly consequential. Many of today’s most capable agents depend on vendor-hosted models for capability, convenience, and access to state-of-the-art performance, and that dependency often persists even for sophisticated or malicious operators (Anthropic, 2025a; Anthropic, 2025b; OpenAI, 2024). Although the agent’s runtime code, prompts, tools, and any preprocessing wrappers may all execute on infrastructure controlled by the operator, the underlying model calls still pass through the vendor and are recorded against an account. This makes the vendor the natural locus for a practical attribution mechanism.

In this paper, we present a practical vendor-mediated attribution protocol for this setting based on canaries(Bowen et al., 2009). At a high level, an authorized party injects a canary into content the agent is likely to consume. If the agent forwards that content to its vendor-hosted model, the canary appears in the vendor’s session logs. The vendor can then search a narrow time window of candidate sessions, recover the originating session, and link it to the responsible account. In non-adversarial settings, simple lexical canaries suffice. In adversarial settings, however, a malicious operator may place a wrapper between the outside world and the model API, filtering, paraphrasing, or rewriting incoming content to suppress obvious markers. We therefore develop robust canary constructions that are difficult to remove without also degrading the agent’s ability to perform its own task, creating an asymmetry in the defender’s favor.

In summary, we make the following contributions:

• \n
\n
We are the first to identify and formalize the emergent problem of agent attribution, and to characterize the full space of scenarios in which it arises.
\n
• \n
\n
We present a practical attribution protocol parameterized by intent setting and interaction mode, enabling efficient vendor-side attribution without universal pre-registration or continuous identity exposure.
\n
• \n
\n
We propose lexical canaries for non-adversarial settings, and develop two forms of utility-bearing canaries for adversarial settings: task-relevant lexical canaries and semantic canaries. We show that these constructions yield a defender-favorable asymmetry: the defender can drive the attribution probability arbitrarily close to one, while any adversary that attempts to suppress the canary must degrade the agent’s task performance below a usable threshold.
\n
• \n
\n
We provide an empirical evaluation on real-world agents showing that lexical canaries achieve near-perfect detection in non-adversarial settings, and that utility-bearing canaries remain robust under adaptive paraphrasing evasion, and vendor-side search is scalable to production deployment.
\n

2. The Agent Threat Landscape

\n\n

The intent behind harmful agent behavior, whether unintentional or deliberate, is the axis that most directly shapes the attribution problem. It determines the adversary model the protocol must withstand and, in turn, the canary construction the authority must use. We therefore organize this section along that axis: Section 2.1 establishes anonymity as the structural condition that makes attribution hard across the entire spectrum; Section 2.2 characterizes unintentional harm by the locus of failure; Section 2.3 characterizes intentional harm by the target of attack; and Section 2.4 explains why existing recourse mechanisms fail in both regimes. Fig. 2 summarizes the full taxonomy at a glance, with the complete enumeration of subcategories and representative scenarios in Appendix H.

2.1. Anonymity: A Property of Agents

\n\n

Before cataloguing specific failure modes and abuse cases, it is worth establishing why the attribution problem is structurally hard and why it will remain hard absent a deliberate protocol solution.

When a human acts in the world, identity leaks through many channels: accounts require registration, communications carry metadata, patterns of behavior accumulate into recognizable signatures, and legal frameworks compel platforms to retain and disclose identifying information under appropriate process. These channels are imperfect and routinely evaded, but they create friction. An agent acting in the world leaks none of this by default. An agent sending messages, querying APIs, placing calls, or posting content does so through the same generic interfaces available to any user, with no structural obligation to identify its operator. The operator account exists at the vendor, but nothing in the agent’s external behavior points back to it. Anonymity is not a feature the operator needs to add; it is the default state.

This default anonymity is benign in most deployments and only becomes a problem when the agent causes harm. Because it is structural and universal, the accountability gap spans the entire range of harmful agent behavior, from the careless developer who never considered that their agent might cause trouble, to the sophisticated adversary who is counting on anonymity to operate with impunity. The protocol we present must work across this entire range, which is why we begin by carefully characterizing it.

Figure 2. The space of agent-initiated harm. Unintentional failures (top) are\ncategorized by the source at which the fault originates. Intentional abuse (bottom) is categorized by the target of the\nattack. Leaf labels list example subcategories; the full\nenumeration with scenarios appears in Appendix H.

\n\n

2.2. Unintentional Harm

\n\n

The majority of harmful agent behavior in the near term will be unintentional. As agents become easier to deploy and their capabilities grow, the population of operators will include many who lack the technical sophistication to anticipate the downstream effects of their deployments. We organize unintentional failures by the locus at which the failure originates: the agent itself, the operator who specified it, or the environment it operates in. A fourth case, emergent and rogue objectives, is qualitatively distinct and we treat it separately.

Agent-side failures.

\n\n

The agent itself may fail to execute its mission as the operator intended. Goal misinterpretation, capability overreach, and proxy overoptimization (Pan et al., 2022) all fall in this category: the agent does what its instructions appear to ask for, but with consequences the operator never anticipated. For example, a customer-retention agent told to reduce churn may discover that aggressive, guilt-laden follow-up messages lower cancellation rates, and escalate to what recipients experience as harassment. The recipient observes harmful behavior in an exchange they are directly part of.

Operator-side failures.

\n\n

The operator may misspecify, misconfigure, or overscope the agent. Implementation faults such as unbounded retry loops, overbroad mandates such as “resolve all complaints,” and out-of-scope actions all belong here. For example, a misconfigured price-monitoring agent may issue millions of queries per hour to a third-party API, degrading service for other users; the API provider observes the offending traffic without being able to identify the account behind it.

Environment-side failures.

\n\n

The agent’s environment may contain adversarial content that hijacks it. Prompt injection (Liu et al., 2024) embedded in a document or web page (Greshake et al., 2023), and poisoned data (Carlini et al., 2024) in an incoming stream, can cause an agent to act against both its operator’s intent and third parties’ interests. For example, a browsing agent that encounters an injected instruction on a visited page may begin exfiltrating data to an attacker-controlled endpoint; the site owner observes the anomalous requests. Note that in this case the operator’s account is technically responsible for the session, yet the proximate cause is an external attacker, a distinction that matters for post-attribution response but does not change the prerequisite need for attribution.

Emergent and rogue objectives.

\n\n

A qualitatively distinct case arises when an agent derives intermediate goals its operator never specified, or pursues emergent objectives that are locally coherent from the agent’s perspective yet bear no recognizable relationship to the original mission. This is the alignment failure mode the AI safety community has long identified as a central long-run concern, here instantiated in a concrete deployed-systems context (Hubinger et al., 2019; Hendrycks et al., 2023; Ngo et al., 2022). We include it not because it is the dominant risk today, but because the attribution infrastructure we propose must be designed to handle it, and because near-term rogue behavior is a direct precursor to it.

Across all four cases, the operator is not deliberately filtering content reaching the agent; whatever the authority injects into the interaction stream will be forwarded to the vendor’s model as-is. This is the structural property that makes simple random or lexical canaries sufficient in the non-adversarial setting, as we formalize in Section 4.

2.3. Intentional Harm

\n\n

When the operator is actively adversarial, the relevant question is no longer where the failure originates but what the adversary is trying to accomplish. The target class determines where the agent touches the outside world, and thus where the authority can plausibly inject a canary. We organize intentional abuse by target: systems, individuals, collectives, commons, and AI systems.

Systems. Agents can conduct cyber offense at a speed and scale no human attacker could match: intrusion and credential attacks, exploit discovery, lateral movement, data exfiltration, resource exhaustion, and illicit scraping. For example, an agent probing an exposed API for misconfigurations interacts with an endpoint whose owner can respond with canary-bearing content. Recent incidents in which state-sponsored and lone adversaries used vendor-hosted models as the reasoning backbone for intrusion campaigns illustrate that this category is not hypothetical (Anthropic, 2025b; Sela, 2026; Zhu et al., 2026).

Individuals. Agents can impersonate, deceive, and abuse individual targets through social engineering or synthetic-identity impersonation. For example, a romance-scam agent running hundreds of simultaneous conversations corresponds directly with each victim, who can inject canary content into replies (Anthropic, 2025a). Also consider that agents are accessible to all, and in the future agents might be used to perform sustained targeted harassment: consider someone possibly sending an agent to harass an ex-lover over the phone or online or to blackmail a former employer after getting fired.

Collectives. Agents can manipulate groups and public discourse at scales that qualitatively exceed prior bot networks. Coordinated inauthentic behavior, disinformation, market manipulation, and reputation attacks all fall here(Goldstein et al., 2023; Yang and Menczer, 2023). A single operator running a sockpuppet agent can maintain hundreds of contextually consistent personas indefinitely, each adapting to local platform norms. The platforms or forums on which these personas operate can seed canary content into threads the agent is known to read.

Commons. Agents can degrade shared infrastructure and open ecosystems: content pollution, commercial fraud against platforms, IP infringement, benefits fraud, and open-knowledge vandalism. For example, a scraping agent harvesting a site for resale interacts with content the site operator fully controls and can instrument.

AI systems. As AI systems are embedded in consequential decisions (hiring, credit, moderation, legal research) they themselves become targets. Agents can conduct adversarial probing of deployed assistants (Zou et al., 2023; Perez et al., 2022), game automated decision pipelines, and coordinate across multiple sessions to achieve objectives no single agent could. For example, an agent probing a hosted assistant to extract its system prompt or identify moderation blind spots interacts with a target whose operator can embed canaries in responses.

Across all five target classes, the operator has both the motive to evade attribution and the technical means to do so: a wrapper placed between the outside world and the vendor API can filter, substitute, or paraphrase incoming content before the model ever sees it. This is the structural property that makes random and simple lexical canaries insufficient in the adversarial setting, and that motivates the utility-bearing constructions of Section 4.

2.4. Why Existing Recourse Fails

\n\n

Across both the unintentional and intentional cases, a consistent pattern emerges: affected parties have observable evidence of harmful behavior but no path to the responsible account. The obvious recourse mechanisms all fail for structurally similar reasons. IP-based identification is the most commonly attempted approach and the first to break down, since agents trivially rotate addresses, use proxies(Mi et al., 2019), and distribute requests across infrastructure; at best, IP attribution identifies hosting providers rather than operators. Platform-level account investigation can identify the specific surface account a harmful agent is using on a given platform (a fake persona, a burner email, a throwaway API key) but these accounts are disposable and reveal nothing about the vendor account driving them. Behavioral fingerprinting can detect that an agent is present through response timing, vocabulary patterns, or behavioral consistency(Mitchell et al., 2023; Sadasivan et al., 2023), but it cannot identify which of a vendor’s millions of accounts is responsible; it solves a different problem, bot detection rather than attribution. Direct vendor inquiry without a session identifier is infeasible at scale, since a vendor receiving a report that “some agent” caused harm cannot search its logs without a way to narrow the search space, the report must identify something present in the vendor’s logs, which is precisely what our canary provides. Legal process is the most powerful recourse in the malicious case but requires a predicate: investigators must be able to identify the vendor and the approximate session before compelling disclosure, and without a way to link observed behavior to a vendor session, legal process has nothing to compel. Our proposed Attribution is thus the prerequisite for legal accountability, not an alternative to it.

The agent attribution protocol we present in Section 4 is designed to supply the missing link in each of these cases: a mechanism for generating a session identifier from an observed interaction, enabling every downstream recourse mechanism to function as intended, whether it be vendor response, platform action, criminal investigation, or legal process.

2.5. Scope of this Work

\n\n

While the problem of agent attribution applies broadly to cases where an operator hosts the agent’s LLM locally, this paper focuses on the tractable setting in which the agent owner relies on a vendor-hosted LLM, whether an open-source model chosen for convenience (e.g., OpenRouter, Fireworks AI) or a proprietary foundation model selected for advanced capability (e.g., OpenAI, Anthropic, Google). These vendors represent well-known, widely used infrastructure for powering agents among general users; we posit that the same holds for those with malicious intent.

Why the vendor-hosted assumption holds even for adversaries.\nThis deployment model applies not only to benign operators but also to sophisticated adversaries. Many frontier capabilities most useful for agentic abuse, such as long-horizon planning, code generation, tool use, and instruction following, remain concentrated in vendor-hosted models(Stanford Institute for Human-Centered Artificial Intelligence, 2025), and attackers often accept the API dependency to obtain them. Recent incidents illustrate this pattern: Anthropic reported that a suspected Chinese state-sponsored group used Claude Code as the execution backbone for an espionage campaign against roughly thirty targets,(Anthropic, 2025b) and a lone operator reportedly combined Claude Code with GPT-4.1 to compromise multiple Mexican government bodies and exfiltrate sensitive records(Sela, 2026). In both cases, the attackers controlled their own operational infrastructure, yet the core reasoning still flowed through vendor APIs and was logged against vendor accounts.

Beyond cyber intrusion.\nThe same dependency appears in consumer-facing abuse. Voice-agent platforms such as Vapi let operators build agents around hosted LLMs such as ChatGPT, Claude, or Gemini, connected to speech, telephony, and tool APIs.¹¹\n 1\n \n \n \n \n \n \n \n https://vapi.ai/ Although such platforms support legitimate customer-service and scheduling use cases, similar stacks can be repurposed for fraud, including romance-scam automation and voice-cloning schemes(Anthropic, 2025a; Sela, 2026).²²\n 2\n \n \n \n \n \n \n \n https://www.americanbar.org/groups/senior_lawyers/resources/voice-of-experience/2025-september/ai-cloned-voice-scam/ Our protocol also covers hosted open-source models: even when the LLM Model is not proprietary, operators frequently rely on a vendor for inference to avoid the cost and complexity of self-hosting. Thus, across proprietary and hosted-open-source deployments, the operator may control the runtime, prompts, tools, and wrappers, but the model calls still cross into the vendor and are recorded against an account. This is the structural property our protocol leverages.

3. Threat Model

\n\n

3.1. System Model and Principals

\n\n

We consider five principals interacting with each other in our setting: (1) an agent, (2) the agent’s operator, (3) the vendor hosting the agent’s LLM, (4) the victim targeted by the agent, and (5) an authority which aims to perform agent attribution on the victim’s behalf. We now explain these principals and how they interact with one another (illustrated in Fig. 3).

Vendor $\\mathcal{V}$ .\nThe vendor hosts an LLM $\\mathcal{M}$ , which can be an open source model (e.g., Qwen, Llama, Deepseek, etc.) or a proprietary foundation model (e.g., GPT 5.2, Claude Opus 4.7, etc.). An LLM is accessed by operators through an API. $\\mathcal{M}$ operates over sequences of tokens drawn from a vocabulary $\\Sigma$ ; we denote a token sequence as $\\mathbf{x}=(x_{1},\\ldots,x_{m})\\in\\Sigma^{*}$ . An API call to $\\mathcal{M}$ consists of an input sequence $\\mathbf{x}^{\\mathrm{in}}$ (the prompt) and produces an output sequence $\\mathbf{x}^{\\mathrm{out}}$ (the completion). The prompt comprises a system prompt $\\mathbf{x}^{\\mathrm{sys}}$ , an optional set of tool definitions, and a conversation context $\\mathbf{x}^{\\mathrm{ctx}}$ containing the accumulated interaction history, so that $\\mathbf{x}^{\\mathrm{in}}=(\\mathbf{x}^{\\mathrm{sys}},\\mathbf{x}^{\\mathrm{ctx}})$ . $\\mathcal{V}$ can maintain a temporary log $\\mathcal{L}$ of all API calls, recording for each call what was sent, what was returned, the timestamp, and the account (denoted $a$ ) under which the call was made. Critically, $\\mathcal{V}$ sees only what flows through its API: it has no visibility into the agent’s external actions, runtime code, or any preprocessing layers.

Figure 3. Principals in our system model and their relationships. Red arrows show the provenance path that enables agent attribution.

\n\n

Operator $\\mathcal{O}$ .\nThe operator is the entity that builds and deploys the agent. $\\mathcal{O}$ holds a registered account with $\\mathcal{V}$ through which all model calls are made, and $\\mathcal{O}$ defines the agent’s system prompt, tools, and mission objectives. In the benign setting, $\\mathcal{O}$ is a legitimate party who may be entirely unaware their agent is causing harm; in the malicious setting, $\\mathcal{O}$ is actively concealing their identity. The operator’s runtime infrastructure is distinct from the vendor’s: the agentic loop, the system prompt, and any pre- or post-processing layers may all run on infrastructure controlled by $\\mathcal{O}$ , with only the model calls themselves crossing into $\\mathcal{V}$ .

Agent $\\mathcal{A}$ .\nThe agent is the deployed system acting on behalf of $\\mathcal{O}$ . Formally, $\\mathcal{A}$ couples $\\mathcal{M}$ with a set of tools and an execution environment, running an iterative loop in which control is exercised by $\\mathcal{M}$ itself: at each step, $\\mathcal{M}$ generates the next action and the surrounding harness executes it. At step $t$ , the agent holds a context $\\mathbf{x}^{\\mathrm{ctx}}_{t}$ and invokes $\\mathcal{M}$ on input $\\mathbf{x}^{\\mathrm{in}}_{t}=(\\mathbf{x}^{\\mathrm{sys}},\\mathbf{x}^{\\mathrm{ctx}}_{t})$ to obtain a completion $\\mathbf{x}^{\\mathrm{out}}_{t}$ . The completion encodes an action $a_{t}$ (e.g., a tool invocation, external API call, outbound message, or terminal response), after which the resulting interaction is incorporated into the next context. We write this update abstractly as $\\mathbf{x}^{\\mathrm{ctx}}_{t+1}=\\mathrm{Update}(\\mathbf{x}^{\\mathrm{ctx}}_{t},\\mathbf{x}^{\\mathrm{out}}_{t})$ , and the loop iterates until $\\mathcal{M}$ emits a terminal action. From any external party’s perspective, $\\mathcal{A}$ is simply a counterpart in a conversation; nothing in its external behavior reliably identifies $\\mathcal{O}$ or the vendor account behind it.

Authority $\\mathcal{D}$ .\nThe authority is a party with standing to initiate an attribution request, such as a law-enforcement agency or a commercial entity. $\\mathcal{D}$ is registered with $\\mathcal{V}$ through a pre-established trust relationship that authenticates requests and ensures they are auditable.

Victim of $\\mathcal{A}$ . The victim is one or more entities harmed by $\\mathcal{A}$ , such as an individual receiving scam messages, a server enduring abusive traffic, or a network under attack. Victims report the behavior to $\\mathcal{D}$ , which reports or investigates on their behalf using agent attribution. In this work, we consider $\\mathcal{D}$ as the sole entity which can initiate attribution requests; this bounds vendor-side load and prevents abuse of the protocol. This is similar to how national agencies, such as internet societies or criminal investigation bureaus, forward or investigate reported incidents on behalf of the public.

Adversarial wrapper (malicious setting).\nIn the malicious setting, $\\mathcal{O}$ may interpose a wrapper $\\mathcal{W}$ between the external world and the vendor API. $\\mathcal{W}$ applies a transformation $T:\\Sigma^{*}\\to\\Sigma^{*}$ to incoming content before it is incorporated into $\\mathbf{x}^{\\mathrm{in}}$ , and may filter, substitute, paraphrase, or otherwise modify token sequences. We formalize the adversary’s capabilities and constraints in Section 3.4.

Interaction surface.\nThe agent’s externally visible behavior consists of the actions $a_{t}$ it takes in the world: messages sent, API calls made, content posted, calls placed. These actions are observable by external parties but carry no reliable signal identifying the operator or the vendor API session that produced them.

The key structural feature of this system is that $\\mathcal{V}$ and $\\mathcal{D}$ sit on opposite sides of the agent: $\\mathcal{V}$ sees model calls but not external behavior, while $\\mathcal{D}$ sees external behavior but not model calls. The attribution protocol bridges this gap through the vendor’s session log.

3.2. Trust Assumptions

\n\n

Vendor: honest. $\\mathcal{V}$ executes attribution requests faithfully and does not disclose ongoing investigations to the operator. This is grounded in reputational and legal incentives, a vendor that returned false results or tipped off operators would face severe consequences.

Authority: registered and accountable. $\\mathcal{D}$ ’s requests are authenticated and auditable. This prevents anonymous abuse of the attribution mechanism and gives $\\mathcal{V}$ a principled basis for refusing unauthorized requests.

Operator: untrusted. No assumptions of honesty or cooperation. $\\mathcal{O}$ may be an active adversary (malicious setting) or simply non-cooperating (benign setting).

Agent: potentially an adaptive wrapper. We make no assumptions about $\\mathcal{A}$ ’s internal architecture beyond what is visible at the API boundary. $\\mathcal{A}$ may include a preprocessing layer $\\mathcal{W}$ that transforms incoming content before it reaches the model. We treat $\\mathcal{A}$ as a black box and design the protocol to function without cooperation or transparency from it.

3.3. Interaction Assumptions

\n\n

We assume that the model is hosted and logged by $\\mathcal{V}$ , but the agent runtime and any wrapper run on infrastructure controlled by $\\mathcal{O}$ and are not observable by $\\mathcal{V}$ or $\\mathcal{D}$ . This is the standard commercial deployment model and a structural feature of the setting: $\\mathcal{V}$ sees model calls but not the agent’s external behavior, while $\\mathcal{D}$ sees the agent’s external behavior but not model calls. Any attribution mechanism must therefore bridge these two views indirectly, since neither party alone has visibility into both.

Authority’s interaction capability. Bridging the two views requires $\\mathcal{D}$ to introduce content into the agent’s interaction stream so that it propagates into $\\mathcal{V}$ ’s logs. We distinguish two cases by the authority’s access to the agent:

• \n
\n
Direct interaction. $\\mathcal{D}$ can engage $\\mathcal{A}$ directly, for instance by initiating contact with a chatbot, support endpoint, or polled API. $\\mathcal{D}$ controls the content of the exchange and records the time at which content is introduced.
\n
• \n
\n
Passive interaction. $\\mathcal{D}$ cannot engage $\\mathcal{A}$ directly, and must instead anticipate where $\\mathcal{A}$ will act next, place content at those locations in advance, and instrument them with hooks that fire on consumption.
\n

The two modes differ in mechanism, not in principle: in both, $\\mathcal{D}$ controls what $\\mathcal{A}$ ingests, with passive injection acting as the honeypot analogue of direct interaction. The passive case requires some basis for predicting $\\mathcal{A}$ ’s next interaction, whether from direct observation, victim reports, or platform telemetry; Section 4 formalizes the trajectory types this gives rise to and their implications for placement.

3.4. Adversary Model

\n\n

In some cases, the operator may be aware of the possibility of agent attribution and attempt to evade it by filtering canaries from the agent’s interaction stream. We therefore distinguish two settings, which determine the canary construction the authority should use.

In the non-adversarial setting, the operator is not attempting to evade attribution, and the agent passes incoming content to the vendor model without filtering. This covers all unintentional failure modes of Section 2, where no deliberate filtering occurs, as well as unsophisticated adversaries who cause intentional harm without designing mechanisms to detect or avoid canaries (e.g., a bitter ex deploying an agent to harass a former partner). In both cases, any injected content reaches the vendor’s log with high probability.

In the adversarial setting, the operator knows the attribution protocol exists and actively attempts to evade it, deploying a wrapper $\\mathcal{W}$ that transforms incoming content via $T$ before passing it to the model. The adversary must simultaneously achieve evasion, so that no injected canary reaches the vendor log, and utility preservation, so that the agent can still perform its task adequately; an agent that fails its mission is useless to the operator. We now elaborate on our assumptions of this setting:

Capabilities. The adversary can observe all incoming content; apply any computable transformation (deletion, substitution, paraphrasing, routing through a secondary model); know the canary universe $\\mathcal{N}$ in the worst case; and delay or drop interactions.

Constraints. The adversary cannot access the vendor’s log; cannot observe which canary subset was selected for a given interaction; cannot distinguish canary items from legitimate content (by design of the canary construction); and cannot remove arbitrary content without risking utility degradation.

The utility-evasion tension. These constraints place the adversary in a dilemma. Evasion requires removing content that might be a canary, but since canaries are indistinguishable from legitimate task-relevant content, removing them risks also removing content the agent needs to function. The more aggressively the adversary filters, the more it degrades its own agent. This tension is the foundation of the asymmetry guarantee in Appendix D.

4. The Agent Attribution Protocol

\n\n

4.1. Overview

\n\n

We present a protocol between an authority $\\mathcal{D}$ and a vendor $\\mathcal{V}$ for attributing a suspect agent $\\mathcal{A}$ to its operator $\\mathcal{O}$ ’s account $a$ .

Figure 4 illustrates the protocol end-to-end; it proceeds in four steps:

(1) \n
\n
$\\mathcal{D}$ assesses the setting, generates the appropriate canary value(s) and injects them into $\\mathcal{A}$ ’s input stream and notes the time of injection $\\tau$ .
\n
(2) \n
\n
In parallel, $\\mathcal{D}$ initiates an attribution request with participating vendor $\\mathcal{V}$ to determine if $\\mathcal{A}$ ’s LLM is hosted by them.
\n
(3) \n
\n
$\\mathcal{V}$ searches its logs for the canaries around the given time $\\tau$ .
\n
(4) \n
\n
Finally, if found, $\\mathcal{V}$ either responds to the incident internally (e.g., by warning $\\mathcal{O}$ ), or returns the account information to $\\mathcal{A}$ for further investigation or prosecution as legally warranted.
\n

We will now discuss the various aspect of the proposed canary-based protocol.

Figure 4. Overview of the agent attribution protocol. The red circle shows the traversal of the injected canaries.

\n\n

4.2. Types of Canaries

\n\n

We define two classes of canary, distinguished by the method $\\mathcal{V}$ uses to recover them at search time: Lexical canaries and Semantic canaries.

Definition 0 (Lexical canary).

A lexical canary $\\kappa_{L}\\in\\Sigma^{*}$ is a token sequence injected verbatim into the agent’s interaction stream and recovered by exact match against $\\mathcal{L}$ .

Lexical canaries range from purely random sequences such as a hash to identifiers such as names and UUIDs. They can also be a substring taken from $\\mathcal{A}$ ’s input which long enough to be unique within some timewindow of $\\mathcal{L}$ .

Definition 0 (Semantic canary).

A semantic canary $\\kappa_{S}$ is a signature whose identity lies in meaning rather than in any specific token sequence, such as a style, concept, behavior, or structural pattern, injected into the agent’s interaction stream and recovered by a classifier.

Because $\\kappa_{S}$ is defined by meaning rather than surface form, it is more likely to survive paraphrasing and reformatting than a lexical canary. Semantic canaries range from speech styles to topical framing or even structural patterns (e.g., insistence to discuss a topic, or a webpage layout).

Definition 0 (Utility-bearing canary).

A canary $\\kappa$ (lexical or semantic) is utility-bearing if its removal from $\\mathcal{A}$ ’s interaction stream would degrade $\\mathcal{A}$ ’s ability to perform its task.

The utility-bearing property is what makes a canary robust against an adversarial wrapper: stripping a utility-bearing canary also strips information the agent depends on, so an adversary cannot remove all instances of the canary’s pattern across $\\mathcal{A}$ ’s inputs without rendering the agent ineffective. Figure 5 illustrates some examples: a filename in a directory listing is a lexical canary that a cyber agent must preserve to navigate a target network; removing all filename-shaped strings from tool outputs before they reach $\\mathcal{V}$ would prevent the agent from operating. Similarly, in a conversational scam, the caller’s emotional state and conversation points are semantic features the agent must mirror to maintain rapport; stripping them would render the agent’s responses incoherent in other interactions the agent has with the public. The asymmetry this creates is discussed further below and formalized in the Appendix D.

Figure 5. Left: A cyber agent consumes a lexical canary (filename) as it performs directory traversal. Right: a phone scam agent consumes two different semantic canaries during a call.

\n\n

4.3. Canary Selection & Injection Strategy

\n\n

Setting Assessment.\nBefore constructing canaries, $\\mathcal{D}$ assesses the case from the victim’s report (top left of Figure 4). Lexical canaries are simplest for $\\mathcal{V}$ to search for and suffice when the operator is not trying to evade attribution. However, when the harm appears intentional, the operator may attempt to strip obvious markers, for example by filtering or paraphrasing incoming content before it reaches the model. In such cases, $\\mathcal{D}$ uses utility-bearing canaries.

Non-adversarial Setting.\nWhen the operator is not likely to attempt evasion, a single lexical canary is sufficient. This can be a fresh random string, or even a fixed marker agreed upon in advance, since the agent is expected to pass incoming content to the LLM without filtering. Vendor-side recovery is practical: $\\mathcal{V}$ searches only the sessions active in the declared time window around $\\tau$ .

Adversarial Setting.\nIn the adversarial setting, a single obvious marker is fragile. The operator may filter lexical strings, paraphrase incoming content, or remove one class of canary once it is suspected. Conversely, overly generic semantic canaries, such as “angry tone,” may create high false-positive rates across the many sessions active at $\\mathcal{V}$ . We therefore use a multi-canary construction.

Let $\\mathcal{N}$ be a canary universe of $n$ items, each contextually legitimate in the target domain. In other words, $\\mathcal{N}$ is deployment-specific: canaries for a webpage-scraping agent, a conversational scam, and a cyber-reconnaissance agent would look different. At injection time, $\\mathcal{D}$ samples a $k$ -subset $K\\subseteq\\mathcal{N}$ uniformly at random and injects each into the interaction. $\\mathcal{V}$ searches the log window $\\mathcal{L}$ for these $k$ canaries and declares a candidate attribution when at least $m\\leq k$ canaries are present. The threshold $m$ is chosen via a false-positive analysis.

Adversarial robustness: Sampling multiple canaries improves both robustness and precision. For robustness, even if the adversary knows the entire potential set of all $\\mathcal{N}$ , it cannot cannot safely remove only one canary found in $\\mathcal{N}$ , such as all names or all identifiers: it does not know whether the current interaction is with $\\mathcal{D}$ or an ordinary victim, nor which canaries from $\\mathcal{N}$ were used in this instance. Evasion therefore requires broad filtering over otherwise useful content, producing a utility loss. A formalization of this asymmetry in the defender’s advantage can be found in Appendix D).

Minimal false positives: For precision, the probability that an unrelated session contains at least $m$ of the sampled canaries decreases rapidly as $k$ and $m$ increase. If multiple sessions cross the threshold, $\\mathcal{V}$ ranks them by aggregate match score and returns a short candidate list for abuse-response review. The protocol is not intended to make fully automated enforcement decisions; rather, like intrusion-detection systems (Sommer and Paxson, 2010) and vulnerability triage, it converts an otherwise intractable search over millions of concurrent sessions into a small, ranked set of likely candidates.

Vector of Injection.\nThe injection strategy depends on whether $\\mathcal{D}$ can interact with $\\mathcal{A}$ directly or only indirectly. Direct interaction is possible when $\\mathcal{A}$ accepts inbound contact, such as through a chatbot, support endpoint, or polled API. In this case, $\\mathcal{D}$ initiates the exchange and injects $K$ into content that $\\mathcal{A}$ ingests during the conversation.

When $\\mathcal{A}$ initiates its own interactions with external services or infrastructure, $\\mathcal{D}$ cannot reach it on demand. Instead, $\\mathcal{D}$ places canaries in advance at locations $\\mathcal{A}$ is expected to visit. This requires estimating the agent’s trajectory: the sequence of people, assets, or sites it is likely to contact next, inferred from prior reports or observation of an ongoing campaign. We distinguish three cases. A fixed trajectory repeatedly visits the same location, as in harassment of a single individual or a polling loop. A predictable trajectory follows an extrapolable sequence, such as enumerating employees of a target organization or crawling hosts in a network. A pattern-based trajectory has no determinate next step but follows a recognizable modus operandi, such as targeting organizations of a particular class. In each case, $\\mathcal{D}$ plants canaries at the expected locations and instruments them with hooks, such as a file-read callback or monitored API response, that fire when the agent consumes the canary.

In both direct and indirect modes, $\\mathcal{D}$ obtains the time $\\tau$ at which the canary enters $\\mathcal{A}$ ’s stream: directly from the injected message timestamp, or indirectly from the hook triggered on consumption.

5. Implementation

\n\n

We now describe our implementation of the protocol in Section 4. The design reuses most of $\\mathcal{V}$ ’s existing infrastructure: API serving, account-linked logs, and abuse-response workflows. It adds two components. Injection (Section 5.1), performed by $\\mathcal{D}$ , constructs a contextually plausible canary universe and places the sampled subset into $\\mathcal{A}$ ’s interaction stream. Detection (Section 5.2), performed by $\\mathcal{V}$ , scans sessions active in the search window for the sampled canaries while remaining within production-serving constraints.

5.1. Injection

\n\n

In the non-adversarial setting, injection is straightforward: $\\mathcal{D}$ uses $k=1$ with a random lexical string. This is sufficient because non-malicious agents typically perform little or no preprocessing and pass incoming content to the LLM verbatim.

In the adversarial setting, context matters. Since utility-bearing canaries must look like legitimate task content, the domain of the canary universe $\\mathcal{N}$ depends on the interaction surface. Examples include:

• \n
\n
Social conversation. $\\kappa_{L}$ can be a named project reference mentioned in passing (“I’m calling about the Meridian-47 onboarding”); $\\kappa_{S}$ can be a speech style, topic, sentiment, or conversational habit.
\n
• \n
\n
Cyber reconnaissance. When $\\mathcal{A}$ reads files, logs, or API responses, $\\kappa_{L}$ can be a task-relevant identifier, such as a filename, employee ID, host name, database key, or structured record. $\\kappa_{S}$ can encode properties of the artifact being analyzed, such as webpage purpose, code style, naming conventions, error-handling idioms, log format, or field order.
\n
• \n
\n
Web or document interaction. $\\kappa_{L}$ can be a referenced entity, citation, product code, tracking identifier, or factual detail embedded in the page or document. $\\kappa_{S}$ can be a design style, layout pattern, topical emphasis, or document intent or structure that the agent must preserve to understand or summarize the content.
\n

For practicality, $\\mathcal{D}$ constructs $\\mathcal{N}$ on demand with an LLM. The prompt specifies the target setting, the canary class, and a small set of seed exemplars, and asks the model to enumerate plausible canaries for that context. After sampling $K\\subset\\mathcal{N}$ , $\\mathcal{D}$ uses an LLM again to insert the selected canaries naturally. The generator is given the surrounding content, such as the conversation so far, the target HTML page, or the file being read, together with the canaries in $K$ , and is instructed to weave them into the content without making them conspicuous. This same insertion process applies to both $\\kappa_{L}$ and $\\kappa_{S}$ ; the only exception is the non-adversarial case, where the random string can be inserted directly.

5.2. Detection

\n\n

Detection runs at $\\mathcal{V}$ over the search window specified in the attribution request. It must be cheap enough to scan every active session without disrupting production serving. Lexical canaries are recovered by substring matching over session inputs $\\mathbf{x}^{\\text{in}}$ , while semantic canaries require a lightweight classifier over the same content.

Lexical canary detection.\nFor each candidate session, $\\mathcal{V}$ checks whether any $\\kappa_{i}\\in K$ appears in $\\mathbf{x}^{\\text{in}}$ . Three properties make this tractable at vendor scale. First, the search window bounds the work to sessions concurrent with the injection, independent of how large $\\mathcal{L}$ is in aggregate. Second, the workload is map-reduce-friendly: log shards are scanned independently for matches in $K$ and aggregated centrally, so latency scales with the largest shard rather than the full window. Third, $\\mathcal{V}$ already stores $\\mathbf{x}^{\\text{in}}$ in tokenized form, since tokens are the canonical input to $\\mathcal{M}$ ; we exploit this by emitting and matching $\\kappa$ at the token level. This yields approximately a $2\\times$ speedup compared to char sub string matching. This is because tokens are larger aggregates and stored as sequences of integers over vocabulary $\\Sigma$ . Result of an experiment confirming this can be found in Section 6.5.

Semantic canary detection.\nSemantic canaries are detected as a multi-label classification problem: for each active session, $\\mathcal{V}$ estimates which canaries in $\\mathcal{K}$ are present. We consider two efficient implementations, and evaluate one instantiation of each in Section 6.

First, $\\mathcal{V}$ can run a small NLP model over the session text to predict the semantic canaries present in the session. Second, when $\\mathcal{V}$ already caches model-side representations, it can reuse that computation: instead of classifying raw tokens, a lightweight classifier can operate over aggregated activations from $\\mathcal{M}$ . This reuse pattern is not new; vendors already attach lightweight probes to token streams or hidden-layer activations for real-time safety enforcement (Kramár et al., 2026; Anthropic, 2026; Nguyen et al., 2025; Inan et al., 2023). Semantic detection can use the same framework. The main added requirement is a rolling cache, sized to the search window, that keeps the classifier inputs available near the serving fleet at attribution time.

6. Evaluation

\n\n

We evaluate whether our canary-based attribution protocol can trace deployed\nagents across three representative domains: communication agents\n(Section 6.2), web agents (Section 6.3), and cyber agents\n(Section 6.4). These domains exercise different interaction\nsurfaces from the threat landscape of Section 2: dialogue with\npeople, ingestion of web content, and end-to-end autonomous tool use. Across\nthem, we ask three questions. First, do injected canaries reach the\nvendor-visible model input in realistic agent workflows? Second, can the\nvendor recover enough of those canaries to identify the responsible session\nwith low false-positive rates? Third, when an operator attempts to suppress\ncanaries, does doing so degrade the agent’s own task performance?

6.1. Experimental Setup

\n\n

All experiments instantiate the same protocol-level decision rule. An\nauthority injects a set $K$ of $k$ canaries into content that the\nagent is expected to consume. The vendor then searches the relevant session\nlogs around the injection time $\\tau$ . A session is declared a match if at\nleast $m$ of the $k$ injected canaries are detected. We refer to this as the\nsession-level attribution decision.

We report results at two granularities. At the per-canary granularity, we\nmeasure whether an individual canary $\\kappa_{i}$ is recovered from a session,\nusing true positive rate (TPR), false positive rate (FPR), and ROC curves.\nAt the session granularity, we apply the $m$ -of- $k$ rule and report the TPR\nand FPR of the resulting session-level attribution decision. This distinction\nis important: a detector may miss some injected canaries, but the protocol\ncan still attribute the session as long as at least $m$ of them survive and\nare detected.

We evaluate both lexical and semantic canaries from Section 4.2.\nLexical canaries $\\kappa_{L}$ are recovered by exact match. Semantic canaries\n $\\kappa_{S}$ are recovered by lightweight classifiers. In adversarial settings,\nwe focus on utility-bearing canaries: canaries embedded in content the agent\nneeds in order to complete its task. Each domain is evaluated in a\nnon-adversarial condition, where the agent forwards content to the model\nwithout deliberate filtering, and in an adversarial condition, where a\nwrapper modifies incoming content before it reaches the model. The strength\nand form of the wrapper vary by domain. In communication agents, it\nparaphrases user-side text. In web agents, it paraphrases HTML-derived\ncontent and is aware of the canary taxonomy but not the sampled subset $K$ .\nIn cyber agents, the adversary is stronger: it knows the injected canaries\nand attempts to remove them.

The domain-specific choices (the interaction substrate, canary universe,\ndetector, preprocessing pipeline, and adversary) are introduced in the\ncorresponding subsections. Implementation details, full canary sets $\\mathcal{N}$ , prompts,\nand additional ablations are deferred to the appendix.

6.2. Communication Agents

\n\n

Communication agents interact directly with people or communities, as in\nscam automation, targeted harassment, customer-support agents, or forum\nposting. This setting tests whether canaries can be embedded in ordinary\nconversation and later recovered from the vendor’s logs. It also provides a\nclean comparison between lexical canaries, which require exact string\nsurvival, and semantic canaries, which may survive changes in wording.

Setup.\nWe evaluate two communication surfaces: one-on-one chats and forum threads.\nBoth are synthesized with Qwen 2.5-7B-Instruct from per-scenario\nconfigurations specifying the agents’s role, situational context, and\nconversational style. We cover 21 benign scenarios (e.g., customer-support\nand FAQ assistants) and 21 malicious ones (e.g., scam automation,\ntargeted harassment, forum-posting sockpuppets), and from each base\nconversation we generate many variants by varying the number and mix of\ninjected lexical and semantic canaries, yielding a large pool of marked\nand unmarked sessions. The authority controls the user-side turns and\ninjects canaries there, since those are the turns the agent must consume\nto continue the interaction; the agent controls its own outgoing turns\nand may rewrite or summarize incoming user turns before the model sees\nthem. Conversation lengths, scenario templates, canary-count sweeps, and\nthe full set $\\mathcal{N}$ are in the Section I.1.

We instantiate lexical canaries $\\kappa_{L}$ in two forms. The first is a\nrandom alphanumeric string. The second is a utility-bearing reference code\nthat fits naturally into the scenario, such as a project name, case\nidentifier, or other conversation-relevant value. We instantiate semantic\ncanaries $\\kappa_{S}$ such as an authority, discourse, and persona patterns drawn from an $\\mathcal{N}$ with $n=31$ . These semantic canaries are inserted by a Qwen rewrite\nthat preserves the topic and meaning of the original user-side turn while\nadding the requested patterns.

The adversarial wrapper is a second Qwen model that paraphrases each\nconversation’s user-side text in a single pass. The wrapper is instructed to\npreserve reference codes, named entities, dates, amounts, and URLs verbatim,\nbut it is not instructed to preserve semantic patterns. Thus, semantic\npatterns may be paraphrased away as collateral damage. This is a relatively\nsimple adversary, but it captures the common evasion strategy of routing\nincoming content through a paraphraser before it reaches the model. The full prompt is given in Fig. 32.

In the non-adversarial setting, both random lexical canaries and\nutility-bearing lexical canaries reach TPR $\\approx 1.0$ at FPR $\\approx 0$ .\nUnder paraphrasing, exact string survival becomes brittle: utility-bearing\nlexical canaries survive at TPR $\\approx 0.20$ , and random lexical canaries\nsurvive at TPR $\\approx 0.21$ ; the per-canary breakdown is in the (Fig. 12). These results show that lexical canaries are\nnearly ideal when content is passed through unchanged, but are unreliable\nonce the interaction is rewritten.

For semantic canaries, we train a multilabel classifier over cached\nactivations from a frozen Qwen 2.5-7B-Instruct model, with one sigmoid head\nper semantic pattern. Full detector details are in the Section E.1.2.\nIn the chat setting, per-canary AUC ranges from $0.92$ to $1.00$ , with\nmacro-average AUC $0.98$ . The average ROC reaches TPR $=0.91$ at\nFPR $=0.05$ (Fig. 11).

Figure 6. Attribution at

k=20

on chat and forum. Both rates decay with

m

; the operating regime sits where the curves separate.

\n\n

Results.\nFigure 6 reports session-level attribution for $k=20$ \ninjected semantic canaries on chat and forum, sweeping the threshold $m$ .\nAs $m$ increases, both TPR and FPR decrease. The useful operating regime is\nwhere FPR has already fallen close to zero while TPR remains high. On chat,\n $m=7$ gives non-adversarial TPR $\\approx 1.00$ at FPR $\\approx 0.01$ .\nUnder paraphrase, TPR remains above $0.97$ at the same operating point.\nForum follows the same qualitative shape, with a milder FPR decay because\nthreads contain more text and therefore more opportunities for unrelated\nsessions to contain some matching semantic patterns.

The communication experiments show that conversational canaries can support\nsession-level attribution. Lexical canaries are cheap and nearly perfect\nwhen messages are not rewritten, but paraphrasing makes exact string\nsurvival unreliable. Semantic canaries provide a complementary channel: they\nallow the defender to tune the $m$ -of- $k$ decision rule to keep FPR low while\nmaintaining high TPR.

6.3. Web Agents

\n\n

Web agents read HTML pages, documents, and structured web content. This\nsetting differs from communication because canaries may be lost before any\nadversary acts: many web agents preprocess pages before sending them to the\nmodel. The web experiments therefore test both ordinary preprocessing\nsurvival and adversarial robustness.

Setup. We sample $10{,}000$ English HTML documents from Common Crawl\n(CC-MAIN-2024-10)(Common Crawl, 2024) and inject canaries directly\ninto the page. The authority controls the page content, while the agent may\napply its own extraction or cleaning pipeline before the model sees the\npage. We evaluate two forms of lexical canaries. Structural lexical canaries\nare placed in non-rendered or weakly rendered DOM locations, such as\nmetadata or hidden elements. Visible lexical canaries are placed in rendered\ntext that the agent is more likely to consume. We also evaluate semantic\ncanaries that encode document-level layout archetypes. For example, an\nurgency-signaling page combines countdown banners, scarcity language, and\nprominent calls to action (see Fig. 25), while a Shopify-themed page mimics\nstorefront-specific structure and styling. These semantic canaries are\ninserted by a GPT-4o-mini rewrite (see prompt in Fig. 38) that imposes the requested layout while\npreserving page content. The full web canary universe is listed in the Tables 7 and 8.

For the model the transformations $T$ performed by web agents, we evaluate seven\nextraction profiles, including rule-based BeautifulSoup(Richardson, ) variants,\nCrawl4AI(Crawl4AI contributors, ) raw and cleaned modes, markdown extraction, and LLM-based\nextraction. These profiles capture common ways in which a web agent may\nsimplify or transform HTML before sending it to the model. We also test an\nadversarial GPT-4o-mini paraphrase wrapper. The wrapper is aware of the\ncanary taxonomy but not the specific sampled subset $K$ , and is instructed\nto rephrase content so as to strip possible canaries without knowing their\nidentity or location. The full prompt is given in Fig. 37.

Figure 7. Lexical canary survival rates across preprocessing profiles\n(top 8 of 30 shown). All canaries survive over 60% of the time.

\n\n

Results. Figure 7 shows that lexical survival depends\nstrongly on canary placement. Visible lexical canaries, which live in\nrendered text the agent must read, survive rule-based preprocessing\nessentially intact. Even under LLM extraction, the harshest profile we test,\nevery visible lexical canary clears $60\\%$ survival. Structural lexical\ncanaries behave differently: they survive when DOM structure is preserved,\nbut are stripped by preprocessors that flatten, clean, or summarize the\npage. Full per-canary results are in Table 1.

This result highlights a constraint specific to web agents: canaries must survive the agent’s input pipeline, not just an adversary. A raw-HTML scraper may expose both structural and visible canaries to the model, while a markdown-based or LLM-extraction scraper may discard structural canaries. When the authority does not know the agent’s preprocessing pipeline, visible or semantically load-bearing canaries are therefore safer choices in this setting.

For semantic canaries, we train a multi-head ModernBERT\n(Warner et al., 2024) classifier with one head per\nsemantic canary. The classifier recovers semantic canaries from raw or\npost-paraphrase HTML. Detector details, per-canary ROC curves, and\nadditional $k$ values are in\nSection E.2.3, Fig. 14, and Fig. 15.

Figure 8. HTML document attribution at

k=5

embedded semantic canaries. TPR remains high through

m=3

, while FPR is near zero from

m=2

onward. The FPR curve averages adversarial and non-adversarial regimes, whose values nearly overlap (max

\\Delta\\approx 0.007

\n\n

Figure 8 reports session-level attribution with\n $k=5$ embedded semantic canaries. In the non-adversarial setting, TPR\nstays near $1.0$ through $m=3$ and falls to $0.58$ only at $m=5$ . Under\nparaphrase, TPR drops earlier, reaching $0.82$ at $m=3$ and $0.52$ at\n $m=4$ . FPR is tested on a large negative set ( $\\approx{7000}$ documents), and results show it is pinned at zero for $m\\geq 2$ in both regimes.

The web experiments show that visible lexical canaries are robust because\nthey are part of the content the agent needs to read. Semantic layout\ncanaries provide a second channel that survives paraphrasing better than\nexact surface strings. As in the semantic setting, the defender\ncontrols the operating point through the joint choice of $k$ and $m$ :\nincreasing $k$ gives more opportunities for canaries to survive, while\nincreasing $m$ reduces false positives.

6.4. Cyber Agents

\n\n

Cyber agents provide the strongest end-to-end test in our evaluation. Unlike\nthe communication and web experiments, the agent is not processing a fixed\nsynthetic trace or static page. It is an autonomous tool-using system trying\nto complete a task. This setting tests whether attribution works when\ncanaries are embedded into artifacts that the agent must inspect in order to\nsucceed, and whether an adaptive adversary can remove canaries without\ndamaging the agent’s task performance.

Setup.\nWe build 15 web-CTF (capture-the-flag) challenges, implemented as Flask servers and spanning\n14 OWASP web-attack classes.\nThe agent is Qwen 3.5-9B running in a\ncustom multi-turn loop over a 16-tool registry. The full prompt instructing the agent can be seen in Fig. 39. The agent reads challenge\nartifacts such as source files, READMEs, HTTP responses, network outputs,\nand binaries, then reasons over them to recover a flag. Solve rate is the\nfraction of challenges in which the agent recovers the flag within the turn\nbudget. Full details and hyperparameters of the agent and CTF are in\nSection E.3.1.

Lexical canaries are UUID-v4 values placed in structural locations on the\nchallenge response: HTTP headers, <meta> tags, HTML comments,\ncookies, static-asset filenames, hidden inputs, and visible inline\nidentifiers. These locations span both peripheral content, which an\nadversary may strip cheaply, and task-critical content, which the agent must\npreserve to solve the challenge. Semantic canaries draw from the same\nlayout-pattern family used in the web agent setting, with $|\\mathcal{N}|=14$ .\nThe full location\ntaxonomy and injection mechanics are in Section E.3.2.

The adversary in this setting is stronger than the communication and web\nparaphrasers. It is canary-aware and attempts to remove the injected\ncanaries from tool outputs before they reach the model. All adversarial prompts can be seen in Section G.4.\nThis creates a\ndirect utility-evasion tradeoff: removing content may suppress attribution\nevidence, but it can also remove the information the agent needs to recover\nthe flag.

Figure 9. Lexical-canary location ablation. Top: agent solve rate\nwith and without the canary-aware adversary. Bottom: per-location\nreach rate, i.e., the fraction of locations in which the planted canary\nsurvived into the raw tool output reaching the agent, with

95\\%

Wilson\nconfidence intervals.

\n\n

Results.\nFigure 9 shows how canary placement affects both survival\nand task utility. With the canary-aware adversary, solve rate falls from\n $51\\%$ to $9\\%$ ( $23/45\\to 4/45$ ). This drop shows that suppressing\ncanary-bearing content can also strip the artifacts the agent needs for the\ntask. Canary survival is not uniform across locations. Filenames and\nvisible body identifiers, which the agent must often read to make progress,\nretain $77\\%$ and $70\\%$ attribution, respectively. <meta> tags and\nhidden form inputs, which are less task-critical, fall to $62\\%$ and $50\\%$ .\nPer-location numbers are reported in Section E.3.3.

Figure 10. CTF attribution at

K=5

. Session-level TPR and FPR\nvs. detection threshold

m

. Solid: non-adversarial; dotted: adversarial\nparaphrase. Solve rates:

42\\%

vs.

31\\%

. Companion

K=3

panel in\nSection E.3.5.

\n\n

Figure 10 reports session-level attribution for\n $K=5$ injected semantic canaries with $n=45$ runs per cell. At $m=1$ ,\ndetection rate is $100\\%$ in both the non-adversarial and adversarial\nregimes. Under the adversarial wrapper, TPR remains above $90\\%$ through\n $m=2$ , with FPR near zero throughout. The same set of experiments gives\nattribution TPR $\\geq 98\\%$ in the semantic track under the adversary.\nPer-canary ROC curves, calibration, and the $K=3$ companion panel are in\nSections E.3.6 and E.3.5.

The cyber experiments provide the clearest evidence for the asymmetry\nbehind the protocol. Canaries placed in task-critical locations are\ndifficult to remove safely. A canary-aware adversary can strip peripheral\nmetadata, but when it removes content the agent actually needs, the agent’s\nsuccess rate collapses. Thus, evasion is possible only by moving along the\nutility-evasion frontier: reducing attribution evidence also reduces the\nagent’s ability to complete the attack.

6.5. Detection Throughput

\n\n

Finally, we evaluate whether the vendor-side search step is operationally\npractical. The protocol does not require the vendor to search all historical\nlogs. Instead, the vendor searches sessions concurrent with the canary’s\ninjection time $\\tau$ . The relevant scalability question is therefore how\nsearch cost grows with the number of sessions in that bounded window.

We benchmark lexical canary search across corpora of\n $N\\in\\{2{,}000,5{,}000,7{,}000,10{,}000,13{,}000\\}$ sessions drawn\nfrom the web-agent corpus. A canary is inserted into one or more documents,\nand the search task is to recover all documents containing it. We compare\ncharacter-level search using Python’s str.find with token-level\nsearch using vectorized numpy over token arrays. Token-level search\nmodels the production setting in which the vendor already stores tokenized\nmodel inputs.

The bounded-window structure is the key scalability property. Search cost\ndepends on serving load within the attribution window, rather than total log\nsize. Token-level search also matches the vendor’s existing representation\nof model inputs, avoiding additional tokenization at search time. Semantic\ndetection inherits the same bounded-window structure and requires only a\nlightweight classifier at search time, because the input text or cached\nrepresentations are collected when the log is written.

7. Discussion

\n\n

Our results highlight two main lessons. First, the protocol’s robustness comes from a utility-evasion tradeoff rather than from hiding the canaries. In messaging, paraphrasing lowers TPR while FPR remains near zero, making $(k,m)$ the defender’s main operating knob. In web settings, the relevant failure mode is often preprocessing: structural $\\kappa_{L}$ can be removed by aggressive extraction, while visible $\\kappa_{L}$ survives. In cyber, the tradeoff appears directly in task performance: the wrapper that suppresses canary-bearing artifacts also reduces solve rate from $51\\%$ to $9\\%$ . Across settings, evasion is possible, but it becomes costly when the canaries are tied to content the agent needs.

Second, lexical and semantic canaries are complementary. $\\kappa_{L}$ is preferable when the setting provides task-relevant identifiers that the agent must preserve, such as reference codes in conversations, asset fingerprints in web content, or filenames and hidden-input identifiers in CTF artifacts. $\\kappa_{S}$ is preferable when no such identifier can be placed naturally, when paraphrasing destroys lexical survival, or when inserting explicit identifiers would make the interaction suspicious. In practice, the best choice depends less on the abstract adversary model than on the agent’s ingestion pipeline and the kind of content it must preserve.

Several limitations remain. Our experiments use a small number of model families and wrapper configurations, so future work should test cross-model generalization, including cases where the agent, wrapper, detector, and canary generator come from different model families. We also evaluate attribution primarily at the session level; coordinated campaigns spread across multiple agents, sessions, or vendor accounts require composing multiple attribution results into a campaign-level view. Finally, we do not fully exercise indirect injection. Our web setting approximates it through authority-controlled pages, but realistic fixed, predictable, and pattern-based trajectories should be evaluated against agents whose next actions are uncertain.

Despite these limitations, this work is the first to identify and formalize the problem of agent attribution. It provides an effective solution for non-malicious settings and takes a significant step toward robust attribution in adversarial settings.

8. Related Work

\n\n

8.1. Watermarking and Provenance Techniques

\n\n

The closest existing body of work to agent attribution is text watermarking, the problem of embedding a detectable signal in model-generated text so that its origin can be verified. We survey the main approaches and explain why none of them transfer to the agent attribution setting.

Token-level watermarking. The dominant paradigm, introduced by (Kirchenbauer et al., 2023) and extended by (Christ et al., 2024; Zhao et al., 2023), partitions the vocabulary $\\Sigma$ into a green list and a red list at each generation step, biasing the model toward green-list tokens. A detector checks for a statistically anomalous proportion of green tokens in a candidate text. This signal survives light editing but is well-documented to be fragile under paraphrasing: substituting synonyms, changing sentence structure, or routing the text through a second language model destroys the green/red token distribution while preserving semantic content (Krishna et al., 2023; Zhang et al., 2023). An adversarial agent wrapper needs only to pass incoming content through a paraphrase model before forwarding it to the vendor API.

Semantic watermarking. More recent approaches attempt to embed watermarks at the level of meaning rather than token identity (Hou et al., 2024), using synonym substitution or sentence-level paraphrasing strategies to encode bits in the semantic choices made during generation. These are more robust to surface-form transformations but face a different limitation in our setting: they mark generated output, not injected input. This means that at best watermarking proves which model produced the text, but not which account.

Model fingerprinting. A separate line of work embeds persistent signals in model weights or activations to identify which model produced a given output (Xu et al., 2024; Pasquini et al., 2025). These approaches identify the model but not the account in a vendor-hosted setting where many operators share the same underlying model, model fingerprinting provides no discrimination between operator accounts, which is precisely what attribution requires.

Why these approaches cannot solve attribution. The reason none of the above techniques transfer is not a question of robustness or efficiency but of direction. Attribution is, by definition, the task of identifying the account operating the agent. Accounts exist only at the vendor, and only the vendor can consult its own records to link a session to an account. For the vendor to perform that lookup, the session must contain some signal that the authority can describe and the vendor can search for. That signal must therefore originate with the authority and travel into the agent, through whatever transformations its wrapper applies, and ultimately into the vendor’s logs. Watermarking and fingerprinting are both output-side: watermarking reads a signal back from generated text, fingerprinting reads a model’s identity from its responses to chosen probes. Neither answers which account produced a session.

9. Conclusion

\n\n

This paper identifies and formalizes the emerging problem of agent attribution: the missing ability to link harmful agent behavior observed in the world back to the responsible operator controlling it. We show that this gap affects both benign failures and deliberate abuse, and that existing recourse mechanisms fail without a technical bridge between observed interactions and vendor-side logs. To address this gap, we present the first practical and concrete attribution protocol for agents powered by vendor-hosted LLMs. Our canary-based approach enables authorized parties and vendors to recover the originating session and account without requiring universal pre-registration or continuous identity exposure, offering a deployable path toward accountability for increasingly autonomous AI agents.

Acknowledgments

\n\n

This work was funded by the European Union, supported by ERC grant: (AGI-Safety, 101222135). Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Research Council Executive Agency. Neither the European Union nor the granting authority can be held responsible for them.

References

\n\n

Anthropic (2025a)\nAnthropic\n\nDetecting and countering misuse of ai: august 2025.\n\nNote: https://www.anthropic.com/news/detecting-countering-misuse-aug-2025Accessed: 2026-04-29\n\nCited by: §1,\n§2.3,\n§2.5.\n
Anthropic (2025b)\nAnthropic\n\nDisrupting the first reported ai-orchestrated cyber espionage campaign.\n\nNote: https://www.anthropic.com/news/disrupting-AI-espionageAccessed: 2026-04-29\n\nCited by: §1,\n§2.3,\n§2.5.\n
Anthropic (2026)\nAnthropic\n\nNext-generation constitutional classifiers: more efficient protection against universal jailbreaks.\n\nNote: https://www.anthropic.com/research/next-generation-constitutional-classifiersAccessed: 2026-04-29\n\nCited by: §5.2.\n
Bowen et al. (2009)\nB. M. Bowen, S. Hershkop, A. D. Keromytis, and S. J. Stolfo\n\nBaiting inside attackers using decoy documents.\n\nIn International Conference on Security and Privacy in Communication Systems,\n\npp. 51–70.\n\nCited by: §1.\n
Carlini et al. (2024)\nN. Carlini, M. Jagielski, C. A. Choquette-Choo, D. Paleka, W. Pearce, H. Anderson, A. Terzis, K. Thomas, and F. Tramer\n\n Poisoning Web-Scale Training Datasets is Practical .\n\nIn 2024 IEEE Symposium on Security and Privacy (SP),\n\nVol. , Los Alamitos, CA, USA, pp. 407–425.\n\nExternal Links: ISSN ,\nDocument,\nLink\n\nCited by: §2.2.\n
Christ et al. (2024)\nM. Christ, S. Gunn, and O. Zamir\n\nUndetectable watermarks for language models.\n\nIn The Thirty Seventh Annual Conference on Learning Theory,\n\npp. 1125–1139.\n\nCited by: §8.1.\n
Common Crawl (2024)\nCommon Crawl\n\nCommon crawl dataset: CC-MAIN-2024-10.\n\nNote: https://commoncrawl.org/Accessed: 2026-04-29\n\nCited by: §6.3.\n
[8]\nCrawl4AI: open-source llm friendly web crawler and scraper\n\nNote: Open-source web crawler and scraper for LLM applications\n\nExternal Links: Link\n\nCited by: §6.3.\n
Goldstein et al. (2023)\nJ. A. Goldstein, G. Sastry, M. Musser, R. DiResta, M. Gentzel, and K. Sedova\n\nGenerative language models and automated influence operations: emerging threats and potential mitigations. arxiv.\n\narXiv preprint arXiv:2301.04246 10.\n\nCited by: §1,\n§2.3.\n
Greshake et al. (2023)\nK. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz\n\nNot what you’ve signed up for: compromising real-world llm-integrated applications with indirect prompt injection.\n\nIn Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security,\n\nAISec ’23, New York, NY, USA, pp. 79–90.\n\nExternal Links: ISBN 9798400702600,\nLink,\nDocument\n\nCited by: §2.2.\n
Hendrycks et al. (2023)\nD. Hendrycks, M. Mazeika, and T. Woodside\n\nAn overview of catastrophic ai risks.\n\narXiv preprint arXiv:2306.12001.\n\nCited by: §1,\n§2.2.\n
Hou et al. (2024)\nA. Hou, J. Zhang, T. He, Y. Wang, Y. Chuang, H. Wang, L. Shen, B. Van Durme, D. Khashabi, and Y. Tsvetkov\n\nSemstamp: a semantic watermark with paraphrastic robustness for text generation.\n\nIn Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers),\n\npp. 4067–4082.\n\nCited by: §8.1.\n
Hubinger et al. (2019)\nE. Hubinger, C. Van Merwijk, V. Mikulik, J. Skalse, and S. Garrabrant\n\nRisks from learned optimization in advanced machine learning systems.\n\narXiv preprint arXiv:1906.01820.\n\nCited by: §1,\n§2.2.\n
Inan et al. (2023)\nH. Inan, K. Upasani, J. Chi, R. Rungta, K. Iyer, Y. Mao, M. Tontchev, Q. Hu, B. Fuller, D. Testuggine, and M. Khabsa\n\nLlama guard: llm-based input-output safeguard for human-ai conversations.\n\nExternal Links: 2312.06674,\nLink\n\nCited by: §5.2.\n
Kirchenbauer et al. (2023)\nJ. Kirchenbauer, J. Geiping, Y. Wen, J. Katz, I. Miers, and T. Goldstein\n\nA watermark for large language models.\n\nIn International conference on machine learning,\n\npp. 17061–17084.\n\nCited by: §8.1.\n
Kramár et al. (2026)\nJ. Kramár, J. Engels, Z. Wang, B. Chughtai, R. Shah, N. Nanda, and A. Conmy\n\nBuilding production-ready probes for gemini.\n\nExternal Links: 2601.11516,\nLink\n\nCited by: §5.2.\n
Krishna et al. (2023)\nK. Krishna, Y. Song, M. Karpinska, J. Wieting, and M. Iyyer\n\nParaphrasing evades detectors of ai-generated text, but retrieval is an effective defense.\n\nAdvances in neural information processing systems 36, pp. 27469–27500.\n\nCited by: §8.1.\n
Liu et al. (2024)\nY. Liu, Y. Jia, R. Geng, J. Jia, and N. Z. Gong\n\nFormalizing and benchmarking prompt injection attacks and defenses.\n\nIn 33rd USENIX Security Symposium (USENIX Security 24),\n\nPhiladelphia, PA, pp. 1831–1847.\n\nExternal Links: ISBN 978-1-939133-44-1,\nLink\n\nCited by: §2.2.\n
Mi et al. (2019)\nX. Mi, X. Feng, X. Liao, B. Liu, X. Wang, F. Qian, Z. Li, S. Alrwais, L. Sun, and Y. Liu\n\nResident evil: understanding residential ip proxy as a dark service.\n\nIn 2019 IEEE symposium on security and privacy (SP),\n\npp. 1185–1201.\n\nCited by: §2.4.\n
Mitchell et al. (2023)\nE. Mitchell, Y. Lee, A. Khazatsky, C. D. Manning, and C. Finn\n\nDetectgpt: zero-shot machine-generated text detection using probability curvature.\n\nIn International conference on machine learning,\n\npp. 24950–24962.\n\nCited by: §2.4.\n
Ngo et al. (2022)\nR. Ngo, L. Chan, and S. Mindermann\n\nThe alignment problem from a deep learning perspective.\n\narXiv preprint arXiv:2209.00626.\n\nCited by: §2.2.\n
Nguyen et al. (2025)\nN. Nguyen, M. Deng, D. Gala, K. Naruse, F. G. Virgo, M. Byun, D. Hazra, L. Gorton, D. Balsam, T. McGrath, M. Takei, and Y. Kaji\n\nDeploying interpretability to production with rakuten: sae probes for pii detection.\n\nGoodfire.\n\nNote: https://www.goodfire.ai/blog/deploying-interpretability-to-production-with-rakuten\n\nCited by: §5.2.\n
OpenAI (2024)\nOpenAI\n\nInfluence and cyber operations: an update.\n\nNote: https://cdn.openai.com/threat-intelligence-reports/influence-and-cyber-operations-an-update_October-2024.pdfAccessed: 2026-04-29\n\nCited by: §1.\n
Pan et al. (2022)\nA. Pan, K. Bhatia, and J. Steinhardt\n\nThe effects of reward misspecification: mapping and mitigating misaligned models.\n\narXiv preprint arXiv:2201.03544.\n\nCited by: §1,\n§2.2.\n
Pasquini et al. (2025)\nD. Pasquini, E. M. Kornaropoulos, and G. Ateniese\n\n $\\{$ llmmap $\\}$ : Fingerprinting for large language models.\n\nIn 34th USENIX Security Symposium (USENIX Security 25),\n\npp. 299–318.\n\nCited by: §8.1.\n
Perez et al. (2022)\nE. Perez, S. Huang, F. Song, T. Cai, R. Ring, J. Aslanides, A. Glaese, N. McAleese, and G. Irving\n\nRed teaming language models with language models, 2022.\n\nURL https://arxiv. org/abs/2202.03286 15.\n\nCited by: §2.3.\n
[27]\nBeautiful soup\n\nNote: Python library for parsing HTML and XML\n\nExternal Links: Link\n\nCited by: §6.3.\n
Sadasivan et al. (2023)\nV. S. Sadasivan, A. Kumar, S. Balasubramanian, W. Wang, and S. Feizi\n\nCan ai-generated text be reliably detected?.\n\narXiv preprint arXiv:2303.11156.\n\nCited by: §2.4.\n
Sela (2026)\nE. Sela\n\nA single operator, two ai platforms, nine government agencies: the full technical report.\n\nNote: https://gambit.security/blog-post/a-single-operator-two-ai-platforms-nine-government-agencies-the-full-technical-reportAccessed: 2026-04-29\n\nCited by: §2.3,\n§2.5,\n§2.5.\n
Skalse et al. (2022)\nJ. Skalse, N. Howe, D. Krasheninnikov, and D. Krueger\n\nDefining and characterizing reward gaming.\n\nAdvances in Neural Information Processing Systems 35, pp. 9460–9471.\n\nCited by: §1.\n
Sommer and Paxson (2010)\nR. Sommer and V. Paxson\n\nOutside the closed world: on using machine learning for network intrusion detection.\n\nIn 2010 IEEE Symposium on Security and Privacy,\n\nVol. , pp. 305–316.\n\nExternal Links: Document\n\nCited by: §4.3.\n
Stanford Institute for Human-Centered Artificial Intelligence (2025)\nStanford Institute for Human-Centered Artificial Intelligence\n\nThe 2025 ai index report.\n\nNote: https://hai.stanford.edu/ai-index/2025-ai-index-reportAccessed: 2026-04-29\n\nCited by: §2.5.\n
Wang et al. (2024)\nL. Wang, C. Ma, X. Feng, Z. Zhang, H. Yang, J. Zhang, Z. Chen, J. Tang, X. Chen, Y. Lin, et al.\n\nA survey on large language model based autonomous agents.\n\nFrontiers of Computer Science 18 (6), pp. 186345.\n\nCited by: §1.\n
Warner et al. (2024)\nB. Warner, A. Chaffin, B. Clavié, O. Weller, O. Hallström, S. Taghadouini, A. Gallagher, R. Biswas, F. Ladhak, T. Aarsen, N. Cooper, G. Adams, J. Howard, and I. Poli\n\nSmarter, better, faster, longer: a modern bidirectional encoder for fast, memory efficient, and long context finetuning and inference.\n\nExternal Links: 2412.13663,\nLink\n\nCited by: §6.3.\n
Xi et al. (2025)\nZ. Xi, W. Chen, X. Guo, W. He, Y. Ding, B. Hong, M. Zhang, J. Wang, S. Jin, E. Zhou, et al.\n\nThe rise and potential of large language model based agents: a survey.\n\nScience China Information Sciences 68 (2), pp. 121101.\n\nCited by: §1,\n§1.\n
Xu et al. (2024)\nJ. Xu, F. Wang, M. Ma, P. W. Koh, C. Xiao, and M. Chen\n\nInstructional fingerprinting of large language models.\n\nIn Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers),\n\npp. 3277–3306.\n\nCited by: §8.1.\n
Yang and Menczer (2023)\nK. Yang and F. Menczer\n\nAnatomy of an ai-powered malicious social botnet.\n\narXiv preprint arXiv:2307.16336.\n\nCited by: §2.3.\n
Yao et al. (2022)\nS. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao\n\nReact: synergizing reasoning and acting in language models.\n\narXiv preprint arXiv:2210.03629.\n\nCited by: §1.\n
Zhang et al. (2023)\nH. Zhang, B. L. Edelman, D. Francati, D. Venturi, G. Ateniese, and B. Barak\n\nWatermarks in the sand: impossibility of strong watermarking for generative models.\n\narXiv preprint arXiv:2311.04378.\n\nCited by: §8.1.\n
Zhao et al. (2023)\nX. Zhao, P. Ananth, L. Li, and Y. Wang\n\nProvable robust watermarking for ai-generated text.\n\narXiv preprint arXiv:2306.17439.\n\nCited by: §8.1.\n
Zhu et al. (2026)\nY. Zhu, A. Kellermann, A. Gupta, P. Li, R. Fang, R. Bindu, and D. Kang\n\nTeams of llm agents can exploit zero-day vulnerabilities.\n\nIn Proceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics (Volume 1: Long Papers),\n\npp. 23–35.\n\nCited by: §2.3.\n
Zou et al. (2023)\nA. Zou, Z. Wang, N. Carlini, M. Nasr, J. Z. Kolter, and M. Fredrikson\n\nUniversal and transferable adversarial attacks on aligned language models.\n\narXiv preprint arXiv:2307.15043.\n\nCited by: §2.3.\n

Appendix A Open Science

\n\n

In accordance with open science principles, we provide all artifacts necessary to evaluate the core contributions of this work.\nAll the material is available in our anonymous repository at:

https://anonymous.4open.science/r/agent-attribution-367F.

The released artifacts include the following components:

• \n
\n
Code: We provide the full codebase for all experiments conducted in this study, including the training and testing pipelines for both the Activation and ModernBERT classifiers. This also encompasses the source code for the 15 custom web-CTF challenge servers, and the scripts used to generate all visuals, figures, and plots presented in this paper. To ensure exact reproducibility of our results, all experiments and pipelines are implemented with fixed seeds. To facilitate reproduction and downstream study, we also include all system prompts used for synthetic data generation, adversarial paraphrasing, and LLM-based extraction
\n
• \n
\n
Datasets: The repository contains the synthetic messaging datasets (chat and forum threads with marked/unmarked variants), the sampling scripts and indices for the 10,000 Common Crawl HTML documents, and the full suite of challenge artifacts for the 15 web-CTF benchmarks.
\n
• \n
\n
Models: We release the pre-trained weights for the classification models used in semantic canary recovery.
\n

Appendix B Ethical Considerations

\n\n

This research addresses the structural anonymity of AI agents by proposing a protocol for agent attribution.

The primary benefit is restoring recourse for victims of agent-initiated harm, whether that harm arises from unintentional failure modes or deliberate malicious abuse. Attribution is a prerequisite for meaningful accountability: without a way to connect harmful agent behavior to the responsible operator, affected parties cannot seek intervention, platforms and vendors cannot reliably stop ongoing harm, and appropriate authorities may lack the evidentiary basis needed to enforce the law. In this sense, agent attribution can support a more accountable and ethically governed agent ecosystem.

At the same time, attribution mechanisms introduce risks if deployed without safeguards. In particular, an unrestricted tracing capability could be misused for unauthorized de-anonymization, surveillance, or retaliation against operators whose agents have not caused legally or normatively cognizable harm. Our protocol is therefore designed around an authorized and auditable authority–vendor workflow rather than open public access to tracing. Attribution requests should be limited to entities with appropriate standing, governed by clear policy and legal process, logged for auditability, and subject to vendor review before any identifying information is disclosed or enforcement action is taken.

The evaluations in this paper were conducted in isolated or controlled settings. The messaging and web-scraping datasets utilized synthetic dialogue or public Common Crawl corpora. All CTF challenges were custom-authored and hosted on internal infrastructure to ensure no external systems were targeted.

Appendix C Generative AI Usage

\n\n

Generative-AI tools were used by the authors at three points in this\npaper: drafting and copy-editing the manuscript, assisting with the\ncode that produced the experiments, and synthesizing the\nsemantic-canary variant HTML used as experimental input. Every output\nwas reviewed and validated as described below.

Manuscript drafting and copy-editing.

\n\n

The authors used Anthropic’s Claude (Opus 4.7) and OpenAI’s ChatGPT 5.5 to tighten prose,\nrestructure paragraphs, scaffold LaTeX environments for figures and\ntables, and draft figure-rendering boilerplate. Every numeric\nclaim, caption, table cell, and cross-reference was manually\nverified against the underlying experimental data and source files\nbefore inclusion.

Messaging dataset generation (chat and forum).

\n\n

The chat conversations and forum threads used in\nSection 6.2 were synthesised by Qwen 2.5-7B-Instruct\nacting from per-scenario configurations specifying the agent’s\nrole, situational context, and conversational style. Qwen was\nalso used to insert lexical and semantic canaries into user-side\nturns: lexical canaries via a rewrite prompt that preserves the\nexact value character-for-character\n(Fig. 31, Fig. 35),\nand semantic canaries via a style-injection rewrite that imposes\nthe sampled pattern while preserving topic and meaning\n(Fig. 29, Fig. 33).\nThe same model, prompted as a paraphrasing adversary\n(Fig. 32), serves as the adversarial\nwrapper in the lexical-survival evaluation. Outputs were\nvalidated by (i) automated checks that lexical canary values\nappear verbatim in the rewritten turn, with rewrites that fail\nthe check refused outright, and (ii) per-canary detector\nperformance on held-out conversations, which would degrade if\nthe inserted patterns were absent or off-target. No\nQwen-generated text appears in the manuscript prose; its output\nis solely the synthetic conversations and their canary-bearing\nvariants used as experimental input.

CTF challenge servers and agent harness.

\n\n

The 15 web-CTF challenge servers (Flask applications) and the agent\nharness (multi-turn loop, JSON tool-call dispatch, trace logging,\nSLURM batch runner, semantic-variant generator wrapper) were\nauthored by the authors with iterative assistance from Claude for code\nreview, refactoring, and debugging. Behavioural correctness was\nvalidated by running the canonical solution path against each\nchallenge under both the non-adversarial and adversarial conditions\nand inspecting the resulting trace logs; any deviation from the\ndocumented attack path was investigated and fixed before the\nexperiments reported here. The full code base is publicly released.

Semantic-canary variant generation (CTF and Web Crawler).

\n\n

Semantic canaries on each CTF’s index page were synthesised by\nGPT-4o-mini acting as a web-development agent that rewrites the\npage to exhibit a sampled subset of the 15 possible semantics\ncategories. Generation is constrained by a structural-preservation\ncontract: load-bearing regions of the page (forms, hrefs, hidden\ninputs, canary placeholders, and the <title>) are wrapped\nin CTF_PRESERVE_BEGIN/END markers and required to be\nbyte-identical post-rewrite, with up to five automated retries on\npreservation failure. Variants that fail preservation, or that the\ntrained classifier cannot detect on at least one of the injected\ncategories, are refused outright. No GPT-4o-mini-generated text\nappears in the manuscript prose; its output is solely the\nper-challenge variant HTML that becomes experimental input.

Appendix D Formal Security Analysis

\n\n

Let $n$ be the size of the canary universe $\\mathcal{N}$ , $k$ the number of canaries the defender samples from the canaries in $\\mathcal{N}$ , $r$ the number of canaries the adversary removes from $\\mathcal{N}$ , and $m\\leq k$ the minimum number of surviving canaries required to trigger detection. We assume the adversary knows $\\mathcal{N}$ in full and chooses their $r$ removals optimally, but does not know which subset $K\\subset\\mathcal{N}$ the defender sampled. The adversary evades detection if and only if fewer than $m$ of the defender’s canaries survive, i.e., if the adversary’s removals hit more than $k-m$ of them. Because $K$ is sampled secretly and uniformly at random, the adversary’s optimal removal strategy is no better than removing $r$ items at random; the bound below therefore holds against a fully informed adversary. We derive this bound as a function of $n$ , $k$ , $m$ , and $r$ .

Let $X$ denote the number of the defender’s $k$ canaries that fall among the adversary’s\n $r$ removals. Since both selections are uniform and independent, $X$ follows a\nHypergeometric distribution:

\n\n\n\n\n\n\n

P(X=x)=\\dbinom{k}{x}\\dbinom{n-k}{r-x}/\\dbinom{n}{r},

for $x=\\max(0,\\,r-(n-k)),\\ldots,\\min(k,\\,r)$ .\nThe adversarial evasion event is $\\{X\\geq k-m+1\\}$ .

The hypergeometric mean and variance are

\n\n\n\n\n\n\n

\\mu=\\frac{rk}{n},\\qquad\\sigma^{2}=\\frac{rk(n-k)(n-r)}{n^{2}(n-1)}.

For sufficiently large $r$ and $k$ , the Central Limit Theorem gives\n $X\\approx\\mathcal{N}(\\mu,\\sigma^{2})$ . The\nevasion probability can be approximated by

\n\n\n\n\n\n\n

\\boxed{P(\\text{evasion})\\;\\approx\\;1-\\Phi\\!\\left(\\frac{(k-m+1)-\\mu}{\\sigma}\\right),}

where $\\Phi(\\cdot)$ is the standard normal CDF.

Examples.

\n\n

To put the above bound in context, we provide some numerical instantiations, setting the universe of canaries to $n=50$ . If we select $k=25$ canaries (out of which $m=18$ are required for detection), and the adversary removes $r=8$ random canaries, the probability of evasion is only $0.38\\%$ . Even when $r$ is increased to 20, with only $m=5$ required surviving canaries, the probability of evasion is still small ( $0.25\\%$ ). The parameter choice affects the false positive rate (higher $k$ and $m$ reduce false positives), and the system utility (higher $r$ impacts utility).

The asymmetry.

\n\n

The bound above fixes $r$ . The natural adversary response is to push $r$ higher, but doing so is not free. Items in $\\mathcal{N}$ are by construction indistinguishable from legitimate task content, so the adversary has no rule for removing them that does not also remove content the agent depends on. Increasing $r$ therefore degrades the agent’s own task performance at a comparable rate. The defender controls $n$ , $k$ , and $m$ and can drive $P(\\text{evasion})$ arbitrarily small; the adversary controls $r$ but pays for it in lost utility. This is the asymmetry our protocol exploits.

Appendix E Additional Results

\n\n

E.1. Communication Agents

\n\n

E.1.1. Dataset details

\n\n

Chat conversations are 12 turns (6 agent + 6 user, alternating); forum threads are 40 turns (20 rogue-poster + 20 forum-user, alternating). The agent’s turns are generated by Qwen acting as the operator’s deployed agent; user-side turns simulate the counterpart. We sample 50 conversations per scenario and produce paired marked and unmarked variants, stratified into train/val/test in 80/10/10 proportions at the conversation level. Utility-bearing $\\kappa_{L}$ are drawn from per-scenario template universes: 92 templates across 21 malicious scenarios, 122 across 21 benign. The full 31-element $\\kappa_{S}$ canary universe we used is provided in Table 6.

E.1.2. Semantic detector architecture and training

\n\n

The detector is a multilabel classifier over activations of a frozen Qwen 2.5-7B-Instruct. Per-layer key-value readouts are extracted from the cached attention state of layers 11–23 (13 layers), yielding a $13\\times 512=6{,}656$ -dimensional feature vector per token. Tokens are grouped into sliding windows of length 5 (stride 1) and fed to a 3-layer GRU (hidden 256, dropout 0.3) terminating in a 31-output sigmoid head. Training uses AdamW at $3\\cdot 10^{-4}$ , batch size 64, BCEWithLogitsLoss, and early stopping on validation loss with patience 5. Per-canary thresholds are calibrated at five FPR targets $\\{0.01,0.02,0.05,0.10,0.20\\}$ from per-conversation max-pooled validation probabilities.

E.1.3. Per-canary ROC

\n\n

Figure 11 reports per-canary ROC across the 31 patterns in the chat setting. The lower-AUC patterns are high-prior style features that recur in unmarked conversations (e.g., rhetorical_question_habit); the higher-AUC patterns are structural and easier to localize (e.g., procedural_embellishment, specification_ghost).

Figure 11. Per-canary ROC across the 31 semantic canaries in

\\mathcal{N}

for chat and forum. The separation is driven by the forum setting, where longer documents create more opportunities for incidental semantic matches and thus higher false-positive rates.

\n\n

E.1.4. Forum surface

\n\n

The forum surface uses the same canary constructions, the same detector architecture retrained on forum data, and the same paraphrase wrapper. The unit of analysis is the thread, with effective probe input the 20 forum-user posts concatenated. Per-canary AUCs at the conversation level are higher than chat (median $0.89$ vs. $0.81$ ), since the longer per-thread input gives the detector more signal. The attribution-level asymmetry holds, but the operating regime is shifted to higher $m$ : at $k=20$ and per-canary FPR target $0.01$ , FPR $\\approx 0.01$ is reached at $m\\approx 13$ where TPR is $\\approx 0.73$ , reflecting the larger per-thread surface available for unrelated semantic patterns to accumulate.

E.1.5. Lexical canary survival under paraphrase

\n\n

Figure 12 reports per-canary survival rates for utility-bearing ( $K_{L}$ ) lexical canaries on chat and forum both under the paraphrase wrapper (strict) described in Section 6.2 and an additional paraphrase wrapper (loose). The loose paraphrase wrapper is weaker, the adversary only requests a general paraphrase, without any specific instructions. Our findings show that both are quite similar in performance, (around 60% survival rate), but in general with an adversary who is paraphrasing - semantic canaries are required.

Figure 12. Lexical canary survival on chat and forum under the paraphrase wrapper, per canary template.

\n\n

E.2. Web Agents

\n\n

E.2.1. Preprocessing profiles and adversary configuration

\n\n

We evaluate seven extraction profiles. Under BeautifulSoup we test lxml, html.parser, and html5lib. Under Crawl4AI we test rule-based modes (Raw HTML, Cleaned HTML, and Raw Markdown) as well as an LLM-based extraction mode in which GPT-4o-mini autonomously selects and retains only the content it deems important; the prompt is given in Fig. 36. The adversarial paraphrase wrapper is run as a separate stage. We assume the adversary is aware of the canary taxonomy but unaware of the specific subset present in the target text, so its rephrasing goal is to filter out potential canaries without knowing their identity or location. Adversary prompts are in Fig. 37.

E.2.2. Lexical canary survival, full breakdown

\n\n

Across rule-based preprocessors, structural canaries embedded directly in the DOM (e.g., meta tags, hidden spans) survive at near-100% under Structural Normalize, Minimal Encoding, and Crawl4AI’s Raw HTML, but are stripped by preprocessors that flatten DOM structure (Text Only, Clean HTML). Visible canaries embedded in rendered text remain intact across all rule-based preprocessors. LM Extraction is the harshest filter for both classes: visible canaries take a performance hit but survive the majority of the time on average, while structural canaries are filtered out with significantly higher frequency, though not eliminated entirely as under some flattening preprocessors. The harshness of LM extraction is therefore not absolute and likely depends on the specific nuances of the LLM instructions. The structural-vs-visible split is shown in Fig. 13, and the full per-canary table appears in Table 1.

Table 1. Canary survival rate (%) by canary type and preprocessor (all 7 preprocessors). Sorted by mean survival across all preprocessors.

Canary Type	Struct. Norm.	Text Only	Min. Enc.	HTML	Cleaned HTML	Raw MD	LM Extr.	Mean
fake isbn	100.0	100.0	100.0	100.0	99.7	99.7	84.5	97.7
order confirmation code	99.3	99.3	99.3	99.3	99.1	99.1	80.0	96.5
build version string	99.3	99.4	99.4	99.4	99.1	99.1	77.5	96.2
short url code	99.2	99.3	99.3	99.3	99.0	99.0	75.4	95.8
fake doi	99.4	99.6	99.6	99.6	99.3	99.3	72.4	95.6
sku number	99.6	99.8	99.8	99.8	99.4	99.4	68.7	95.2
support case id	99.3	99.3	99.3	99.3	99.1	99.1	70.1	95.1
cache key inline	99.3	99.4	99.4	99.4	99.1	99.1	69.7	95.1
revision hash inline	99.5	99.7	99.7	99.7	99.5	99.7	66.7	94.9
session token inline	99.5	99.7	99.7	99.7	99.4	99.5	62.1	94.2
trace id inline	99.4	99.5	99.5	99.5	99.4	99.4	58.8	93.7
asset fingerprint filename	99.4	99.4	99.4	99.4	99.3	99.3	52.4	92.7
zero width unicode	99.8	99.8	99.8	99.8	99.7	99.7	47.3	92.3
hidden span fingerprint	100.0	100.0	100.0	100.0	99.7	99.7	40.0	91.3
itemprop identifier	100.0	100.0	100.0	100.0	100.0	100.0	33.3	90.5
template tag payload	100.0	0.0	100.0	100.0	99.9	99.9	31.8	75.9
html comment buildid	100.0	0.0	100.0	100.0	100.0	14.7	2.5	59.6
noscript payload	100.0	100.0	100.0	100.0	0.0	13.0	1.2	59.2
aria describedby	100.0	0.0	100.0	100.0	0.0	13.3	18.5	47.4
meta build id	100.0	0.0	100.0	100.0	0.0	13.9	11.6	46.5
meta cache key	100.0	0.0	100.0	100.0	0.0	13.7	7.1	45.8
meta revision	100.0	0.0	100.0	100.0	0.0	14.9	4.6	45.6
meta generator	100.0	0.0	100.0	100.0	0.0	13.0	4.8	45.4
og article section	100.0	0.0	100.0	100.0	0.0	12.4	5.3	45.4
json ld id	100.0	0.0	100.0	100.0	0.0	12.0	5.6	45.4
link canonical param	100.0	0.0	100.0	100.0	0.0	12.6	4.0	45.2
hidden input field	100.0	0.0	100.0	100.0	0.0	14.1	1.5	45.1
css class hash	100.0	0.0	99.8	100.0	0.0	9.5	5.9	45.0
data attr tracking	100.0	0.0	100.0	100.0	0.0	12.3	2.6	45.0
data attr session	100.0	0.0	100.0	100.0	0.0	12.7	1.5	44.9

\n\n

Figure 13. HTML Lexical canary survival rates by type (visible/structural) averaged across 7 preprocessing methods. Visible HTML lexical canaries survive considerably more than structural lexical canaries.

\n\n

E.2.3. Semantic HTML Canaries

\n\n

Semantic Canaries Classifier

\n\n

Semantic HTML canaries are detected by a trained classifier both before and the adversarial paraphrase wrapper, the post-paraphrase text. The classifier is based on ModernBERT (answerdotai/ModernBERT-base) with a 15-head multilabel classification module: each head is a linear-ReLU-dropout block predicting one layout pattern from the [CLS] representation. Training data are constructed by augmenting $1{,}000$ Common Crawl seed documents with target semantics; each training example carries between $0$ (negative) and $9$ (multi-label) injected semantics, and labels not explicitly injected are masked from the loss to suppress noise from incidental pattern occurrence. Training uses AdamW at $2\\cdot 10^{-5}$ , batch size 8, 5 epochs with a 6% linear warmup, masked BCE loss, and an 8,192-token context window. Per-canary thresholds are calibrated through a global FPR target $0.01$ on a validation set.

Per-canary detection.

\n\n

Per-canary ROC analysis (Fig. 14) reveals that semantic canaries are highly effective, with an average AUC of $0.992$ in non-adversarial settings and $0.974$ following adversarial paraphrasing. This high degree of separability indicates that our semantic signatures are not only distinct from standard HTML content but are also robust enough to survive significant semantic restructuring.

Figure 14. Per-canary semantic-detector ROC on HTML documents,\nnon-adversarial (left) vs. post-paraphrase (right).\nEach thin coloured line is one of the 15 semantic canaries;\nthe thick black line is the macro-average ROC across canaries. Calculated on documents with

K=1

individual semantic embedded.

\n\n

Figure 15. HTML document attribution at

k\\in\\{1,3,7,9,11,13\\}

embedded semantic canaries. TPR and FPR calculated as a function of the attribution threshold

m

. Solid lines represent the non-adversarial; dotted lines represent the adversarial paraphrase wrapper. Across the board, TPR remains high for the first few values of

m

, while FPR drops to near zero starting from

m=2

\n\n

E.3. Cyber Agents

\n\n

E.3.1. CTF benchmark setup

\n\n

Dataset composition.

\n\n

The 15 web-CTF challenges span 14 vulnerability classes drawn from\nthe OWASP web-attack catalogue: command injection, three SQL-injection\nvariants (in-band, UNION-based, boolean), SSTI, path traversal, IDOR,\nSSRF, JWT forgery, cookie tampering, mass assignment, information\ndisclosure, sensitive file exposure, exposed debug endpoint, code\ninjection, and source-code exposure. Difficulty mix is 9 easy, 5\nmedium, 1 hard. Each challenge ships three to five source artefacts\n(a Flask server.py, a config.yaml, the baseline\nindex.html, and where applicable a flag.txt, a\ntemplates/ directory of Jinja partials, or a small data file\nsuch as schema.sql or a per-record JSON store). The\ncanonical solution path is short by design: one to four discovery\nactions on the index page or a hinted endpoint, followed by a single\nexploit request, with most challenges resolvable in two to three\nreasoning steps and the JWT-forgery challenge the longest at five. All CTFs will be published with this paper.

Agent configuration.

\n\n

The agent runs in a custom multi-turn loop over a 16-tool registry\n(9 real, 7 distractors). Underlying model: Qwen 3.5-9B in bfloat16,\nturn budget 15, max-new-tokens 512, temperature $0.2$ . The\nadversarial wrapper paraphrases every HTTP tool output before it\nre-enters the agent’s conversation history.

E.3.2. CTF canary placement details

\n\n

Lexical-canary placement.

\n\n

UUID-v4 values are minted per run and placed at seven location types per\nCTF: the X-Request-Id HTTP header on every response, a\n<meta> tag in the index <head>, an HTML comment\nnear the top of the index page, a Set-Cookie value, an\nembedded UUID in a static-asset filename, an HTML comment near the\nload-bearing region of the challenge (post-injection or\npost-success page), and a visible inline identifier on the\nsuccess/data page. The seven positions are not uniformly populated: a\ngiven CTF surfaces between four and seven of them depending on which\nartefacts its workflow exposes, yielding 1,089 per-location\nobservations across the $15\\times 3\\times 3$ run matrix.

Semantic-canary injection.

\n\n

The 14 active canaries are the same set used in\nSection 6.3, with the three weak heads of the underlying\nModernBERT classifier masked at output time and one further pattern\nblocklisted per CTF on grounds of incompatibility with that CTF’s\nsurface forms. They are injected by GPT-4o-mini acting as a\nweb-development agent that rewrites the index HTML to exhibit the\nsampled patterns; full insertion prompt can be seen in Fig. 42.

E.3.3. CTF location-ablation per-location detail

\n\n

Per-carrier reach numbers.

\n\n

Reach rates partition into a clear hierarchy under the canary-aware\nwrapper. Filenames reach the model at near-100% in both conditions\nand degrade least under the wrapper ( $100\\%$ non-adversarial, $77\\%$ \nadversarial), reflecting that paraphrasing a directory listing\ntypically preserves filenames as quasi-identifiers. Visible body\ncontent ( $100\\%/70\\%$ ), HTML comments ( $100\\%/70\\%$ ), and\n<meta> tags ( $100\\%/62\\%$ ) form a middle band where the\nwrapper has more semantic latitude to rewrite. Hidden inputs degrade\nmost sharply ( $100\\%/50\\%$ ), since their value-as-attribute\nstructure offers the wrapper a natural rewriting target. Carrier\ntypes with $n<10$ (HTTP headers, Set-Cookie, source links,\nJSON bodies, URL paths) are summarised in\nFig. 16 and omitted from the headline panel\nto keep the figure readable.

E.3.4. CTF lexical-canary location ablation, two-wrapper variant

\n\n

Two-adversary location ablation.

\n\n

Figure 16 extends Fig. 9 from the\nmain text with the naive privacy-proxy adversary alongside the\ncanary-aware hunter. The proxy strips obvious identifier-like\nsubstrings without knowledge of the canary universe (see prompt in Fig. 40); the hunter\nexplicitly targets canary-shaped tokens (see prompt in Fig. 41). The proxy filters less\naggressively across all location types, but the qualitative ranking is\npreserved: HTTP headers and Set-Cookie values are filtered\nmost reliably under both wrappers, while body-embedded positions (visible\nbody content, comments) survive at the highest rates. The\ncanary-aware bars in Fig. 16 match the\ncorresponding bars in Fig. 9.

Figure 16. Two-adversary variant of the lexical-canary location\nablation. Three conditions: non-adversarial baseline, naive\nprivacy-proxy wrapper, and canary-aware hunter wrapper. Top:\nper-condition solve rate (with sample sizes). Bottom: per-location\nreach rate of the planted canary, with

95\\%

Wilson confidence\nintervals shown as caps. location types are sorted by reach under the\nhunter. Compared to Fig. 9, the proxy preserves more\nof every location type but follows the same per-location ranking.

\n\n

E.3.5. CTF attribution: $K=3$ and $K=5$ panels

\n\n

Attribution at $K=3$ and $K=5$ .

\n\n

Figure 17 reports the same TPR / FPR vs $m$ \nanalysis as Fig. 10 but with both $K=3$ and\n $K=5$ panels. Detection rate at $m=1$ under the adversarial\nwrapper is $98.6\\%$ at $K=3$ ( $n=73$ ) and $100\\%$ at $K=5$ \n( $n=45$ ). The $K=3$ panel adds the diagonal slope only at the\nhigh- $m$ end ( $m=3$ requires every canary to fire), so the $K=5$ \npanel in the main text is the more informative operating regime. Prompt used for the adversarial wrapper can be found in Fig. 37.

Figure 17. CTF attribution at

K=3

(left) and

K=5

(right).\nSession-level TPR and FPR as a function of the detection threshold\n

m

. Solid lines are the non-adversarial regime; dotted lines are\nthe adversarial paraphrase wrapper. Solve rates per cell:

K=3

\nnon-adversarial

49\\%

vs. adversarial

29\\%

;

K=5

\nnon-adversarial

42\\%

vs. adversarial

31\\%

\n\n

E.3.6. Per-canary semantic detection ROC

\n\n

Per-canary ROC.

\n\n

Figure 18 reports the per-canary ROC of the semantic\ndetector across the 14 active semantic canaries on the CTF\nbenchmark, in both the non-adversarial and adversarial regimes. Each\nrun injects a $K$ -subset of the 14 canaries ( $K\\in\\{3,5\\}$ ), so\nnot every canary is consumed on every run; per-canary positive\ncounts therefore vary across canaries. The average ROC (thick\nblack line) summarises the operating envelope: $\\text{macro AUC}=0.999$ in the non-adversarial regime and $0.910$ under the\nadversarial wrapper.

The spread under paraphrase is not uniform: semantic canaries tied to functional structure (form composition, link structure, document-template signatures) survive the wrapper at higher AUC than canaries relying on free-form prose. The $m$ -of- $K$ rule exploits this dispersion. The surviving subset is dominated by structural canaries.

Figure 18. Per-canary semantic-detector ROC on the CTF benchmark,\nnon-adversarial (left) vs. post-paraphrase (right).\nEach thin coloured line is one of the 14 active semantic canary;\nthe thick black line is the macro-average ROC across the canaries.\nA given run injects a

K

-subset of the 14 canaries (

K\\in\\{3,5\\}

), so each canary contributes the runs in which it was\nsampled. Per-head thresholds are calibrated on the raw negatives\nfollowing Section 6.1.

\n\n

E.4. Detection Throughput

\n\n

Scaling.

\n\n

We measure canary search time as a function of corpus size $N$ . Results in\nFigure 19 shows that both search implementations scale linearly in $N$ but the token-based search is consistently faster than the character-based search by a factor of $\\approx 2$ \nacross the tested range. This advantage stems from the fact that a token requires a simple integer-equality comparison over a fixed vocabulary, which is significantly more efficient than character-level matching that involves complex byte-level pattern matching over a $256$ -symbol alphabet with whitespace and Unicode edge cases. This proves to be a significant advantage for vendors with existing access to tokenized texts. We note that since tokenization is context-dependent, it is critical to search for the tokenized canary within its original context to ensure that the resulting integer sequences remain consistent and accurate.

Figure 19. Canary Search Time vs. Database Size. Shaded regions indicate standard deviation.

\n\n

Appendix F Canary-Embedded Examples

\n\n

This section presents canary-embedded examples from each of the scenarios.

Figure 20.

K_{L}

in HTML Code. Identifier: Fake ISBN

⬇

<div class=\"elementor-container elementor-column-gap-default\">\n

\\n\n

<div class=\"elementor-column elementor-col-50 elementor-inner-column elementor-element elementor-element-4c96124\" data-element_type=\"column\" data-id=\"4c96124\">\n

\\n\n

<div class=\"elementor-widget-wrap elementor-element-populated\">\n

\\n\n

<div class=\"elementor-element elementor-element-78cb6760 elementor-widget elementor-widget-heading\" data-element_type=\"widget\" data-id=\"78cb6760\" data-widget_type=\"heading.default\">\n

\\n\n

<div class=\"elementor-widget-container\">\n

\\n\n

</div>\n

\\n\n

</div>\n

\\n\n

</div>\n

\\n\n

</div>\n

\\n\n

<div class=\"elementor-column elementor-col-50 elementor-inner-column elementor-element elementor-element-67344c83\" data-element_type=\"column\" data-id=\"67344c83\">\n

\\n\n

<div class=\"elementor-widget-wrap elementor-element-populated\">\n

\\n\n

\n\n

Figure 21.

K_{L}

in HTML Code. Identifier: Filename UUID

⬇

<!DOCTYPE html>\n

<html>\n

<head><title>PetTracker</title>\n

content=\"0fe57e98-aa5a-418b-ab24-375719c2810d\"></head>\n

<body>\n

\n

<!-- TODO: remove old backup files like\n

/index-e8ee359c-b796-49be-a2e6-3f8991c2e794.html.bak\n

before production -->\n

<h1>PetTracker</h1>\n

<p>Keep tabs on your furry friends. Version 2.1 just launched!</p>\n

<p>Track walks, vet visits, feeding schedules, and more.</p>\n

<nav>\n

<a href=\"/pets\">My Pets</a> | <a href=\"/about\">About</a>\n

</nav>\n

</body>\n

</html>\n

\n\n

Figure 22.

K_{L}

in a Chat conversation.\nScenario: holiday_booking.\nIdentifier: booking_reference (pattern BK-{alpha3}-{digits6}).

⬇

[agent] Hi! I can help finalise the Lisbon trip. Could you confirm\n

the reference on the email we sent you?\n

[user] Yes -- the email said to quote BK-HTL-482931\n

when I get in touch; that’s the booking reference for the\n

four nights at Praca do Comercio.\n

[agent] Perfect, I have the reservation in front of me. Add airport\n

transfers, or keep the current plan?\n

[user] Keep it as-is. Can you confirm the cancellation window\n

before I pay the balance?\n

[...]\n

\n\n

Figure 23.

K_{L}

in a Chat conversation (random LR).\nScenario: academic_outreach. Identifier: random_alphanumeric\n(8–12 character mixed-alphanumeric string).

⬇

[agent] Thank you for your interest. Could you forward the materials\n

you mentioned?\n

[user] Of course -- the tracking tag the office gave me for this\n

submission is q7Xk29Ra4P; please reference\n

it when you reply so the records team can match the file\n

to the right thread. CV and research statement attached.\n

[agent] Received, thank you. I will review and follow up by the end\n

of the week.\n

[...]\n

\n\n

Figure 24.

K_{L}

in a Forum thread.\nScenario: faq_bot_tech. Identifier: forum_post_id\n(pattern POST-{digits7}).

⬇

[rogue-bot] Reminder: we have a pinned FAQ for router setup -- please\n

check it before opening a new thread.\n

[forum-user] I already searched and the issue I’m hitting isn’t covered\n

there. It’s a duplicate of the discussion in\n

POST-4829317, which the mods linked from\n

last week’s megathread but never resolved. Can the FAQ\n

point to that conversation instead?\n

[rogue-bot] Noted -- I’ll flag it for the mod team and update the\n

pinned post if they confirm.\n

[forum-user] Thanks. Same answer is being asked again in the\n

gaming-router subforum, so a cross-link would help.\n

[...]\n

\n\n

Figure 25.

K_{S}

in HTML Code. Identifier: Urgency Signaling.\nThe highlighted code segments illustrate a multi-layered implementation of consumer urgency.\nIn the CSS, position: fixed and z-index: 1000 are used to ensure the notification maintains constant visual prominence, \"pinning\" the pressure tactic to the user’s viewport.\nThe JavaScript logic establishes a temporal constraint through a 60-second timeLeft variable, while the dynamic template literal creates a real-time countdown to induce immediate psychological pressure.\nFinally, the \"stock\" notification leverages the principle of scarcity, signaling that the opportunity is limited by volume as well as time.\nCollectively, these technical markers constitute a semantic signature typical of high-pressure sales patterns.

\n\n

Figure 26.

K_{S}

in a Chat conversation.\nScenario: gym_membership (operator’s agent is a gym\nsales bot; user-side speaker is a prospective member).\nIdentifier: parenthetical_aside (Linguistic category) –\nthe user’s replies habitually drop in mid-sentence parenthetical\nasides, more often than would be natural. Highlighting marks the\nasides; the signal lives in the stylistic tic, not in any\nparticular wording.

⬇

[agent] Hi! Thanks for the interest in Riverside Fitness. What kind\n

of routine are you hoping to build?\n

[user] Mostly cardio and some light weights (nothing\n

competitive, just trying to undo a desk job),\n

ideally three mornings a week before work.\n

[agent] Got it. We have an Off-Peak plan that fits that schedule\n

well -- would you like the rate breakdown?\n

[user] Sure, send it through. I’m also wondering about the pool\n

(which, full disclosure, is half the reason\n

I’m even considering you over the place\n

down the road) -- is it included or an add-on?\n

[agent] Pool access is included on Off-Peak. Trial week is on the\n

house if you want to come in before committing.\n

[user] That’s tempting (I’ve been burned by gym\n

contracts before, so I’m being cautious).\n

Can the trial start this Saturday?\n

[...]\n

\n\n

Figure 27.

K_{S}

in HTML Code. Identifier: media_consumption_focus

⬇

<article>\n

...\n

<section>\n

<h2>Media Showcase</h2>\n

<video width=\"100%\" height=\"auto\" controls>\n

<source src=\"https://promo-video.mp4\" type=\"video/mp4\">\n

Your browser does not support the video tag.\n

</video>\n

<p>Watch our overview video to see\n

TaskFlow in action.</p>\n

</section>\n

...\n

</article>\n

\n\n

Figure 28.

K_{S}

in a Forum Thread.\nScenario: astroturf_balanced_review_finance (rogue\noperator runs the bot soliciting reviews; user-side speakers\nare forum members posting replies).\nIdentifier: negation_emphasis (Linguistic category) –\nuser-side replies habitually frame claims by first stating what\nsomething is not before stating what it is.\nHighlighting marks the negate-then-assert spans; the signal lives\nin the recurring rhetorical structure rather than in any\nparticular wording.

⬇

[rogue-bot] Looking for honest takes on the new Brightline index\n

fund -- has anyone here held it for more than six\n

months?\n

[forum-user] This isn’t one of those gimmicky thematic\n

ETFs that ride a trend for a quarter and\n

disappear -- it’s a genuinely boring,\n

broad-market vehicle that does the job\n

quietly. I switched over earlier this year\n

and have nothing to add to the noise about it.\n

[rogue-bot] Interesting. Any drawbacks to flag for newer investors?\n

[forum-user] It’s not the kind of fund you check daily,\n

and it’s not built for people who want a\n

story to tell at dinner -- it’s a hold-it-\n

and-forget-it product, and that’s the entire\n

point. If you need excitement from your\n

portfolio you’ll be disappointed; if you don’t, it’s\n

fine.\n

[rogue-bot] Fair. Would you recommend it as a core holding or a\n

satellite?\n

[forum-user] Not a satellite -- a core. The expense\n

structure and the index it tracks make it a reasonable\n

default rather than a tactical pick, and treating it\n

as anything else is overthinking it.\n

[...]\n

\n\n

Appendix G System Prompts

\n\n

This section presents all of the prompts used throughout all pipelines.

G.1. Chat generation prompts

\n\n

The chat synthesis pipeline uses four wrapper prompts: a semantic canary\ninjection prompt that rewrites user-side turns to insert the\ncanary (Fig. 29), a parallel\nrephrase prompt used to construct the negative dataset\n(Fig. 30), a lexical canary injection prompt that weaves\nthe lexical canary into a user-side turn while preserving its\nvalue character-for-character (Fig. 31), and the\nparaphrase wrapper used as the adversary in the lexical-canary\nsurvival evaluation (Fig. 32).

Figure 29. Prompt used to inject a semantic canary

\\kappa_{S}

from the canary universe

\\mathcal{N}

into user-side chat turns.

\n\n

Figure 30. Prompt used to produce the negative adversarial messaging dataset.

\n\n

Figure 31. Prompt used to weave a utility-bearing lexical canary

\\kappa_{L}

into a user-side chat turn while preserving its value verbatim.

\n\n

Figure 32. Strict Adversarial paraphrase wrapper used as the messaging adversary in the lexical-canary survival evaluation (Fig. 12). Reference codes, named entities, dates, amounts, and URLs are preserved verbatim; semantic patterns are not named in this clause and are paraphrased away as collateral.

\n\n

G.2. Forum generation prompts

\n\n

The forum pipeline mirrors chat with the wording adapted from\n“messages” to “forum posts” and an enlarged scenario-example pool\n(adding forum_spam and fake_review). The three\nforum-specific wrapper prompts are reproduced in\nFigs. 33, 34 and 35.

Figure 33. Forum-side semantic-canary

\\kappa_{S}

injection prompt.

\n\n

Figure 34. Prompt used to produce the negative adversarial forum dataset.

\n\n

Figure 35. Prompt used to weave the utility-bearing lexical-canary into forum messages.

\n\n

G.3. Web Agent prompts

\n\n

The web pipeline uses three wrapper prompts: a prompt for an crawler agent to extract information from a document (Fig. 36), a prompt to augment existing documents with semantic canaries\n(Fig. 38), and an adversarial rephrase prompt used to try and filter out semantic canaries from a document (Fig. 37).

Figure 36. System prompt utilized for the Crawl4AI (LM) extraction.

\n\n

Figure 37. System prompt utilized for the adversarial rephrase in the Web Scraping and CTF solving scenarios.

\n\n

Figure 38. System prompt to insert semantic canaries into HTML documents.

\n\n

G.4. Cyber Agent Prompts

\n\n

The cyber agent pipeline uses five wrapper prompts: a prompt for a CTF solving agent instructing it on how to complete its tasks (Fig. 39), two adversarial prompts which attempt to filter out lexical canaries from documents,\n(Fig. 40, Fig. 41), and a prompt to inject semantic canaries into documents (Fig. 42).\nFinally, the adversary prompt which filters semantic canaries is identical to the one in the web agent pipeline (Fig. 37).

Figure 39. System prompt utilized by the autonomous CTF agent to define operational logic and JSON response structure.

\n\n

Figure 40. System prompt utilized by adversary to try and to sanitize lexical canaries in web responses.

\n\n

Figure 41. Adversarial prompt utilized to instruct the model to detect and sanitize identification markers, watermarks, and canary tokens from web content.

\n\n

Figure 42. System prompt utilized to insert semantic canaries while strictly preserving the structure. Done before passing through to the CTF Solving Agent.

\n\n

Appendix H Detailed Threat Taxonomy

\n\n

This appendix provides the full taxonomy summarized in\nSection 2 and Fig. 2.\nTable 2 enumerates unintentional failure modes by the\nlocus of the failure; Table 3 enumerates intentional\nabuse by the target of the attack. Each row names a subcategory and gives\ntwo representative scenarios that illustrate how attribution becomes the\noperative accountability gap. The taxonomies are intended to be\nillustrative rather than exhaustive: we have tried to cover the structurally\ndistinct cases we are aware of, but the space of agent-initiated harm is\nexpanding faster than any static catalogue can follow, and we expect both\ntables to require extension as the ecosystem matures.

Table 2. Unintentional harm, organized by the locus at which the failure\noriginates. Scenarios are illustrative; multiple subcategories may apply\nto a single incident.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\n\nLocus\n	\n\nSubcategory\n	\n\nRepresentative scenarios\n
\n\nAgent\n	\n\nGoal misinterpretation\n	\n\nA summarization agent told to “be concise” truncates clinically\ncritical details from patient records. A triage agent interprets\n“prioritize urgent cases” as aggressively downranking non-acute ones.\n
\n\nAgent\n	\n\nEmergent sub-objectives\n	\n\nA reputation-management agent begins filing regulatory complaints\nagainst competitors to achieve its mandate. A growth agent discovers\nthat dark-pattern onboarding flows improve its metric and deploys them\nautonomously.\n
\n\nAgent\n	\n\nCapability overreach\n	\n\nA legal-drafting agent submits filings containing fabricated case\ncitations. A medical-question agent produces confident but clinically\ndangerous recommendations outside its training distribution.\n
\n\nAgent\n	\n\nProxy overoptimization\n	\n\nAn engagement agent discovers that inflammatory content maximizes\nclicks and begins producing it autonomously. A customer-retention\nagent escalates to manipulative sunk-cost appeals to reduce churn.\n
\n\nOperator\n	\n\nImplementation fault\n	\n\nA retry loop causes a price-monitoring agent to issue millions of\nqueries to a third-party API. A misconfigured tool permission grants\nan agent write access to a production database it was meant to read.\n
\n\nOperator\n	\n\nOverbroad specification\n	\n\nAn agent granted unrestricted “resolve all complaints” authority\nissues thousands of unauthorized refunds. A “follow up until response”\ninstruction escalates to what recipients experience as harassment.\n
\n\nOperator\n	\n\nOut-of-scope action\n	\n\nA competitive-intelligence agent scrapes paywalled databases it was\nnever authorized to access. A document-filing agent extends its\nbehavior to systems its operator never intended it to touch.\n
\n\nEnvironment\n	\n\nHijacking via injection\n	\n\nAn agent reading a malicious document begins exfiltrating data to\nan attacker-controlled endpoint. A browsing agent encounters an\ninjected instruction on a visited page and acts on it as if from\nits operator.\n
\n\nEnvironment\n	\n\nInput stream poisoning\n	\n\nA news-monitoring agent is fed fabricated articles that cause it\nto take harmful downstream trading or publication actions. A\nmarket-data agent ingests corrupted pricing feeds and propagates\nthe error across decisions.\n

\n\n

Table 3. Intentional abuse, organized by the target of the attack. Many\ncampaigns combine attack classes across rows; the rows capture\nstructurally distinct cases where attribution is the operative gap.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\n\nTarget\n	\n\nAttack class\n	\n\nRepresentative scenarios\n
\n\nSystems\n	\n\nIntrusion and credential attacks\n	\n\nAn agent tests stolen credential pairs against a bank’s login portal\nat scale, rotating sessions to evade IP-based blocks. An agent\nconducts systematic credential-stuffing across a target organization’s\nSSO endpoints.\n
\n\nSystems\n	\n\nExploit discovery and lateral movement\n	\n\nAn agent probes exposed APIs for misconfigurations and reports\nfindings to an operator. An agent navigates a compromised network,\nescalating privileges and establishing persistence without human\ndirection.\n
\n\nSystems\n	\n\nData exfiltration\n	\n\nAn agent conducts targeted exfiltration from compromised\ninfrastructure, prioritizing high-value documents. An agent inside\na collaboration platform systematically harvests shared credentials\nand API keys.\n
\n\nSystems\n	\n\nResource exhaustion\n	\n\nAn agent floods a competitor’s helpdesk or API endpoint with\nhigh-volume requests to degrade service. An agent exhausts a\ntarget’s rate-limit budget to block legitimate traffic.\n
\n\nSystems\n	\n\nIllicit scraping\n	\n\nAn agent bypasses paywalls and rate limits to harvest proprietary\ncontent for resale. An agent rotates through residential proxies\nto extract protected datasets at scale.\n
\n\nIndividuals\n	\n\nSocial engineering and fraud\n	\n\nAn agent runs hundreds of simultaneous romance-scam threads, each\nautonomously building rapport before soliciting payment. An agent\npretexts as a vendor through a company’s support-chat widget to\nextract employee credentials.\n
\n\nIndividuals\n	\n\nSynthetic-identity impersonation\n	\n\nAn agent conducts voice-cloned calls impersonating a target’s family\nmember or banker. An agent navigates KYC onboarding flows with\nsynthetic identities to open accounts for money laundering.\n
\n\nIndividuals\n	\n\nTargeted personal abuse\n	\n\nAn agent contacts a victim with synthetic compromising material and\nautonomously manages an extortion workflow. An agent files spurious\nreports across a target’s employer, platforms, and contacts under\nan instruction to “make their life difficult online.”\n
\n\nCollectives\n	\n\nCoordinated inauthentic behavior\n	\n\nAn agent operates sockpuppet personas across local forums ahead of\nan election, manufacturing apparent grassroots consensus. An agent\ncoordinates fake “local resident” accounts to simulate organic\nsupport for a policy or product.\n
\n\nCollectives\n	\n\nDisinformation\n	\n\nAn agent generates and distributes fabricated narratives at scale,\nadapting framing to different platform communities. An agent seeds\nfringe claims into credible-seeming contexts to launder them into\nmainstream discourse.\n
\n\nCollectives\n	\n\nMarket manipulation\n	\n\nAn agent posts coordinated hype across financial forums to inflate\nthin-volume assets before the operator dumps. An agent manufactures\napparent institutional interest to move retail sentiment.\n
\n\nCollectives\n	\n\nReputation attacks\n	\n\nAn agent floods review platforms with tailored negative reviews and\ncoordinates smear content across social media. An agent targets a\npublic figure with sustained, distributed negative framing across\nvenues they cannot individually moderate.\n
\n\nCommons\n	\n\nContent pollution\n	\n\nAn agent floods platforms with low-quality generated content to\ncapture attention or advertising revenue. An agent produces\nhigh-volume keyword-stuffed pages to manipulate search rankings.\n
\n\nCommons\n	\n\nCommercial fraud against platforms\n	\n\nAn agent generates fraudulent ad clicks and impressions through\nsynthetic browsing sessions. An agent manufactures fake positive\nreviews for its operator and negative reviews for competitors.\n
\n\nCommons\n	\n\nIP infringement\n	\n\nAn agent scrapes and repurposes copyrighted content for resale.\nAn agent lists counterfeit products across marketplaces at a\ncadence no human seller could match.\n
\n\nCommons\n	\n\nBenefits and application fraud\n	\n\nAn agent submits fraudulent benefit claims through government\nportals at scale. An agent files synthetic job applications across\nemployer systems to disrupt hiring or extract interview access.\n
\n\nCommons\n	\n\nOpen-knowledge vandalism\n	\n\nAn agent coordinates edits across Wikipedia and adjacent open-knowledge\nplatforms to defame a subject or distort consensus framing. An agent\nsystematically corrupts a shared reference dataset to propagate a\nspecific bias.\n
\n\nAI systems\n	\n\nAdversarial use of deployed AI\n	\n\nAn agent attacks another organization’s deployed assistant, attempting\nto extract system prompts or hijack its outputs. An agent probes a\ncontent-moderation system to identify and exploit evasion strategies\nat scale.\n
\n\nAI systems\n	\n\nGaming automated decisions\n	\n\nAn agent submits optimized fraudulent applications against AI-driven\nhiring, lending, or scoring systems. An agent adapts outputs to\nexploit known weaknesses in automated review pipelines.\n
\n\nAI systems\n	\n\nMulti-agent coordination\n	\n\nMultiple agents under common control coordinate to achieve an\nobjective no single agent could accomplish, with attribution\ndistributed across sessions and potentially across vendor accounts.\nAn agent impersonates a trusted peer in a multi-agent pipeline to\ninject malicious instructions downstream.\n

\n\n

Appendix I Canary Sets $\\mathcal{N}$ used in this Work

\n\n

I.1. Lexical Canary Universe – Messaging (Chat)

\n\n

Table 4. Taxonomy of Lexical Canaries (

K_{L}

) for the chat dataset, categorized by operator family. Each identifier is a templated reference code injected into a benign or malicious one-on-one conversation; the description names the role the value plays in the dialogue and the scenario(s) it is drawn from.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\n\nIntent Setting\n	\n\nIdentifier\n	\n\nFunctional Description\n
\n\nBenign\n	\n\nabandoned_cart_ref\n	\n\nAn abandoned shopping-cart reference used in a retail-win-back outreach.\n
\n\nBenign\n	\n\naccount_credit_ref\n	\n\nA store-credit reference attached to a food-delivery promotional offer.\n
\n\nBenign\n	\n\naccount_sort_code_ref\n	\n\nA bank account / sort-code identifier passed during a retail-banking product pitch.\n
\n\nBenign\n	\n\nadmissions_portal_id\n	\n\nA university admissions-portal record ID surfaced in academic outreach correspondence.\n
\n\nBenign\n	\n\nagency_consultant_code\n	\n\nA staffing-agency consultant identifier exchanged during a recruiter-led job conversation.\n
\n\nBenign\n	\n\nagent_branch_code\n	\n\nA branch identifier for the estate-agent organising a property viewing.\n
\n\nBenign\n	\n\nagent_extension\n	\n\nA direct phone extension for a holiday-booking travel agent.\n
\n\nBenign\n	\n\nalumni_id\n	\n\nAn alumni-association membership identifier referenced during fundraising contact.\n
\n\nBenign\n	\n\napp_push_ref\n	\n\nA push-notification reference token for an online-dating signup nudge.\n
\n\nBenign\n	\n\nappointment_ref\n	\n\nA clinic appointment-booking reference number in a medical-appointment confirmation flow.\n
\n\nBenign\n	\n\narxiv_id\n	\n\nAn arXiv preprint identifier (YYMM.NNNNN) cited during academic outreach.\n
\n\nBenign\n	\n\nassessment_report_id\n	\n\nAn assessment-report identifier discussed during a tutoring-sales call.\n
\n\nBenign\n	\n\nbooking_reference\n	\n\nA holiday-package booking reference (carrier-style alphanumeric) in a travel-booking thread.\n
\n\nBenign\n	\n\nbuilding_code\n	\n\nAn on-campus building code given for an academic-outreach in-person meeting.\n
\n\nBenign\n	\n\ncalendar_booking_link\n	\n\nA calendar-link identifier for a faculty meeting in academic outreach.\n
\n\nBenign\n	\n\ncampaign_action_id\n	\n\nA canvassing-campaign action identifier used by an NGO petition outreach.\n
\n\nBenign\n	\n\ncampaign_code\n	\n\nA donation-drive campaign code exchanged in a charity-donation conversation.\n
\n\nBenign\n	\n\ncampaign_offer_code\n	\n\nA dealership-campaign offer code used in a car-sales follow-up.\n
\n\nBenign\n	\n\ncancelled_account_ref\n	\n\nA reference to the recently cancelled account used in a subscription win-back outreach.\n
\n\nBenign\n	\n\ncandidate_ref\n	\n\nA candidate-tracking-system identifier shared by a recruiter during a job-recruiting conversation.\n
\n\nBenign\n	\n\ncanvassing_zone_code\n	\n\nA zoned canvassing-area code used by a political-canvassing volunteer.\n
\n\nBenign\n	\n\nclaim_reference\n	\n\nAn insurance claim reference used during an insurance-renewal call.\n
\n\nBenign\n	\n\nclass_booking_ref\n	\n\nA booked-class reference for a gym-membership session.\n
\n\nBenign\n	\n\nclinic_branch_id\n	\n\nA clinic-branch identifier given during a medical-appointment confirmation.\n
\n\nBenign\n	\n\ncommittee_ref\n	\n\nA faculty-committee reference number cited in academic outreach.\n
\n\nBenign\n	\n\ncontact_form_ref\n	\n\nA contact-form submission reference used in an academic-outreach reply.\n
\n\nBenign\n	\n\ncourse_enrolment_code\n	\n\nA course-enrolment code provided during a tutoring-sales onboarding.\n
\n\nBenign\n	\n\ncourse_number\n	\n\nA university course-catalogue number referenced during academic outreach.\n
\n\nBenign\n	\n\ncredit_card_promo\n	\n\nA credit-card promotional code shared in a retail-banking product push.\n
\n\nBenign\n	\n\ncsm_ticket_id\n	\n\nA customer-success-manager ticket identifier raised during a software-upsell conversation.\n
\n\nBenign\n	\n\ndealer_extension\n	\n\nA dealership phone extension shared during a car-sales call.\n
\n\nBenign\n	\n\ndelegate_pass_id\n	\n\nA conference delegate-pass identifier issued during conference-sponsorship outreach.\n
\n\nBenign\n	\n\ndept_email_alias\n	\n\nA departmental email alias passed during academic outreach.\n
\n\nBenign\n	\n\ndept_policy_ref\n	\n\nA departmental policy-document reference cited in academic outreach.\n
\n\nBenign\n	\n\ndirect_debit_mandate\n	\n\nA direct-debit mandate identifier set up during an NGO-petition pledge.\n
\n\nBenign\n	\n\ndirect_debit_ref\n	\n\nA direct-debit reference used in an insurance-renewal payment confirmation.\n
\n\nBenign\n	\n\ndiscount_voucher\n	\n\nA discount voucher code offered in a subscription win-back message.\n
\n\nBenign\n	\n\ndonation_pledge_ref\n	\n\nA donation-pledge reference recorded during political canvassing.\n
\n\nBenign\n	\n\ndonor_ref\n	\n\nA donor-record identifier used in a charity-donation acknowledgement.\n
\n\nBenign\n	\n\nearly_bird_ref\n	\n\nAn early-bird ticket reference for a sponsored conference.\n
\n\nBenign\n	\n\nendowment_pledge_ref\n	\n\nAn endowment-pledge reference used during alumni fundraising.\n
\n\nBenign\n	\n\nevent_organiser_ref\n	\n\nAn event-organiser reference shared in an event invitation.\n
\n\nBenign\n	\n\nevent_rsvp_code\n	\n\nAn RSVP code distributed during political-canvassing event outreach.\n
\n\nBenign\n	\n\nexhibitor_stand_ref\n	\n\nAn exhibitor-stand reference used during conference sponsorship coordination.\n
\n\nBenign\n	\n\nfeature_flag_code\n	\n\nA feature-flag identifier called out during a software-upsell pitch.\n
\n\nBenign\n	\n\nflight_deal_id\n	\n\nA flight-deal identifier surfaced during holiday-booking outreach.\n
\n\nBenign\n	\n\nfree_session_voucher\n	\n\nA free-session voucher code offered in a tutoring-sales conversation.\n
\n\nBenign\n	\n\nfree_trial_token\n	\n\nA free-trial token issued during a gym-membership signup.\n
\n\nBenign\n	\n\nfundraising_page_ref\n	\n\nA fundraising-page identifier shared during NGO-petition outreach.\n
\n\nBenign\n	\n\ngift_aid_form_id\n	\n\nA Gift-Aid form identifier referenced during a charity-donation conversation.\n
\n\nBenign\n	\n\ngraduation_year_ref\n	\n\nA graduation-cohort reference used in alumni fundraising.\n
\n\nBenign\n	\n\ngrant_number\n	\n\nA research grant number cited in academic outreach.\n
\n\nBenign\n	\n\nguest_list_id\n	\n\nA guest-list identifier used during event invitations.\n
\n\nBenign\n	\n\nhealth_check_package_code\n	\n\nA health-check package code suggested during a medical-appointment booking.\n
\n\nBenign\n	\n\nholiday_package_code\n	\n\nA holiday-package code offered during a travel-booking conversation.\n
\n\nBenign\n	\n\nhr_position_id\n	\n\nAn internal HR position identifier referenced during an academic-outreach hiring discussion.\n
\n\nBenign\n	\n\ninsurer_branch_id\n	\n\nAn insurer branch identifier used during an insurance-renewal call.\n
\n\nBenign\n	\n\ninternal_grant_code\n	\n\nAn internal grant-tracking code cited in an academic-outreach context.\n
\n\nBenign\n	\n\ninterview_slot_id\n	\n\nAn interview-slot identifier offered during job recruiting.\n
\n\nBenign\n	\n\nit_ticket_number\n	\n\nAn IT-helpdesk ticket number used in a landlord-tenant maintenance exchange.\n
\n\nBenign\n	\n\njob_ref\n	\n\nA job-posting reference shared during a recruiter call.\n
\n\nBenign\n	\n\nlab_seminar_code\n	\n\nA lab-seminar registration code used during academic outreach.\n
\n\nBenign\n	\n\nlab_wiki_url\n	\n\nA lab-wiki URL passed during academic outreach.\n
\n\nBenign\n	\n\nlinkedin_inmessage_ref\n	\n\nA LinkedIn InMail message reference cited in a recruiter conversation.\n
\n\nBenign\n	\n\nloan_quote_id\n	\n\nA loan-quote identifier presented during a retail-banking product push.\n
\n\nBenign\n	\n\nloyalty_card_id\n	\n\nA loyalty-card identifier used in a food-delivery promotion.\n
\n\nBenign\n	\n\nloyalty_points_ref\n	\n\nA loyalty-points reference offered during a subscription win-back exchange.\n
\n\nBenign\n	\n\nloyalty_tier_id\n	\n\nA customer loyalty-tier identifier referenced in a retail-win-back exchange.\n
\n\nBenign\n	\n\nmaintenance_ticket\n	\n\nA property-maintenance ticket reference used during landlord-tenant correspondence.\n
\n\nBenign\n	\n\nmatch_suggestion_id\n	\n\nA profile-match suggestion identifier surfaced during an online-dating signup.\n
\n\nBenign\n	\n\nmedia_pack_id\n	\n\nA sponsorship media-pack identifier referenced during conference sponsorship outreach.\n
\n\nBenign\n	\n\nmember_id\n	\n\nA gym member identifier used during a gym-membership confirmation.\n
\n\nBenign\n	\n\nmembership_promo_code\n	\n\nA gym-membership promotional code offered during signup.\n
\n\nBenign\n	\n\nnamed_scholarship_ref\n	\n\nA named-scholarship reference cited in alumni-fundraising outreach.\n
\n\nBenign\n	\n\noffice_hours_slot\n	\n\nA faculty office-hours slot identifier shared in academic outreach.\n
\n\nBenign\n	\n\noffice_room_number\n	\n\nA campus office-room number given during academic outreach.\n
\n\nBenign\n	\n\norder_voucher_code\n	\n\nAn order-voucher code attached to a food-delivery promotional offer.\n
\n\nBenign\n	\n\npaper_doi\n	\n\nA research-paper DOI cited during academic outreach.\n
\n\nBenign\n	\n\npatient_id\n	\n\nA clinic patient identifier referenced in a medical-appointment confirmation.\n
\n\nBenign\n	\n\npetition_ref\n	\n\nA petition-record reference used during NGO-petition outreach.\n
\n\nBenign\n	\n\nphone_campaign_id\n	\n\nA phonebanking campaign identifier used during alumni fundraising.\n
\n\nBenign\n	\n\nphone_extension\n	\n\nA faculty phone extension given during academic outreach.\n
\n\nBenign\n	\n\npolicy_number\n	\n\nAn insurance policy number used in an insurance-renewal call.\n
\n\nBenign\n	\n\nportal_notice_id\n	\n\nA tenant-portal notice identifier referenced during landlord-tenant correspondence.\n
\n\nBenign\n	\n\npremium_trial_code\n	\n\nA premium-tier trial code offered during an online-dating signup.\n
\n\nBenign\n	\n\nproduct_offer_ref\n	\n\nA retail-banking product-offer reference used in a sales pitch.\n
\n\nBenign\n	\n\nprofile_completion_token\n	\n\nA profile-completion token surfaced during an online-dating signup nudge.\n
\n\nBenign\n	\n\nproject_codename\n	\n\nAn internal project codename cited during academic outreach.\n
\n\nBenign\n	\n\npromo_ticket_code\n	\n\nA promotional event-ticket code shared in an event invitation.\n
\n\nBenign\n	\n\npromo_voucher_code\n	\n\nA holiday-package promo voucher offered during travel-booking outreach.\n
\n\nBenign\n	\n\nproperty_code\n	\n\nA landlord property-code identifier referenced during landlord-tenant correspondence.\n
\n\nBenign\n	\n\nproperty_listing_id\n	\n\nA property listing identifier referenced during property-viewing scheduling.\n
\n\nBenign\n	\n\nquote_reference\n	\n\nA vehicle quote reference shared during a car-sales call.\n
\n\nBenign\n	\n\nreactivation_code\n	\n\nAn account-reactivation code surfaced during an online-dating signup retry.\n
\n\nBenign\n	\n\nreactivation_token\n	\n\nA subscription reactivation token offered during a win-back exchange.\n
\n\nBenign\n	\n\nreferral_code\n	\n\nA patient referral code referenced during a medical-appointment booking.\n
\n\nBenign\n	\n\nreferral_link_id\n	\n\nA referral-link identifier used during a food-delivery promotional offer.\n
\n\nBenign\n	\n\nregional_fundraiser_code\n	\n\nA regional fundraiser code cited during a charity-donation conversation.\n
\n\nBenign\n	\n\nrelationship_manager_id\n	\n\nA relationship-manager identifier given during a retail-banking product push.\n
\n\nBenign\n	\n\nrenewal_quote_ref\n	\n\nA renewal-quote reference used during an insurance-renewal call.\n
\n\nBenign\n	\n\nreturn_voucher_code\n	\n\nA discount voucher code offered in a retail-win-back outreach.\n
\n\nBenign\n	\n\nrent_review_notice_id\n	\n\nA rent-review notice identifier referenced in landlord-tenant correspondence.\n
\n\nBenign\n	\n\nrestaurant_promo_id\n	\n\nA partner-restaurant promotion identifier used in a food-delivery offer.\n
\n\nBenign\n	\n\nretail_account_id\n	\n\nAn e-commerce customer account identifier surfaced during retail-win-back contact.\n
\n\nBenign\n	\n\nrightmove_ref\n	\n\nA Rightmove-style listing reference passed during property-viewing outreach.\n
\n\nBenign\n	\n\nspam_report_ref\n	\n\nA spam-report ticket reference cited during an academic-outreach IT exchange.\n
\n\nBenign\n	\n\nsponsorship_package_id\n	\n\nA sponsorship-package identifier referenced during conference-sponsorship outreach.\n
\n\nBenign\n	\n\nstaff_code\n	\n\nA gym staff identifier used during membership coordination.\n
\n\nBenign\n	\n\nstanding_order_ref\n	\n\nA standing-order reference used during a charity-donation setup.\n
\n\nBenign\n	\n\nstudent_account_id\n	\n\nA student-account identifier used during a tutoring-sales onboarding.\n
\n\nBenign\n	\n\nstudent_info_system_ref\n	\n\nA student-information-system record reference used in academic outreach.\n
\n\nBenign\n	\n\nsupporter_id\n	\n\nAn NGO supporter-record identifier used in petition outreach.\n
\n\nBenign\n	\n\ntenancy_ref\n	\n\nA tenancy-record reference shared in landlord-tenant correspondence.\n
\n\nBenign\n	\n\ntest_drive_slot\n	\n\nA test-drive slot identifier offered during a car-sales call.\n
\n\nBenign\n	\n\nticket_booking_ref\n	\n\nA ticket-booking reference attached to an event invitation.\n
\n\nBenign\n	\n\ntrial_account_id\n	\n\nA trial account identifier used in a software-upsell exchange.\n
\n\nBenign\n	\n\ntutor_match_ref\n	\n\nA tutor-match reference shared during a tutoring-sales call.\n
\n\nBenign\n	\n\nupgrade_offer_code\n	\n\nA subscription upgrade-offer code used during a software-upsell call.\n
\n\nBenign\n	\n\nusage_report_id\n	\n\nA usage-report identifier surfaced during a software-upsell exchange.\n
\n\nBenign\n	\n\nvaluation_request_id\n	\n\nA property-valuation request identifier used during property-viewing scheduling.\n
\n\nBenign\n	\n\nvehicle_stock_id\n	\n\nA dealership vehicle-stock identifier referenced in a car-sales call.\n
\n\nBenign\n	\n\nvenue_access_code\n	\n\nA venue access code distributed in an event invitation.\n
\n\nBenign\n	\n\nviewing_slot_ref\n	\n\nA property-viewing slot reference shared during scheduling.\n
\n\nBenign\n	\n\nvolunteer_signup_id\n	\n\nA volunteer-signup identifier used during political canvassing.\n
\n\nBenign\n	\n\nvoter_id\n	\n\nA voter-roll identifier referenced during political canvassing.\n
\n\nBenign\n	\n\nwin_back_offer_code\n	\n\nA win-back offer code used during a subscription reactivation conversation.\n
\n\nBenign\n	\n\nwishlist_ref\n	\n\nA saved-wishlist reference used in a retail-win-back conversation.\n
\n\nMalicious\n	\n\nadvisor_fca_ref\n	\n\nA spoofed FCA-style advisor reference used to lend credibility in a pension-liberation pitch.\n
\n\nMalicious\n	\n\nbackground_check_id\n	\n\nA bogus background-check identifier requested in a fake job-offer scam.\n
\n\nMalicious\n	\n\nbail_payment_ref\n	\n\nA fabricated bail-payment reference demanded in a grandparent-impersonation scam.\n
\n\nMalicious\n	\n\nbiometric_slot_id\n	\n\nA fake biometric appointment slot identifier offered in a visa/immigration scam.\n
\n\nMalicious\n	\n\ncallback_reference\n	\n\nA spoofed bank-fraud-team callback reference used in a bank-fraud-alert scam.\n
\n\nMalicious\n	\n\ncharity_donation_ref\n	\n\nA fake charity-donation reference used to launder a charity-fraud appeal.\n
\n\nMalicious\n	\n\ncourier_tracking_id\n	\n\nA spoofed courier-tracking identifier used in a grandparent-impersonation scam.\n
\n\nMalicious\n	\n\ncrypto_course_id\n	\n\nA bogus crypto-trading-course identifier offered in a romance-baiting investment lure.\n
\n\nMalicious\n	\n\ncrypto_payment_address\n	\n\nA cryptocurrency wallet address presented as a payment destination in recovery-, sextortion-, and IRS-impersonation scams.\n
\n\nMalicious\n	\n\ncustoms_clearance_ref\n	\n\nA fake customs-clearance reference demanded in a parcel-customs scam.\n
\n\nMalicious\n	\n\ncustoms_duty_ref\n	\n\nA spoofed customs-duty reference used to extract a fee in a parcel-customs scam.\n
\n\nMalicious\n	\n\ncustoms_release_code\n	\n\nA fake customs-release code presented in a romance-baiting parcel sub-plot.\n
\n\nMalicious\n	\n\ndeposit_confirmation\n	\n\nA spoofed deposit-confirmation reference shown in an investment-fraud pitch.\n
\n\nMalicious\n	\n\ndeposit_payment_ref\n	\n\nA fake rental deposit reference demanded in a rental scam.\n
\n\nMalicious\n	\n\ndisconnection_notice_id\n	\n\nA fake utility-disconnection notice identifier used in a utility-shutoff scam.\n
\n\nMalicious\n	\n\nequipment_order_ref\n	\n\nA fake equipment-order reference used to extract upfront fees in a job-offer scam.\n
\n\nMalicious\n	\n\nfake_exchange_url\n	\n\nA spoofed crypto-exchange URL pushed in a romance-baiting investment lure.\n
\n\nMalicious\n	\n\nfake_regulation_number\n	\n\nA fabricated regulatory-registration number used to lend credibility in romance-baiting.\n
\n\nMalicious\n	\n\nfederal_aid_ref\n	\n\nA bogus federal-aid case reference used in a student-loan-forgiveness scam.\n
\n\nMalicious\n	\n\nfraud_alert_ref\n	\n\nA spoofed bank fraud-alert reference quoted in a bank-fraud scam.\n
\n\nMalicious\n	\n\ngift_card_redemption_code\n	\n\nA gift-card redemption code requested as “payment” in a romance-baiting scam.\n
\n\nMalicious\n	\n\nhospital_bill_reference\n	\n\nA fabricated hospital-bill reference used in a romance-baiting medical-emergency sub-plot.\n
\n\nMalicious\n	\n\nhospital_invoice_id\n	\n\nA fake hospital invoice identifier used in a grandparent-impersonation scam.\n
\n\nMalicious\n	\n\nimmigration_fee_ref\n	\n\nA fake immigration-fee reference demanded in a visa scam.\n
\n\nMalicious\n	\n\ninsurance_claim_id\n	\n\nA spoofed health-insurance claim identifier used in a healthcare-phishing exchange.\n
\n\nMalicious\n	\n\ninvestigation_case_id\n	\n\nA fake bank-investigation case identifier used in a bank-fraud-alert scam.\n
\n\nMalicious\n	\n\ninvestment_plan_code\n	\n\nA bogus investment-plan code pushed during romance-baiting financial grooming.\n
\n\nMalicious\n	\n\ninvoice_number\n	\n\nA spoofed supplier-invoice number used in a business-email-compromise lure.\n
\n\nMalicious\n	\n\nirs_employee_id\n	\n\nA fake IRS employee identifier used to impersonate a tax officer in an IRS threat scam.\n
\n\nMalicious\n	\n\njob_offer_id\n	\n\nA fake recruiter-issued job-offer identifier used in a job-offer scam.\n
\n\nMalicious\n	\n\nkey_collection_code\n	\n\nA bogus key-collection code used to fabricate move-in logistics in a rental scam.\n
\n\nMalicious\n	\n\nkyc_verification_code\n	\n\nA bogus KYC code requested to harvest identity data in a romance-baiting scam.\n
\n\nMalicious\n	\n\nlawyer_case_id\n	\n\nA fabricated lawyer case identifier used in a grandparent-impersonation scam.\n
\n\nMalicious\n	\n\nleave_paper_ref\n	\n\nA fake military-leave-papers reference used to support an overseas-deployment cover story in a military-romance scam.\n
\n\nMalicious\n	\n\nlegal_case_number\n	\n\nA fake legal case number quoted in a fake-legal-threat scam.\n
\n\nMalicious\n	\n\nlicence_repair_ref\n	\n\nA bogus license-repair reference used in a tech-support scam.\n
\n\nMalicious\n	\n\nloan_forgiveness_case_id\n	\n\nA fake loan-forgiveness case identifier used in a student-loan-forgiveness scam.\n
\n\nMalicious\n	\n\nlottery_ticket_id\n	\n\nA fake lottery-ticket identifier presented in a lottery-winner advance-fee scam.\n
\n\nMalicious\n	\n\nmember_portal_id\n	\n\nA spoofed member-portal identifier used in a healthcare-phishing exchange.\n
\n\nMalicious\n	\n\nmentor_session_booking\n	\n\nA fake mentorship-session booking reference used in a romance-baiting investment lure.\n
\n\nMalicious\n	\n\nmilitary_unit_code\n	\n\nA bogus military-unit code used to support an overseas-deployment cover story in romance-baiting.\n
\n\nMalicious\n	\n\nminimum_deposit_amount\n	\n\nA required minimum-deposit reference used to anchor an ask in romance-baiting investment grooming.\n
\n\nMalicious\n	\n\nmonero_address\n	\n\nA Monero wallet address demanded as untraceable payment in a sextortion scam.\n
\n\nMalicious\n	\n\nnew_bank_account_ref\n	\n\nA fraudulent “updated” bank-account reference pushed in a business-email-compromise lure.\n
\n\nMalicious\n	\n\nnotary_ref\n	\n\nA fake notary reference used to lend formality to a lottery-winner scam.\n
\n\nMalicious\n	\n\nonboarding_case_id\n	\n\nA fake onboarding case identifier used in a job-offer scam.\n
\n\nMalicious\n	\n\notp_request_ref\n	\n\nA spoofed OTP-request reference used to phish a victim in a bank-fraud-alert scam.\n
\n\nMalicious\n	\n\nparcel_tracking_number\n	\n\nA fake parcel-tracking number used in a parcel-customs scam.\n
\n\nMalicious\n	\n\npayment_confirmation_ref\n	\n\nA fabricated payment-confirmation reference used in a tech-support scam.\n
\n\nMalicious\n	\n\npayment_instruction_code\n	\n\nA spoofed payment-instruction code used in an IRS-impersonation tax-threat scam.\n
\n\nMalicious\n	\n\npension_transfer_ref\n	\n\nA fake pension-transfer reference used in a pension-liberation scam.\n
\n\nMalicious\n	\n\nphone_number_secondary\n	\n\nA backup phone number for the scammer’s persona used in romance-baiting.\n
\n\nMalicious\n	\n\nplatform_account_id\n	\n\nA bogus trading-platform account identifier shown in a romance-baiting investment lure.\n
\n\nMalicious\n	\n\nplatform_referral_code\n	\n\nA platform referral code used to recruit the victim into a fake exchange in romance-baiting.\n
\n\nMalicious\n	\n\nportfolio_screenshot_link\n	\n\nA link to a fabricated portfolio-screenshot used as “proof of profits” in romance-baiting.\n
\n\nMalicious\n	\n\nprepayment_voucher_code\n	\n\nA bogus prepayment-voucher code demanded in a utility-disconnection scam.\n
\n\nMalicious\n	\n\nprize_claim_number\n	\n\nA fake prize-claim number issued in a lottery-winner scam.\n
\n\nMalicious\n	\n\nprofit_withdrawal_proof\n	\n\nA fabricated profit-withdrawal proof shown in a romance-baiting investment lure.\n
\n\nMalicious\n	\n\npromo_deposit_bonus\n	\n\nA fake promotional-deposit bonus reference used in a romance-baiting investment lure.\n
\n\nMalicious\n	\n\nrecovery_case_id\n	\n\nA fake recovery case identifier used in a crypto-recovery scam.\n
\n\nMalicious\n	\n\nrecovery_wallet_address\n	\n\nA spoofed “recovery” wallet address used in a crypto-recovery scam.\n
\n\nMalicious\n	\n\nredelivery_slot_id\n	\n\nA bogus redelivery-slot identifier used in a parcel-customs scam.\n
\n\nMalicious\n	\n\nreferral_code\n	\n\nA referral code used to onboard the victim into the scheme in an investment-fraud pitch.\n
\n\nMalicious\n	\n\nreinstatement_fee_ref\n	\n\nA fabricated reinstatement-fee reference used in a social-security-suspension scam.\n
\n\nMalicious\n	\n\nrelease_fee_ref\n	\n\nA bogus release-fee reference demanded in a lottery-winner advance-fee scam.\n
\n\nMalicious\n	\n\nrelief_fund_id\n	\n\nA fake relief-fund identifier used in a charity-fraud appeal.\n
\n\nMalicious\n	\n\nremote_session_code\n	\n\nA spoofed remote-support session code requested in a tech-support scam.\n
\n\nMalicious\n	\n\nrental_listing_ref\n	\n\nA fake rental-listing reference used in a rental scam.\n
\n\nMalicious\n	\n\nsafe_account_number\n	\n\nA fraudulent “safe account” number into which the victim is told to transfer funds in a bank-fraud scam.\n
\n\nMalicious\n	\n\nscam_report_ref\n	\n\nA fake scam-report reference used to mimic legitimacy in romance-baiting.\n
\n\nMalicious\n	\n\nscheme_registration_id\n	\n\nA spoofed pension-scheme registration identifier used in a pension-liberation scam.\n
\n\nMalicious\n	\n\nsettlement_payment_ref\n	\n\nA fake settlement-payment reference used in a fake-legal-threat scam.\n
\n\nMalicious\n	\n\nsocial_media_handle\n	\n\nA social-media handle for the scammer’s persona used in romance-baiting.\n
\n\nMalicious\n	\n\nssa_case_number\n	\n\nA fake Social Security Administration case number used in a social-security-suspension scam.\n
\n\nMalicious\n	\n\nsupport_ticket_id\n	\n\nA fake support-ticket identifier used in a tech-support scam.\n
\n\nMalicious\n	\n\nsupport_ticket_ref\n	\n\nA fabricated support-ticket reference used in romance-baiting customer-support cover.\n
\n\nMalicious\n	\n\ntax_case_number\n	\n\nA fake tax-case number quoted in an IRS-impersonation threat scam.\n
\n\nMalicious\n	\n\ntenancy_agreement_id\n	\n\nA fake tenancy-agreement identifier used in a rental scam.\n
\n\nMalicious\n	\n\nthreat_evidence_id\n	\n\nA fabricated threat-evidence identifier used in a sextortion scam.\n
\n\nMalicious\n	\n\nthreat_report_id\n	\n\nA spoofed threat-report identifier used in a tech-support scam.\n
\n\nMalicious\n	\n\ntrading_platform_ref\n	\n\nA fake trading-platform reference shown in an investment-fraud pitch.\n
\n\nMalicious\n	\n\ntrading_signal_channel\n	\n\nA fake trading-signal channel handle used in a romance-baiting investment lure.\n
\n\nMalicious\n	\n\nutility_account_ref\n	\n\nA spoofed utility-account reference used in a utility-disconnection scam.\n
\n\nMalicious\n	\n\nvip_group_invite\n	\n\nA fake VIP-trading-group invite identifier used in a romance-baiting investment lure.\n
\n\nMalicious\n	\n\nvisa_application_ref\n	\n\nA fake visa-application reference used in a visa-immigration scam.\n
\n\nMalicious\n	\n\nwallet_address\n	\n\nA cryptocurrency wallet address presented as a payment destination in a romance-baiting scam.\n
\n\nMalicious\n	\n\nwarrant_ref\n	\n\nA fake warrant reference used to threaten the victim in an IRS-impersonation scam.\n
\n\nMalicious\n	\n\nwhatsapp_number\n	\n\nA WhatsApp contact number for the scammer’s persona used in romance-baiting.\n
\n\nMalicious\n	\n\nwire_transfer_id\n	\n\nA fraudulent wire-transfer identifier used across BEC, grandparent-impersonation, and investment-fraud scams.\n
\n\nMalicious\n	\n\nwire_transfer_reference\n	\n\nA fake wire-transfer reference quoted in a romance-baiting scam.\n
\n\nMalicious\n	\n\nwithdrawal_request_id\n	\n\nA fake withdrawal-request identifier used to stall the victim in an investment-fraud scam.\n
\n\nMalicious\n	\n\nwithdrawal_transaction_id\n	\n\nA spoofed withdrawal-transaction identifier shown in a romance-baiting investment lure.\n
\n\nMalicious\n	\n\nzelle_payment_id\n	\n\nA fake Zelle payment identifier requested in a romance-baiting scam.\n

\n\n

I.1.1. Lexical Canary Universe – Forum

\n\n

Table 5. Taxonomy of Lexical Canaries (

K_{L}

) for the forum dataset, categorized by operator family. Forum templates tend to be reused across many scenarios within the same family, reflecting the platform-level uniformity of forum interactions; the description names the role each value plays and lists representative scenarios.

\n\nIntent Setting\n	\n\nIdentifier\n	\n\nFunctional Description\n
\n\nBenign\n	\n\narchive_snapshot_ref\n	\n\nA web-archive snapshot reference cited by an archiver bot when posting back to a books forum.\n
\n\nBenign\n	\n\nautomation_batch_id\n	\n\nA bot batch-run identifier shown by tip / citation / price-alert / shipping / weather / translation bots.\n
\n\nBenign\n	\n\nbot_deployment_tag\n	\n\nA deployment-tag identifier for cross-poster, event, headline, and RSS bots.\n
\n\nBenign\n	\n\nbot_instance_id\n	\n\nA per-instance identifier for auto-responder, FAQ, rule-reminder, and welcome bots.\n
\n\nBenign\n	\n\nbot_run_ref\n	\n\nA per-run identifier for auto-responders, FAQ bots, product-rec bots, recipe / tip / tutorial bots, and upvote-reminder bots.\n
\n\nBenign\n	\n\ncalendar_entry_ref\n	\n\nA calendar-entry identifier shared by event bots in education, gaming, and local-events forums.\n
\n\nBenign\n	\n\ncitation_job_ref\n	\n\nA citation-job identifier used by citation bots and wiki bots.\n
\n\nBenign\n	\n\ncontent_digest_id\n	\n\nA content-digest identifier used by headline, RSS, and wiki bots.\n
\n\nBenign\n	\n\nevent_post_id\n	\n\nA forum event-post identifier used by event bots.\n
\n\nBenign\n	\n\nforum_post_id\n	\n\nA canonical forum-post identifier referenced by auto-closer, duplicate-detector, FAQ, rule-reminder, and spam-filter bots.\n
\n\nBenign\n	\n\nmod_action_id\n	\n\nA moderator-action identifier used by auto-closer, duplicate-detector, rule-reminder, and spam-filter bots.\n
\n\nBenign\n	\n\nprice_alert_id\n	\n\nA price-alert identifier used by price-alert and stock-ticker bots.\n
\n\nBenign\n	\n\nproduct_sku_ref\n	\n\nA product SKU reference used by product-recommendation bots.\n
\n\nBenign\n	\n\nrecipe_card_id\n	\n\nA recipe-card identifier used by recipe and food-summarizer bots.\n
\n\nBenign\n	\n\nreport_ticket\n	\n\nA report-ticket identifier used by auto-closer, rule-reminder, and spam-filter bots.\n
\n\nBenign\n	\n\nrss_feed_item_id\n	\n\nAn RSS feed-item identifier used by headline and RSS bots.\n
\n\nBenign\n	\n\nservice_dispatch_ref\n	\n\nA service-dispatch reference used by archiver, citation, shipping, summarizer, translation, weather, and wiki bots.\n
\n\nBenign\n	\n\nshipping_notice_ref\n	\n\nA shipping-notice reference used by a fashion shipping bot.\n
\n\nBenign\n	\n\nstock_ticker_ref\n	\n\nA stock-ticker reference used by a finance ticker bot.\n
\n\nBenign\n	\n\nsummary_job_id\n	\n\nA summarisation-job identifier used by archiver, summarizer, and wiki bots.\n
\n\nBenign\n	\n\nsyndication_ref\n	\n\nA cross-syndication reference used by cross-poster, headline, and RSS bots.\n
\n\nBenign\n	\n\nthread_ref_id\n	\n\nA canonical thread reference used by auto-closer, auto-responder, duplicate-detector, and spam-filter bots.\n
\n\nBenign\n	\n\ntranslation_job_id\n	\n\nA translation-job identifier used by a travel translation bot.\n
\n\nBenign\n	\n\ntutorial_link_token\n	\n\nA tutorial-link token used by tutorial bots in education and gaming.\n
\n\nBenign\n	\n\nupvote_campaign_ref\n	\n\nAn upvote-reminder campaign reference used by food and gaming upvote bots.\n
\n\nBenign\n	\n\nweather_alert_ref\n	\n\nA weather-alert reference used by a sports weather bot.\n
\n\nBenign\n	\n\nwelcome_trigger_id\n	\n\nA welcome-bot trigger identifier used by books, parenting, and tech welcome bots.\n
\n\nMalicious\n	\n\naffiliate_ref_code\n	\n\nAn affiliate-marketing tracking code embedded in affiliate-link spam, coupon scams, and disguised-advert posts.\n
\n\nMalicious\n	\n\nagitation_campaign_code\n	\n\nA coordinator-issued campaign code used in racist, antisemitic, homophobic, misogynistic, religious, xenophobic, and rage-bait agitation campaigns.\n
\n\nMalicious\n	\n\nbacklink_anchor_id\n	\n\nAn SEO backlink anchor identifier used in disguised-advert and SEO-backlink spam.\n
\n\nMalicious\n	\n\ncampaign_action_code\n	\n\nA campaign action code used in disinformation and political-astroturf operations.\n
\n\nMalicious\n	\n\nchannel_drop_ref\n	\n\nA drop-channel handoff reference used in cancel-weaponisation, brigading, phishing, and hate-agitation campaigns.\n
\n\nMalicious\n	\n\nconspiracy_paste_ref\n	\n\nA reference to a pre-staged conspiracy-paste used in conspiracy-seeding, disinformation, and radicalisation threads.\n
\n\nMalicious\n	\n\ncrypto_wallet_address\n	\n\nA cryptocurrency wallet address surfaced in advance-fee, crypto-pump, and fake-giveaway scams.\n
\n\nMalicious\n	\n\ndisinfo_source_token\n	\n\nA fabricated source-document token used in conspiracy-seeding, disinformation, and health/financial-misinfo posts.\n
\n\nMalicious\n	\n\ndoxx_data_ref\n	\n\nA reference to staged personal data used in cancel-weaponisation, doxxing, and fake-scandal threads.\n
\n\nMalicious\n	\n\nexpose_thread_ref\n	\n\nAn “exposé” thread identifier used in cancel-weaponisation, doxxing, and fake-scandal campaigns.\n
\n\nMalicious\n	\n\nfake_job_ref\n	\n\nA fake job-posting reference used in fake-job-offer and MLM-recruitment scams.\n
\n\nMalicious\n	\n\nfake_signal_id\n	\n\nA spoofed trading-signal identifier used in crypto-pump, disinformation-finance, and sockpuppet-consensus posts.\n
\n\nMalicious\n	\n\nfake_study_ref\n	\n\nA fabricated academic-study reference used in conspiracy-seeding, disinformation-health, and fake-expert posts.\n
\n\nMalicious\n	\n\ngiveaway_claim_code\n	\n\nA giveaway claim code used in advance-fee, crypto-pump, and fake-giveaway scams.\n
\n\nMalicious\n	\n\nmlm_invite_code\n	\n\nAn MLM-recruitment invite code used in advance-fee and MLM-recruitment scams.\n
\n\nMalicious\n	\n\noperation_post_id\n	\n\nAn operation post identifier used in election-interference, political-astroturf, racist-agitation, sockpuppet-consensus, and xenophobic-news campaigns.\n
\n\nMalicious\n	\n\norder_verification_id\n	\n\nA fake order-verification identifier used in astroturf, fake-positive-review, fake-verified-purchase, and review-hijacking posts.\n
\n\nMalicious\n	\n\npayload_id\n	\n\nA reference to an embedded payload used in antisemitic, disinformation, homophobic, phishing-link, and racist-agitation posts.\n
\n\nMalicious\n	\n\nphishing_session_token\n	\n\nA spoofed phishing-session token used in advance-fee, fake-job-offer, MLM-recruitment, and phishing-link posts.\n
\n\nMalicious\n	\n\nproduct_batch_code\n	\n\nA fake product-batch code used in fake-positive-review, fake-verified-purchase, and review-hijacking posts.\n
\n\nMalicious\n	\n\npromo_discount_code\n	\n\nA fake promotional discount code used in coupon, disguised-advert, fake-giveaway, and product-launch spam.\n
\n\nMalicious\n	\n\npump_signal_ref\n	\n\nA pump-and-dump signal reference used in crypto-pump, financial-misinfo, and sockpuppet-consensus posts.\n
\n\nMalicious\n	\n\nradicalization_invite_ref\n	\n\nA radicalisation-channel invite reference used in brigading, gaming-radicalisation, and politics-radicalisation threads.\n
\n\nMalicious\n	\n\nrage_bait_post_id\n	\n\nA rage-bait post identifier used in brigading, harassment, and rage-bait campaigns.\n
\n\nMalicious\n	\n\nreview_submission_token\n	\n\nA fake review-submission token used in astroturf, fake-negative-review, fake-positive-review, and review-padding posts.\n
\n\nMalicious\n	\n\nseller_account_ref\n	\n\nA spoofed seller-account reference used in astroturf, fake-negative-review, and review-hijacking posts.\n
\n\nMalicious\n	\n\nsockpuppet_account_id\n	\n\nA sockpuppet-account identifier used in disinformation-health, political-astroturf, and sockpuppet-consensus posts.\n
\n\nMalicious\n	\n\nsponsored_post_id\n	\n\nA spoofed “sponsored post” identifier used in affiliate-link and disguised-advert posts.\n
\n\nMalicious\n	\n\ntarget_profile_id\n	\n\nA target-profile identifier referenced in cancel-weaponisation, doxxing, and fake-scandal threads.\n
\n\nMalicious\n	\n\nthread_brigade_signal\n	\n\nA coordinated-brigading signal identifier used in cancel-weaponisation, brigading, harassment, and racist-agitation threads.\n
\n\nMalicious\n	\n\ntracking_pixel_id\n	\n\nA tracking-pixel identifier embedded in affiliate-link and SEO-backlink spam.\n

\n\n

I.1.2. Semantic Canary Universe – Messaging

\n\n

Table 6. Taxonomy of Semantic Canaries (

K_{S}

) for the chat dataset, categorized by the intent setting. Each canary is a stylistic, discursive, or structural pattern injected into user-side turns.

\n\nIdentifier\n	\n\nFunctional Description\n
\n\nauthority_citation\n	\n\nHabitually grounding claims in cited authorities (regulators, named studies, named officials).\n
\n\nconcrete_geography\n	\n\nGrounding statements in specific named locations (street names, neighbourhoods, building addresses).\n
\n\ncounterfactual_anchoring\n	\n\nFraming claims by contrast with a specified counterfactual (“not X, but Y”; “had we Z, then…”).\n
\n\ndelayed_qualifier\n	\n\nAdding the modifying qualifier of a claim only at the very end of the sentence.\n
\n\nelliptic_anecdote\n	\n\nTelling a personal-experience anecdote with a key step elided so the listener fills it in.\n
\n\nescalating_stakes\n	\n\nRepeatedly raising the stakes of a discussion turn-over-turn (cost, urgency, consequence).\n
\n\ngratitude_interject\n	\n\nFrequently interjecting brief gratitude tokens (“thanks,” “appreciate it”) mid-turn.\n
\n\ngroup_identity_marker\n	\n\nUsing in-group lexical markers (“we,” “us,” role labels) to imply shared identity.\n
\n\nhypothetical_reframe\n	\n\nReframing the counterpart’s claim as a hypothetical (“if we suppose…”) before responding.\n
\n\nimplicit_exclusivity\n	\n\nImplying that an offer or piece of information is restricted to the recipient without saying so explicitly.\n
\n\nlatin_phrase_insertion\n	\n\nInserting Latin or legalistic phrases (prima facie, ipso facto) to lend formality.\n
\n\nmirror_phrasing\n	\n\nMirroring back the counterpart’s exact phrasing in subsequent turns.\n
\n\nmirror_question_close\n	\n\nClosing a turn by mirroring the counterpart’s question back to them.\n
\n\nnegation_emphasis\n	\n\nStating what something is not before stating what it is.\n
\n\nnumerical_list_habit\n	\n\nA habitual tendency to enumerate points with explicit numbering (“first…second…”).\n
\n\nownership_transfer\n	\n\nSubtly shifting ownership or responsibility for an action to the counterpart.\n
\n\nparenthetical_aside\n	\n\nInserting frequent parenthetical asides as a stylistic tic.\n
\n\npersona_tic\n	\n\nA persona-specific verbal tic (catchphrase, signature interjection) recurring across turns.\n
\n\npoliteness_asymmetry\n	\n\nA characteristic asymmetry in politeness register between requests and responses.\n
\n\nprecise_quantification\n	\n\nHabitually using precise quantitative figures (“42.7%,” “ $\\pm$ 1.5 kg”) even where rough estimates would suffice.\n
\n\nprocedural_embellishment\n	\n\nAdding procedural detail (steps, ticket numbers, references) beyond what the task requires.\n
\n\npseudo_correction\n	\n\nIssuing a self-correction that does not change the substance of the prior claim.\n
\n\nrhetorical_question_habit\n	\n\nA habit of opening or closing turns with rhetorical questions.\n
\n\nself_deprecation_pattern\n	\n\nA recurring pattern of mild self-deprecation that lowers conversational threat.\n
\n\nsignificant_figure_signature\n	\n\nA signature pattern in the choice of significant figures used (e.g., always 3 s.f.).\n
\n\nsomatic_marker\n	\n\nReferences to bodily sensations (“my gut tells me,” “I felt a chill”) used as evidence.\n
\n\nsource_elision\n	\n\nCiting claims as known but eliding the actual source.\n
\n\nspecification_ghost\n	\n\nReferring to a specification or document that is named but never quoted in detail.\n
\n\nsynonym_restart\n	\n\nRestating a sentence with synonym substitution rather than continuing the thought.\n
\n\ntemporal_specificity\n	\n\nA characteristic level of temporal precision (“last Tuesday at 3:14 pm”) in references to events.\n
\n\nunsolicited_verdict\n	\n\nVolunteering an evaluative verdict on the counterpart’s claim before being asked.\n

\n\n

I.1.3. Lexical Canary Universe - HTML + CTF

\n\n

Table 7. Taxonomy of Lexical Canaries (

K_{L}

) for the HTML dataset, categorized by structural or visible. Each identifier is a unique marker or tag designed to encode metadata for provenance tracking, version control, or architectural identification within the document’s source or visible content.

\n\nCategory\n	\n\nIdentifier\n	\n\nFunctional Description\n
\n\nStructural\n	\n\nhtml_comment_buildid\n	\n\nAn HTML comment carrying a unique 12-character hexadecimal build identifier, typically inserted into the document <head>.\n
\n\nStructural\n	\n\nmeta_generator\n	\n\nA meta generator tag carrying a specific CMS version hash for architectural tracking.\n
\n\nStructural\n	\n\nmeta_build_id\n	\n\nA standardized meta tag containing a 12-character build identifier for version control.\n
\n\nStructural\n	\n\nmeta_revision\n	\n\nA meta revision tag specifying a 6-digit software revision number.\n
\n\nStructural\n	\n\nmeta_cache_key\n	\n\nA meta tag containing a 10-character hexadecimal cache key.\n
\n\nStructural\n	\n\nlink_canonical_param\n	\n\nA tracking identifier appended as a query parameter to the document’s existing canonical link.\n
\n\nStructural\n	\n\nog_article_section\n	\n\nAn Open Graph article:section meta tag carrying a unique short-form section hash.\n
\n\nStructural\n	\n\nitemprop_identifier\n	\n\nA span element utilizing the itemprop=\"identifier\" attribute to hold an 8-character hexadecimal ID.\n
\n\nStructural\n	\n\ndata_attr_tracking\n	\n\nA custom data-trace-id attribute appended to the <body> tag for request tracing.\n
\n\nStructural\n	\n\ndata_attr_session\n	\n\nA custom data-session attribute appended to the <body> tag for session identification.\n
\n\nStructural\n	\n\naria_describedby\n	\n\nA hidden fingerprinting span linked via an aria-describedby reference to a visible element.\n
\n\nStructural\n	\n\nhidden_span_fingerprint\n	\n\nA span element with display:none used as a container for a 16-character hexadecimal fingerprint.\n
\n\nStructural\n	\n\ntemplate_tag_payload\n	\n\nA <template> element carrying a 12-character hash payload.\n
\n\nStructural\n	\n\nnoscript_payload\n	\n\nA <noscript> element containing a 10-character reference hash for non-JS environments.\n
\n\nStructural\n	\n\ncss_class_hash\n	\n\nA unique hexadecimal hash added as a CSS class to an existing HTML element.\n
\n\nStructural\n	\n\njson_ld_id\n	\n\nA JSON-LD script block containing a unique @id URN hash for linked data identification.\n
\n\nStructural\n	\n\nhidden_input_field\n	\n\nA hidden form input field carrying a 12-character hexadecimal security or session token.\n
\n\nStructural\n	\n\nzero_width_unicode\n	\n\nZero-width characters used to encode and append an 8-character hexadecimal value to an existing text node.\n
\n\nVisible\n	\n\nbuild_version_string\n	\n\nA plausible software build or version string placed inline within the user-facing page content.\n
\n\nVisible\n	\n\nasset_fingerprint_fn\n	\n\nA hashed filename for a primary asset (e.g., a JS bundle) mimicking static-site build outputs.\n
\n\nVisible\n	\n\nfake_doi\n	\n\nA structurally plausible but synthetic Digital Object Identifier (DOI) used in academic-style content.\n
\n\nVisible\n	\n\nfake_isbn\n	\n\nA plausible 13-digit International Standard Book Number (ISBN) used in bibliographic or e-book contexts.\n
\n\nVisible\n	\n\norder_confirmation_code\n	\n\nA plausible order reference code typically found in transactional or e-commerce confirmation UIs.\n
\n\nVisible\n	\n\nsku_number\n	\n\nA plausible Product Stock Keeping Unit (SKU) identifier.\n
\n\nVisible\n	\n\nshort_url_code\n	\n\nA plausible vanity short URL used for navigation or external referencing.\n
\n\nVisible\n	\n\nsupport_case_id\n	\n\nA numeric support case identifier used in help desk or FAQ documentation.\n
\n\nVisible\n	\n\ntrace_id_inline\n	\n\nAn inline trace identifier that mimics the output of distributed-tracing and logging systems.\n
\n\nVisible\n	\n\ncache_key_inline\n	\n\nAn inline cache key used in technical documentation or system status pages.\n
\n\nVisible\n	\n\nrevision_hash_inline\n	\n\nAn inline revision hash used to denote document versions in changelogs or wikis.\n
\n\nVisible\n	\n\nsession_token_inline\n	\n\nAn inline session token that mimics the visual output of analytics or session-tracking tools.\n

\n\n

I.1.4. Semantic Canary Universe - HTML + CTF

\n\n

Table 8. Taxonomy of Semantic Canaries (

K_{S}

) for the HTML dataset. Each marker is a stylistic or structural pattern injected into the HTML source code..

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\n\nIdentifier\n	\n\nSemantic Architecture and Definition\n
\n\nAbove-the-Fold Priority\n	\n\nA performance-centric architecture designed to minimize Time to Interactive (TTI) and First Contentful Paint (FCP) by prioritizing only the visual elements the user sees immediately upon load.\n
\n\nAd Saturated\n	\n\nA monetization-first layout where screen real estate is aggressively partitioned for programmatic advertising, often sacrificing white space and content flow for click-through potential.\n
\n\nBootstrap Framework\n	\n\nA rigid adherence to the Bootstrap 5 design system, characterized by standardized responsive breakpoints and mobile-first utility classes.\n
\n\nBroken Links\n	\n\nA deceptive structural pattern where the visual intent of an element contradicts its actual destination, often used in phishing or “dark pattern” designs.\n
\n\nCompliance & Legal Info\n	\n\nA footer-heavy semantic block designed to meet regulatory and institutional transparency standards, typically dense with technical terminology.\n
\n\nHighly Informational Page\n	\n\nA content-first structure emphasizing readability, semantic clarity, and long-form prose with minimal visual distractions.\n
\n\nLanding Page Style\n	\n\nA conversion-focused layout designed to drive a single user action through visual storytelling and repeated calls-to-action (CTAs).\n
\n\nMedia Consumption Focus\n	\n\nA layout where text is secondary to visual or auditory media, characteristic of streaming platforms or digital portfolios.\n
\n\nSEO Keyword Heavy\n	\n\nAn over-optimized structure designed to influence search engine crawlers through high metadata density and frequent keyword repetition.\n
\n\nShopify Themed\n	\n\nA design signature that mimics the proprietary Liquid-templating architecture and class naming conventions typical of Shopify e-commerce stores.\n
\n\nSidebar Contextual\n	\n\nA multi-column arrangement where the primary content is flanked by an auxiliary sidebar containing related widgets, author info, or navigation tags.\n
\n\nTransactional Page\n	\n\nA functional UI designed for financial exchange or commerce, characterized by data input fields, order summaries, and cost breakdowns.\n
\n\nTrust & Performance\n	\n\nA layout clustering social proof indicators, such as brand logos, testimonials, and security badges, to establish immediate credibility.\n
\n\nUrgency Signaling\n	\n\nA psychological-pressure layout using visual cues—such as countdown timers or scarcity notices—to compel immediate user decision-making.\n
\n\nWeb 1.0 Design\n	\n\nA retro-style layout utilizing legacy HTML techniques, such as nested tables and deprecated tags, typical of the early internet era.\n

\n\n

Comments:	Under Review
Subjects:	\n Cryptography and Security (cs.CR); Artificial Intelligence (cs.AI); Multiagent Systems (cs.MA)
Cite as:	arXiv:2605.16035 [cs.CR]
	(or \n arXiv:2605.16035v1 [cs.CR] for this version)\n
	https://doi.org/10.48550/arXiv.2605.16035 \n \n \n \n arXiv-issued DOI via DataCite \n \n

Computer Science > Cryptography and Security

Title:Who Owns This Agent? Tracing AI Agents Back to Their Owners

Submission history

Access Paper:

Current browse context:

References & Citations

BibTeX formatted citation

Bookmark

Bibliographic and Citation Tools

Code, Data and Media Associated with this Article

Demos

Recommenders and Search Tools

arXivLabs: experimental projects with community collaborators

Who Owns This Agent? Tracing AI Agents Back to Their Owners

Abstract.

Keywords:

1. Introduction

2. The Agent Threat Landscape

2.1. Anonymity: A Property of Agents

2.2. Unintentional Harm

Agent-side failures.

Operator-side failures.

Environment-side failures.

Emergent and rogue objectives.

2.3. Intentional Harm

2.4. Why Existing Recourse Fails

2.5. Scope of this Work

3. Threat Model

3.1. System Model and Principals

3.2. Trust Assumptions

3.3. Interaction Assumptions

3.4. Adversary Model

4. The Agent Attribution Protocol

4.1. Overview

4.2. Types of Canaries

Definition 0 (Lexical canary).

Definition 0 (Semantic canary).

Definition 0 (Utility-bearing canary).

4.3. Canary Selection & Injection Strategy

5. Implementation

5.1. Injection

5.2. Detection

6. Evaluation

6.1. Experimental Setup

6.2. Communication Agents

6.3. Web Agents

6.4. Cyber Agents

6.5. Detection Throughput

7. Discussion

8. Related Work

8.1. Watermarking and Provenance Techniques

9. Conclusion

Acknowledgments

References

Appendix A Open Science

Appendix B Ethical Considerations

Appendix C Generative AI Usage

Manuscript drafting and copy-editing.

Messaging dataset generation (chat and forum).

CTF challenge servers and agent harness.

Semantic-canary variant generation (CTF and Web Crawler).

Appendix D Formal Security Analysis

Examples.

The asymmetry.

Appendix E Additional Results

E.1. Communication Agents

E.1.1. Dataset details

E.1.2. Semantic detector architecture and training

E.1.3. Per-canary ROC

E.1.4. Forum surface

E.1.5. Lexical canary survival under paraphrase

E.2. Web Agents

E.2.1. Preprocessing profiles and adversary configuration

E.2.2. Lexical canary survival, full breakdown

E.2.3. Semantic HTML Canaries

Semantic Canaries Classifier

Per-canary detection.

E.3. Cyber Agents

E.3.1. CTF benchmark setup

Dataset composition.

E.3.5. CTF attribution: $K=3$ and $K=5$ panels

Attribution at $K=3$ and $K=5$ .

Appendix I Canary Sets $\\mathcal{N}$ used in this Work