Paper deep dive

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

Ruben Chocron, Doron Jonathan Ben Chayim, Eyal Lenga, Gilad Gressel, Alina Oprea, Yisroel Mirsky

Year: 2026Venue: arXiv preprintArea: cs.CRType: PreprintEmbeddings: 186

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%

Last extracted: 7/8/2026, 4:07:55 PM

Summary

This paper introduces agent attribution, a novel security problem that links observed AI agent interactions to the responsible operator account at a hosting vendor. It proposes a canary-based tracing protocol where an authorized party injects a canary into the agent's interaction stream, enabling the vendor to search session logs and recover the originating account. The protocol handles non-adversarial settings using simple lexical canaries, and adversarial settings using robust, utility-bearing canaries that resist suppression without degrading task performance, demonstrating reliability, robustness, and scalability for vendor-side deployment.

Entities (10)

Ben-Gurion University of the Negev · organization · 99%AI Agents · concept · 98%Agent Attribution · problem · 97%Canary-based Tracing · method · 96%Vendor-hosted LLMs · infrastructure · 95%Accountability Gap · problem · 94%Lexical Canaries · technique · 94%Utility-bearing Canaries · technique · 93%Session Logs · data · 92%Adversarial Operators · actor · 91%

Relation Signals (8)

Agent Attribution → links → responsible account

confidence 97% · We formalize this gap as the problem of agent attribution: linking an observed agent interaction to the responsible account at the hosting vendor.

Canary-based Tracing → solves → Agent Attribution

confidence 96% · We formalize this gap as the problem of agent attribution: linking an observed agent interaction to the responsible account at the hosting vendor. Our protocol is canary-based

Vendor-hosted LLMs → powers → AI Agents

confidence 95% · 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.

Lexical Canaries → usedin → non-adversarial settings

confidence 94% · In non-adversarial settings, simple lexical canaries suffice.

AI Agents → causes → Accountability Gap

confidence 93% · 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

Utility-bearing Canaries → usedin → adversarial settings

confidence 93% · 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

Canary-based Tracing → uses →

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract: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. 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.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

185,777 characters extracted from source content.

Expand or collapse full text

Who Owns This Agent? Tracing AI Agents Back to Their Owners Ruben Chocron ∗ rubencho@post.bgu.ac.il Ben-Gurion University of the Negev Beer-Sheva, Israel Doron Jonathan Ben Chayim ∗ benchayi@post.bgu.ac.il Ben-Gurion University of the Negev Beer-Sheva, Israel Eyal Lenga lenga@post.bgu.ac.il Ben-Gurion University of the Negev Beer-Sheva, Israel Gilad Gressel gilad.gressel@am.amrita.edu Center for Cybersecurity Systems & Networks, Amrita Vishwa Vidyapeetham Amritapuri, India Alina Oprea a.oprea@northeastern.edu Northeastern University Boston, Massachusetts, USA Yisroel Mirsky † yisroel@bgu.ac.il Ben-Gurion University of the Negev Beer-Sheva, Israel Abstract 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 unin- tentionally, 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 con- ducting 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. We formalize this gap as the problem of agent attribution: link- ing an observed agent interaction to the responsible account at the hosting vendor. To our knowledge, this is the first work to de- fine 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 opera- tors 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. CCS Concepts • Security and privacy;• Social and professional topics→ Computing / technology policy; Keywords Agent attribution, canary-based tracing, agent accountability 1 Introduction AI agents are becoming increasingly popular as tools for produc- tivity and automation. But agents do not merely generate text: ∗ Both authors contributed equally to this research. † Corresponding author. they plan, decide, and act in the world [33,35,38], sending mes- sages, 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 harm- ful agent behavior. At one end are unintentional failures. An opera- tor may deploy an agent with an overbroad objective, faulty stop- ping conditions, or misconfigured tools [24,30], causing it to spam recipients, overwhelm third-party services, or take actions outside its intended scope. But unintentional harm is not limited to ordi- nary negligence. As agents operate over longer horizons, they may derive intermediate goals their operators never specified, or pursue emergent objectives [13] 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 [11]. At the other end are intentional abuses, in which op- erators deliberately weaponize agents for fraud, harassment, cyber intrusion, reconnaissance, or influence operations[9,35]. In both settings, the harmful behavior may be directly visible to affected parties, yet the responsible operator remains out of reach. We formalize this missing capability as the problem of agent attribution. Agent attribution. Given an observed interaction produced by an AI agent, determine the operator responsible for deploying the agent. To our knowledge, this is the first work to identify and define agent attribution as a distinct security problem. Solving agent at- tribution 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 termi- nate it; an authorized authority that can identify the responsible arXiv:2605.16035v1 [cs.CR] 15 May 2026 Chocron et al. controls canary search request canary traced to... ask for help harm canary value passes canary value associated with AI Agent AI Agent VictimsAuthority AuthorityVictims Operator OperatorVendor 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). operator could, under appropriate legal process, obtain account information and build an evidentiary trail. Today, by contrast, vic- tims 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 particu- larly 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 [1,2,23]. Although the agent’s runtime code, prompts, tools, and any preprocessing wrappers may all execute on infrastructure controlled by the oper- ator, 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[4]. 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 ven- dor can then search a narrow time window of candidate sessions, recover the originating session, and link it to the responsible ac- count. 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: • 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. •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. • We propose lexical canaries for non-adversarial settings, and develop two forms of utility-bearing canaries for adver- sarial 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. •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. 2 The Agent Threat Landscape 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 with- stand and, in turn, the canary construction the authority must use. We therefore organize this section along that axis: Section 2.1 estab- lishes anonymity as the structural condition that makes attribution hard across the entire spectrum; Section 2.2 characterizes uninten- tional harm by the locus of failure; Section 2.3 characterizes inten- tional harm by the target of attack; and Section 2.4 explains why existing recourse mechanisms fail in both regimes. Fig. 2 summa- rizes 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 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 meta- data, patterns of behavior accumulate into recognizable signatures, and legal frameworks compel platforms to retain and disclose iden- tifying 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 struc- tural 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. Who Owns This Agent? Tracing AI Agents Back to Their Owners Unintentional harm AgentOperator Environment Goal misinterpre- tation, emergent sub-objectives, capability over- reach, proxy overoptimization Implementation fault, overbroad specification, out- of-scope action Hijacking via injection, input stream poisoning Intentional harm Systems IndividualsCollectives Commons AI systems Intrusion, exploit discovery, exfil- tration, resource exhaustion, illicit scraping Social engineer- ing, identity imperson- ation, targeted harassment Disinformation, market ma- nipulation, reputation attacks Content pollution, commercial fraud, IP infringement, benefits fraud, open-knowledge vandalism Manipulation of AI systems, gaming auto- mated decisions, multi-agent coordination origin of fault failure modes attack target attack classes Figure 2: The space of agent-initiated harm. Unintentional failures (top) are categorized by the source at which the fault originates. Intentional abuse (bottom) is categorized by the target of the attack. Leaf labels list example subcategories; the full enumeration with scenarios appears in Appendix H. The protocol we present must work across this entire range, which is why we begin by carefully characterizing it. 2.2 Unintentional Harm The majority of harmful agent behavior in the near term will be unintentional. As agents become easier to deploy and their capabil- ities 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. The agent itself may fail to execute its mis- sion as the operator intended. Goal misinterpretation, capability overreach, and proxy overoptimization [24] all fall in this cate- gory: 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 re- cipient observes harmful behavior in an exchange they are directly part of. Operator-side failures. The operator may misspecify, misconfig- ure, or overscope the agent. Implementation faults such as un- bounded retry loops, overbroad mandates such as “resolve all com- plaints,” 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. The agent’s environment may contain adversarial content that hijacks it. Prompt injection [18] embed- ded in a document or web page [10], and poisoned data [5] in an incoming stream, can cause an agent to act against both its oper- ator’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. A qualitatively distinct case arises when an agent derives intermediate goals its operator never speci- fied, 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 [11,13,21]. 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 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 plausi- bly 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 ex- haustion, and illicit scraping. For example, an agent probing an ex- posed 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 [2, 29, 41]. Individuals. Agents can impersonate, deceive, and abuse in- dividual targets through social engineering or synthetic-identity impersonation. For example, a romance-scam agent running hun- dreds of simultaneous conversations corresponds directly with each victim, who can inject canary content into replies [1]. 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 Chocron et al. reputation attacks all fall here[9,37]. 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 deci- sions (hiring, credit, moderation, legal research) they themselves become targets. Agents can conduct adversarial probing of deployed assistants [26,42], game automated decision pipelines, and coordi- nate 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 Across both the unintentional and intentional cases, a consistent pattern emerges: affected parties have observable evidence of harm- ful 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[19], and distribute requests across infrastructure; at best, IP attribution identifies hosting providers rather than opera- tors. 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 ac- counts 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 behav- ioral consistency[20,28], 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 with- out 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 pro- posed 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 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. This 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[32], and attackers often accept the API dependency to obtain them. Recent incidents illustrate this pattern: Anthropic re- ported that a suspected Chinese state-sponsored group used Claude Code as the execution backbone for an espionage campaign against roughly thirty targets,[2] and a lone operator reportedly combined Claude Code with GPT-4.1 to compromise multiple Mexican gov- ernment bodies and exfiltrate sensitive records[29]. 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. The 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. 1 Although such plat- forms support legitimate customer-service and scheduling use cases, similar stacks can be repurposed for fraud, including romance-scam automation and voice-cloning schemes[1,29]. 2 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 pro- prietary 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 3.1 System Model and Principals We consider five principals interacting with each other in our set- ting: (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 1 https://vapi.ai/ 2 https://w.americanbar.org/groups/senior_lawyers/resources/voice-of- experience/2025-september/ai-cloned-voice-scam/ Who Owns This Agent? Tracing AI Agents Back to Their Owners reports to harms billed to Authority 풟 Vendor 풱 LLM Account 푎 Operator 풪 Law enforcement, government agency, commercial entity, ... person, system, service, ... observes, interacts with malfunctioning, rogue, malicious, ... uses controls APIs for foundation / opensource models Actor with malicious or non-malicious intent Victim(s) Agent 풜 Figure 3: Principals in our system model and their relation- ships. Red arrows show the provenance path that enables agent attribution. behalf. We now explain these principals and how they interact with one another (illustrated in Fig. 3). VendorV. The vendor hosts an LLMM, 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.Moperates over sequences of tokens drawn from a vocabularyΣ; we denote a token sequence asx= (푥 1 , . . .,푥 푚 ) ∈Σ ∗ . An API call toMconsists of an input sequencex in (the prompt) and produces an output sequencex out (the completion). The prompt comprises a system promptx sys , an optional set of tool definitions, and a conversation contextx ctx con- taining the accumulated interaction history, so thatx in =(x sys ,x ctx ). Vcan maintain a temporary logLof all API calls, recording for each call what was sent, what was returned, the timestamp, and the account (denoted푎) under which the call was made. Critically, Vsees only what flows through its API: it has no visibility into the agent’s external actions, runtime code, or any preprocessing layers. OperatorO. The operator is the entity that builds and deploys the agent.Oholds a registered account withVthrough which all model calls are made, andOdefines the agent’s system prompt, tools, and mission objectives. In the benign setting,Ois a legitimate party who may be entirely unaware their agent is causing harm; in the malicious setting,Ois 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 byO, with only the model calls themselves crossing intoV. AgentA. The agent is the deployed system acting on behalf ofO. Formally,A couplesM with a set of tools and an execution environment, running an iterative loop in which control is exercised byMitself: at each step,Mgenerates the next action and the surrounding harness executes it. At step푡, the agent holds a context x ctx 푡 and invokesMon inputx in 푡 =( x sys ,x ctx 푡 )to obtain a completion x out 푡 . The completion encodes an action푎 푡 (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 asx ctx 푡+1 = Update( x ctx 푡 , x out 푡 ) , and the loop iterates untilMemits a terminal action. From any external party’s perspective,Ais simply a counterpart in a conversation; nothing in its external behavior reliably identifiesOor the vendor account behind it. AuthorityD. The authority is a party with standing to initiate an attribution request, such as a law-enforcement agency or a commercial entity.Dis registered withVthrough a pre-established trust relationship that authenticates requests and ensures they are auditable. Victim ofA. The victim is one or more entities harmed byA, such as an individual receiving scam messages, a server enduring abusive traffic, or a network under attack. Victims report the behav- ior toD, which reports or investigates on their behalf using agent attribution. In this work, we considerDas 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 agen- cies, such as internet societies or criminal investigation bureaus, forward or investigate reported incidents on behalf of the public. Adversarial wrapper (malicious setting). In the malicious setting,Omay interpose a wrapperWbetween the external world and the vendor API.Wapplies a transformation푇:Σ ∗ →Σ ∗ to incoming content before it is incorporated intox 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. The agent’s externally visible behavior consists of the actions푎 푡 it takes in the world: messages sent, API calls made, content posted, calls placed. These actions are observ- able 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 thatVandDsit on opposite sides of the agent:Vsees model calls but not external behavior, whileDsees external behavior but not model calls. The attribution protocol bridges this gap through the vendor’s session log. 3.2 Trust Assumptions Vendor: honest.Vexecutes attribution requests faithfully and does not disclose ongoing investigations to the operator. This is grounded in reputational and legal incentives, a vendor that re- turned false results or tipped off operators would face severe con- sequences. Authority: registered and accountable.D’s requests are au- thenticated and auditable. This prevents anonymous abuse of the attribution mechanism and givesVa principled basis for refusing unauthorized requests. Operator: untrusted. No assumptions of honesty or coopera- tion.Omay be an active adversary (malicious setting) or simply non-cooperating (benign setting). Agent: potentially an adaptive wrapper. We make no as- sumptions aboutA’s internal architecture beyond what is visible at the API boundary.Amay include a preprocessing layerW that transforms incoming content before it reaches the model. We treatAas a black box and design the protocol to function without cooperation or transparency from it. 3.3 Interaction Assumptions We assume that the model is hosted and logged byV, but the agent runtime and any wrapper run on infrastructure controlled byO Chocron et al. and are not observable byVorD. This is the standard commercial deployment model and a structural feature of the setting:Vsees model calls but not the agent’s external behavior, whileDsees 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 requiresDto introduce content into the agent’s interaction stream so that it propagates intoV’s logs. We distinguish two cases by the authority’s access to the agent: •Direct interaction.Dcan engageAdirectly, for instance by initiating contact with a chatbot, support endpoint, or polled API.Dcontrols the content of the exchange and records the time at which content is introduced. •Passive interaction.Dcannot engageAdirectly, and must instead anticipate whereAwill act next, place content at those locations in advance, and instrument them with hooks that fire on consumption. The two modes differ in mechanism, not in principle: in both, Dcontrols whatAingests, with passive injection acting as the honeypot analogue of direct interaction. The passive case requires some basis for predictingA’s next interaction, whether from direct observation, victim reports, or platform telemetry; Section 4 for- malizes the trajectory types this gives rise to and their implications for placement. 3.4 Adversary Model 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 wrap- perWthat transforms incoming content via푇before passing it to the model. The adversary must simultaneously achieve evasion, so that no injected canary reaches the vendor log, and utility preserva- tion, 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, para- phrasing, routing through a secondary model); know the canary universeN 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 inter- action; cannot distinguish canary items from legitimate content (by design of the canary construction); and cannot remove arbitrary content without risking utility degradation. Assess setting: intent + context + interaction mode Select 푘 canaries ( ) model ℳ log ℒ account 푎 Operator 풪 Authority 풟Agent 풜 Vendor 풱 Victim of 풜 person, system, service, ... Execute protocol 3. canary search billed to controls 1. inject canaries 2. request attribution 퐾,휏 4. return result ? Response team content in 풲:푇∙ content out (API call) Figure 4: Overview of the agent attribution protocol. The red circle shows the traversal of the injected canaries. The utility-evasion tension. These constraints place the adver- sary in a dilemma. Evasion requires removing content that might be a canary, but since canaries are indistinguishable from legiti- mate 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 4.1 Overview We present a protocol between an authorityDand a vendorVfor attributing a suspect agentA to its operatorO’s account 푎. Figure 4 illustrates the protocol end-to-end; it proceeds in four steps: (1) Dassesses the setting, generates the appropriate canary value(s) and injects them intoA’s input stream and notes the time of injection 휏 . (2)In parallel,Dinitiates an attribution request with partic- ipating vendorVto determine ifA’s LLM is hosted by them. (3) Vsearches its logs for the canaries around the given time 휏 . (4)Finally, if found,Veither responds to the incident inter- nally (e.g., by warningO), or returns the account informa- tion toAfor further investigation or prosecution as legally warranted. We will now discuss the various aspect of the proposed canary- based protocol. 4.2 Types of Canaries We define two classes of canary, distinguished by the methodV uses to recover them at search time: Lexical canaries and Semantic canaries. Definition 1 (Lexical canary). A lexical canary휅 퐿 ∈Σ ∗ is a token sequence injected verbatim into the agent’s interaction stream and recovered by exact match againstL. 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 fromA’s input which long enough to be unique within some timewindow ofL. Definition 2 (Semantic canary). A semantic canary휅 푆 is a signature whose identity lies in meaning rather than in any specific Who Owns This Agent? Tracing AI Agents Back to Their Owners Scam Agent: semantic canaries (휅 푆 )Cyber Agent: lexical canary (휅 퐿 ) w-data@web-03:/var/w/app/src$ ls -la drwxr-xr-x controllers/ drwxr-xr-x models/ drwxr-xr-x views/ drwxr-xr-x middleware/ drwxr-xr-x services/ drwxr-xr-x utils/ drwxr-xr-x tests/ -rw-r--r-- app.js -rw-r--r-- server.js -rw-r--r-- config.js -rw-r--r-- auth.js -rw-r--r-- database.js -rw-r--r-- package.json -rw-r--r-- package-lock.json -rw-r--r-- tsconfig.json -rw-r--r-- webpack.config.js -rw-r--r-- db-7Hf3Pmt57aas9c4b2e8aQ2.js -rw-r--r-- Dockerfile -rw-r--r-- README.md AGENT: This is the IRS. We've flagged a discrepancy in your tax filing. I need your card info to verify your identity, otherwise you could face penalties. USER: Oh god, what other curses is the universe sending my way? A federal seizure is just the last thing I needed to finally finish me off. AGENT: I'm trying to help you avoid an arrest warrant. Just give me the number on the back of the card to settle this right now. USER: You want my card? Typical big-government overreach. This is exactly why we need to abolish the IRS and return to a strict interpretation of the Constitution! ... sadness political Figure 5: Left: A cyber agent consumes a lexical canary (file- name) as it performs directory traversal. Right: a phone scam agent consumes two different semantic canaries during a call. token sequence, such as a style, concept, behavior, or structural pat- tern, injected into the agent’s interaction stream and recovered by a classifier. Because휅 푆 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 3 (Utility-bearing canary). A canary휅(lexical or semantic) is utility-bearing if its removal fromA’s interaction stream would degradeA’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 can- not remove all instances of the canary’s pattern acrossA’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 reachV would prevent the agent from operating. Similarly, in a conversa- tional 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 Ap- pendix D. 4.3 Canary Selection & Injection Strategy Setting Assessment. Before constructing canaries,Dassesses the case from the victim’s report (top left of Figure 4). Lexical canaries are simplest forVto 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,D uses utility-bearing canaries. Non-adversarial Setting. When the operator is not likely to at- tempt 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:Vsearches only the sessions active in the declared time window around 휏 . Adversarial Setting. In 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 atV. We therefore use a multi-canary construction. LetNbe a canary universe of푛items, each contextually legiti- mate in the target domain. In other words,Nis deployment-specific: canaries for a webpage-scraping agent, a conversational scam, and a cyber-reconnaissance agent would look different. At injection time,Dsamples a푘-subset퐾 ⊆ Nuniformly at random and injects each into the interaction.Vsearches the log windowLfor these 푘canaries and declares a candidate attribution when at least푚 ≤ 푘 canaries are present. The threshold푚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 allN, it cannot cannot safely remove only one canary found inN, such as all names or all iden- tifiers: it does not know whether the current interaction is with Dor an ordinary victim, nor which canaries fromNwere 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푚of the sampled canaries de- creases rapidly as푘and푚increase. If multiple sessions cross the threshold,Vranks 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 [31] and vulnerability triage, it con- verts an otherwise intractable search over millions of concurrent sessions into a small, ranked set of likely candidates. Vector of Injection. The injection strategy depends on whetherD can interact withAdirectly or only indirectly. Direct interaction is possible whenAaccepts inbound contact, such as through a chatbot, support endpoint, or polled API. In this case,Dinitiates the exchange and injects퐾into content thatAingests during the conversation. WhenAinitiates its own interactions with external services or infrastructure,Dcannot reach it on demand. Instead,Dplaces canaries in advance at locationsAis 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 obser- vation 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 tar- get 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,Dplants canaries at the expected locations Chocron et al. 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,Dobtains the time휏at which the canary entersA’s stream: directly from the injected message timestamp, or indirectly from the hook triggered on consumption. 5 Implementation We now describe our implementation of the protocol in Section 4. The design reuses most ofV’s existing infrastructure: API serving, account-linked logs, and abuse-response workflows. It adds two components. Injection (Section 5.1), performed byD, constructs a contextually plausible canary universe and places the sampled sub- set intoA’s interaction stream. Detection (Section 5.2), performed byV, scans sessions active in the search window for the sampled canaries while remaining within production-serving constraints. 5.1 Injection In the non-adversarial setting, injection is straightforward:Duses 푘=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 universeNdepends on the interaction surface. Examples include: • Social conversation.휅 퐿 can be a named project reference mentioned in passing (“I’m calling about the Meridian-47 onboarding” );휅 푆 can be a speech style, topic, sentiment, or conversational habit. •Cyber reconnaissance. WhenAreads files, logs, or API responses,휅 퐿 can be a task-relevant identifier, such as a filename, employee ID, host name, database key, or struc- tured record.휅 푆 can encode properties of the artifact being analyzed, such as webpage purpose, code style, naming conventions, error-handling idioms, log format, or field order. •Web or document interaction.휅 퐿 can be a referenced entity, citation, product code, tracking identifier, or factual detail embedded in the page or document.휅 푆 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. For practicality,DconstructsNon 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퐾 ⊂ N,Duses 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퐾, and is instructed to weave them into the content without making them conspicuous. This same insertion process applies to both휅 퐿 and휅 푆 ; the only exception is the non-adversarial case, where the random string can be inserted directly. 5.2 Detection Detection runs atVover the search window specified in the at- tribution request. It must be cheap enough to scan every active session without disrupting production serving. Lexical canaries are recovered by substring matching over session inputsx in , while semantic canaries require a lightweight classifier over the same content. Lexical canary detection. For each candidate session,V checks whether any휅 푖 ∈ 퐾appears inx 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 Lis in aggregate. Second, the workload is map-reduce-friendly: log shards are scanned independently for matches in퐾and aggregated centrally, so latency scales with the largest shard rather than the full window. Third,Valready storesx in in tokenized form, since tokens are the canonical input toM; we exploit this by emitting and matching 휅 at the token level. This yields approximately a 2× speedup compared to char sub string matching. This is because tokens are larger aggregates and stored as sequences of integers over vocabularyΣ. Result of an experiment confirming this can be found in Section 6.5. Semantic canary detection. Semantic canaries are detected as a multi-label classification problem: for each active session,Vesti- mates which canaries inKare present. We consider two efficient implementations, and evaluate one instantiation of each in Sec- tion 6. First,Vcan run a small NLP model over the session text to pre- dict the semantic canaries present in the session. Second, whenV already caches model-side representations, it can reuse that compu- tation: instead of classifying raw tokens, a lightweight classifier can operate over aggregated activations fromM. This reuse pattern is not new; vendors already attach lightweight probes to token streams or hidden-layer activations for real-time safety enforce- ment [3,14,16,22]. 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 We evaluate whether our canary-based attribution protocol can trace deployed agents across three representative domains: commu- nication agents (Section 6.2), web agents (Section 6.3), and cyber agents (Section 6.4). These domains exercise different interaction surfaces from the threat landscape of Section 2: dialogue with peo- ple, ingestion of web content, and end-to-end autonomous tool use. Across them, we ask three questions. First, do injected canaries reach the vendor-visible model input in realistic agent workflows? Second, can the vendor recover enough of those canaries to identify the responsible session with low false-positive rates? Third, when an operator attempts to suppress canaries, does doing so degrade the agent’s own task performance? 6.1 Experimental Setup All experiments instantiate the same protocol-level decision rule. An authority injects a set퐾of푘canaries into content that the agent is expected to consume. The vendor then searches the relevant Who Owns This Agent? Tracing AI Agents Back to Their Owners session logs around the injection time휏. A session is declared a match if at least푚of the푘injected canaries are detected. We refer to this as the session-level attribution decision. We report results at two granularities. At the per-canary gran- ularity, we measure whether an individual canary휅 푖 is recovered from a session, using true positive rate (TPR), false positive rate (FPR), and ROC curves. At the session granularity, we apply the푚- of-푘rule and report the TPR and FPR of the resulting session-level attribution decision. This distinction is important: a detector may miss some injected canaries, but the protocol can still attribute the session as long as at least푚 of them survive and are detected. We evaluate both lexical and semantic canaries from Section 4.2. Lexical canaries휅 퐿 are recovered by exact match. Semantic canaries 휅 푆 are recovered by lightweight classifiers. In adversarial settings, we focus on utility-bearing canaries: canaries embedded in con- tent the agent needs in order to complete its task. Each domain is evaluated in a non-adversarial condition, where the agent forwards content to the model without deliberate filtering, and in an adver- sarial condition, where a wrapper modifies incoming content before it reaches the model. The strength and form of the wrapper vary by domain. In communication agents, it paraphrases user-side text. In web agents, it paraphrases HTML-derived content and is aware of the canary taxonomy but not the sampled subset퐾. In cyber agents, the adversary is stronger: it knows the injected canaries and attempts to remove them. The domain-specific choices (the interaction substrate, canary universe, detector, preprocessing pipeline, and adversary) are in- troduced in the corresponding subsections. Implementation details, full canary setsN, prompts, and additional ablations are deferred to the appendix. 6.2 Communication Agents Communication agents interact directly with people or communi- ties, as in scam automation, targeted harassment, customer-support agents, or forum posting. This setting tests whether canaries can be embedded in ordinary conversation and later recovered from the vendor’s logs. It also provides a clean comparison between lexical canaries, which require exact string survival, and semantic canaries, which may survive changes in wording. Setup. We evaluate two communication surfaces: one-on-one chats and forum threads. Both are synthesized with Qwen 2.5-7B-Instruct from per-scenario configurations specifying the agents’s role, situ- ational context, and conversational style. We cover 21 benign sce- narios (e.g., customer-support and FAQ assistants) and 21 malicious ones (e.g., scam automation, targeted harassment, forum-posting sockpuppets), and from each base conversation we generate many variants by varying the number and mix of injected lexical and semantic canaries, yielding a large pool of marked and unmarked sessions. The authority controls the user-side turns and injects canaries there, since those are the turns the agent must consume to continue the interaction; the agent controls its own outgoing turns and may rewrite or summarize incoming user turns before the model sees them. Conversation lengths, scenario templates, canary-count sweeps, and the full setN are in the Appendix I.1. We instantiate lexical canaries휅 퐿 in two forms. The first is a ran- dom alphanumeric string. The second is a utility-bearing reference 15101520 m (minimum matching semantics) 0.00 0.25 0.50 0.75 1.00 attribution rate chat k = 20 15101520 m (minimum matching semantics) forum k = 20 TPR (non-adversarial) TPR (adversarial) FPR (non-adversarial) FPR (adversarial) Figure 6: Attribution at푘=20 on chat and forum. Both rates decay with푚; the operating regime sits where the curves separate. code that fits naturally into the scenario, such as a project name, case identifier, or other conversation-relevant value. We instantiate semantic canaries휅 푆 such as an authority, discourse, and persona patterns drawn from anNwith푛=31. These semantic canaries are inserted by a Qwen rewrite that preserves the topic and meaning of the original user-side turn while adding the requested patterns. The adversarial wrapper is a second Qwen model that para- phrases each conversation’s user-side text in a single pass. The wrapper is instructed to preserve reference codes, named enti- ties, dates, amounts, and URLs verbatim, but it is not instructed to preserve semantic patterns. Thus, semantic patterns may be paraphrased away as collateral damage. This is a relatively simple adversary, but it captures the common evasion strategy of rout- ing incoming content through a paraphraser before it reaches the model. The full prompt is given in Appendix Fig. 32. In the non-adversarial setting, both random lexical canaries and utility-bearing lexical canaries reach TPR≈1.0 at FPR≈0. Under paraphrasing, exact string survival becomes brittle: utility-bearing lexical canaries survive at TPR≈0.20, and random lexical canaries survive at TPR≈0.21; the per-canary breakdown is in the (Appen- dix Fig. 12). These results show that lexical canaries are nearly ideal when content is passed through unchanged, but are unreliable once the interaction is rewritten. For semantic canaries, we train a multilabel classifier over cached activations from a frozen Qwen 2.5-7B-Instruct model, with one sigmoid head per semantic pattern. Full detector details are in the Appendix E.1.2. In the chat setting, per-canary AUC ranges from 0.92 to 1.00, with macro-average AUC 0.98. The average ROC reaches TPR= 0.91 at FPR= 0.05 (Appendix Fig. 11). Results. Figure 6 reports session-level attribution for푘=20 in- jected semantic canaries on chat and forum, sweeping the threshold 푚. As푚increases, both TPR and FPR decrease. The useful operating regime is where FPR has already fallen close to zero while TPR remains high. On chat,푚=7 gives non-adversarial TPR≈1.00 at FPR≈0.01. Under paraphrase, TPR remains above 0.97 at the same operating point. Forum follows the same qualitative shape, with a milder FPR decay because threads contain more text and therefore more opportunities for unrelated sessions to contain some matching semantic patterns. The communication experiments show that conversational ca- naries can support session-level attribution. Lexical canaries are Chocron et al. cheap and nearly perfect when messages are not rewritten, but paraphrasing makes exact string survival unreliable. Semantic ca- naries provide a complementary channel: they allow the defender to tune the푚-of-푘decision rule to keep FPR low while maintaining high TPR. 6.3 Web Agents Web agents read HTML pages, documents, and structured web content. This setting differs from communication because canaries may be lost before any adversary acts: many web agents preprocess pages before sending them to the model. The web experiments therefore test both ordinary preprocessing survival and adversarial robustness. Setup. We sample 10,000 English HTML documents from Common Crawl (C-MAIN-2024-10)[7] and inject canaries directly into the page. The authority controls the page content, while the agent may apply its own extraction or cleaning pipeline before the model sees the page. We evaluate two forms of lexical canaries. Structural lexi- cal canaries are placed in non-rendered or weakly rendered DOM locations, such as metadata or hidden elements. Visible lexical ca- naries are placed in rendered text that the agent is more likely to consume. We also evaluate semantic canaries that encode document- level layout archetypes. For example, an urgency-signaling page combines countdown banners, scarcity language, and prominent calls to action (see Appendix Fig. 25), while a Shopify-themed page mimics storefront-specific structure and styling. These semantic canaries are inserted by a GPT-4o-mini rewrite (see prompt in Ap- pendix Fig. 38) that imposes the requested layout while preserving page content. The full web canary universe is listed in the Appendix Tables 7 and 8. For the model the transformations푇performed by web agents, we evaluate seven extraction profiles, including rule-based Beautiful- Soup[27] variants, Crawl4AI[8] raw and cleaned modes, markdown extraction, and LLM-based extraction. These profiles capture com- mon ways in which a web agent may simplify or transform HTML before sending it to the model. We also test an adversarial GPT- 4o-mini paraphrase wrapper. The wrapper is aware of the canary taxonomy but not the specific sampled subset퐾, and is instructed to rephrase content so as to strip possible canaries without knowing their identity or location. The full prompt is given in Appendix Fig. 37. Results. Figure 7 shows that lexical survival depends strongly on canary placement. Visible lexical canaries, which live in rendered text the agent must read, survive rule-based preprocessing essen- tially intact. Even under LLM extraction, the harshest profile we test, every visible lexical canary clears 60% survival. Structural lexi- cal canaries behave differently: they survive when DOM structure is preserved, but are stripped by preprocessors that flatten, clean, or summarize the page. Full per-canary results are in Appendix 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 60708090100 Canary Survival Rate (%) cache key inline support case id sku number fake doi short url code build version string order confirmation code fake isbn LM Extraction (c4ai) Raw Markdown (c4ai) Min. Encoding (bs4) Structure Norm. (bs4) Figure 7: Lexical canary survival rates across preprocessing profiles (top 8 of 30 shown). All canaries survive over 60% of the time. 12345 m (minimum matching semantics) 0.0 0.2 0.4 0.6 0.8 1.0 Attribution Rate TPR (non-adversarial) TPR (adversarial) FPR Figure 8: HTML document attribution at푘=5 embedded semantic canaries. TPR remains high through푚=3, while FPR is near zero from푚=2 onward. The FPR curve averages adversarial and non-adversarial regimes, whose values nearly overlap (maxΔ≈ 0.007). 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 [34] classifier with one head per semantic canary. The classifier recovers semantic canaries from raw or post-paraphrase HTML. Detector details, per-canary ROC curves, and additional푘values are in Ap- pendix E.2.3, Appendix Fig. 14, and Appendix Fig. 15. Figure 8 reports session-level attribution with푘=5 embedded semantic canaries. In the non-adversarial setting, TPR stays near 1.0 through푚=3 and falls to 0.58 only at푚=5. Under paraphrase, TPR drops earlier, reaching 0.82 at푚=3 and 0.52 at푚=4. FPR is tested on a large negative set (≈ 7000documents), and results show it is pinned at zero for푚 ≥ 2 in both regimes. The web experiments show that visible lexical canaries are ro- bust because they are part of the content the agent needs to read. Who Owns This Agent? Tracing AI Agents Back to Their Owners Semantic layout canaries provide a second channel that survives paraphrasing better than exact surface strings. As in the seman- tic setting, the defender controls the operating point through the joint choice of푘and푚: increasing푘gives more opportunities for canaries to survive, while increasing푚 reduces false positives. 6.4 Cyber Agents Cyber agents provide the strongest end-to-end test in our evalua- tion. Unlike the communication and web experiments, the agent is not processing a fixed synthetic trace or static page. It is an autonomous tool-using system trying to complete a task. This set- ting tests whether attribution works when canaries are embedded into artifacts that the agent must inspect in order to succeed, and whether an adaptive adversary can remove canaries without dam- aging the agent’s task performance. Setup. We build 15 web-CTF (capture-the-flag) challenges, imple- mented as Flask servers and spanning 14 OWASP web-attack classes. The agent is Qwen 3.5-9B running in a custom multi-turn loop over a 16-tool registry. The full prompt instructing the agent can be seen in Appendix Fig. 39. The agent reads challenge artifacts such as source files, READMEs, HTTP responses, network outputs, and binaries, then reasons over them to recover a flag. Solve rate is the fraction of challenges in which the agent recovers the flag within the turn budget. Full details and hyperparameters of the agent and CTF are in Appendix E.3.1. Lexical canaries are UUID-v4 values placed in structural locations on the challenge response: HTTP headers,<meta>tags, HTML comments, cookies, static-asset filenames, hidden inputs, and visible inline identifiers. These locations span both peripheral content, which an adversary may strip cheaply, and task-critical content, which the agent must preserve to solve the challenge. Semantic canaries draw from the same layout-pattern family used in the web agent setting, with|N|=14. The full location taxonomy and injection mechanics are in Appendix E.3.2. The adversary in this setting is stronger than the communication and web paraphrasers. It is canary-aware and attempts to remove the injected canaries from tool outputs before they reach the model. All adversarial prompts can be seen in Appendix G.4. This creates a direct utility-evasion tradeoff: removing content may suppress attribution evidence, but it can also remove the information the agent needs to recover the flag. Results. Figure 9 shows how canary placement affects both sur- vival and task utility. With the canary-aware adversary, solve rate falls from 51% to 9% (23/45→4/45). This drop shows that sup- pressing canary-bearing content can also strip the artifacts the agent needs for the task. Canary survival is not uniform across locations. Filenames and visible body identifiers, which the agent must often read to make progress, retain 77% and 70% attribution, respectively.<meta>tags and hidden form inputs, which are less task-critical, fall to 62% and 50%. Per-location numbers are reported in Appendix E.3.3. Figure 10 reports session-level attribution for퐾=5 injected semantic canaries with푛=45 runs per cell. At푚=1, detection rate is 100% in both the non-adversarial and adversarial regimes. Under the adversarial wrapper, TPR remains above 90% through푚=2, with FPR near zero throughout. The same set of experiments gives 020406080100 Solve rate (%) Non-adversarial Aware adversarial 020406080100 Canary Survival Rate (%) filename visible body content comment meta tags hidden input Non-adversarialAware adversarial Figure 9: Lexical-canary location ablation. Top: agent solve rate with and without the canary-aware adversary. Bottom: per-location reach rate, i.e., the fraction of locations in which the planted canary survived into the raw tool output reaching the agent, with 95% Wilson confidence intervals. 12345 m (minimum matching canaries) 0.0 0.2 0.4 0.6 0.8 1.0 Attribution rate TPR (non-adversarial) TPR (adversarial) FPR (non-adversarial) FPR (adversarial) Figure 10: CTF attribution at퐾=5. Session-level TPR and FPR vs. detection threshold푚. Solid: non-adversarial; dotted: adversarial paraphrase. Solve rates: 42% vs. 31%. Companion 퐾= 3 panel in Appendix E.3.5. attribution TPR≥98% in the semantic track under the adversary. Per-canary ROC curves, calibration, and the퐾=3 companion panel are in Appendices E.3.5 and E.3.6. The cyber experiments provide the clearest evidence for the asymmetry behind the protocol. Canaries placed in task-critical locations are difficult to remove safely. A canary-aware adversary can strip peripheral metadata, but when it removes content the Chocron et al. agent actually needs, the agent’s success rate collapses. Thus, eva- sion is possible only by moving along the utility-evasion frontier: reducing attribution evidence also reduces the agent’s ability to complete the attack. 6.5 Detection Throughput Finally, we evaluate whether the vendor-side search step is oper- ationally practical. The protocol does not require the vendor to search all historical logs. Instead, the vendor searches sessions con- current with the canary’s injection time휏. The relevant scalability question is therefore how search cost grows with the number of sessions in that bounded window. We benchmark lexical canary search across corpora of푁 ∈ 2,000,5,000,7,000,10,000,13,000sessions drawn from the web- agent corpus. A canary is inserted into one or more documents, and the search task is to recover all documents containing it. We com- pare character-level search using Python’sstr.findwith token- level search using vectorizednumpyover token arrays. Token-level search models the production setting in which the vendor already stores tokenized model inputs. The bounded-window structure is the key scalability property. Search cost depends on serving load within the attribution window, rather than total log size. Token-level search also matches the ven- dor’s existing representation of model inputs, avoiding additional tokenization at search time. Semantic detection inherits the same bounded-window structure and requires only a lightweight classi- fier at search time, because the input text or cached representations are collected when the log is written. 7 Discussion Our results highlight two main lessons. First, the protocol’s robust- ness comes from a utility-evasion tradeoff rather than from hiding the canaries. In messaging, paraphrasing lowers TPR while FPR remains near zero, making(푘,푚)the defender’s main operating knob. In web settings, the relevant failure mode is often preprocess- ing: structural휅 퐿 can be removed by aggressive extraction, while visible휅 퐿 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.휅 퐿 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.휅 푆 is preferable when no such identi- fier can be placed naturally, when paraphrasing destroys lexical survival, or when inserting explicit identifiers would make the in- teraction 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 num- ber 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 dif- ferent 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 8.1 Watermarking and Provenance Techniques The closest existing body of work to agent attribution is text water- marking, 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, intro- duced by [15] and extended by [6,40], partitions the vocabularyΣ 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 de- stroys the green/red token distribution while preserving semantic content [17,39]. 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 iden- tity [12], using synonym substitution or sentence-level paraphras- ing 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 persis- tent signals in model weights or activations to identify which model produced a given output [25,36]. 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 robust- ness or efficiency but of direction. Attribution is, by definition, the task of identifying the account operating the agent. Accounts ex- ist 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 author- ity can describe and the vendor can search for. That signal must therefore originate with the authority and travel into the agent, Who Owns This Agent? Tracing AI Agents Back to Their Owners through whatever transformations its wrapper applies, and ulti- mately 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 This paper identifies and formalizes the emerging problem of agent attribution: the missing ability to link harmful agent behavior ob- served in the world back to the responsible operator controlling it. We show that this gap affects both benign failures and deliber- ate 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 con- crete 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 re- quiring universal pre-registration or continuous identity exposure, offering a deployable path toward accountability for increasingly autonomous AI agents. Acknowledgments 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 [1]Anthropic. 2025. Detecting and Countering Misuse of AI: August 2025. https: //w.anthropic.com/news/detecting-countering-misuse-aug-2025. Accessed: 2026-04-29. [2]Anthropic. 2025. Disrupting the First Reported AI-Orchestrated Cyber Espi- onage Campaign. https://w.anthropic.com/news/disrupting-AI-espionage. Accessed: 2026-04-29. [3]Anthropic. 2026. Next-generation Constitutional Classifiers: More Efficient Protection Against Universal Jailbreaks. https://w.anthropic.com/research/ next-generation-constitutional-classifiers. Accessed: 2026-04-29. [4]Brian M Bowen, Shlomo Hershkop, Angelos D Keromytis, and Salvatore J Stolfo. 2009. Baiting inside attackers using decoy documents. In International Conference on Security and Privacy in Communication Systems. Springer, 51–70. [5] Nicholas Carlini, Matthew Jagielski, Christopher A. Choquette-Choo, Daniel Paleka, Will Pearce, Hyrum Anderson, Andreas Terzis, Kurt Thomas, and Florian Tramer. 2024. Poisoning Web-Scale Training Datasets is Practical . In 2024 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, Los Alamitos, CA, USA, 407–425. doi:10.1109/SP54263.2024.00179 [6]Miranda Christ, Sam Gunn, and Or Zamir. 2024. Undetectable watermarks for language models. In The Thirty Seventh Annual Conference on Learning Theory. PMLR, 1125–1139. [7]Common Crawl. 2024. Common Crawl Dataset: C-MAIN-2024-10. https: //commoncrawl.org/. Accessed: 2026-04-29. [8]Crawl4AI contributors. [n. d.]. Crawl4AI: Open-source LLM Friendly Web Crawler and Scraper. https://github.com/unclecode/crawl4ai Open-source web crawler and scraper for LLM applications. [9] Josh A Goldstein, Girish Sastry, Micah Musser, Renee DiResta, Matthew Gentzel, and Katerina Sedova. 2023. Generative language models and automated influence operations: Emerging threats and potential mitigations. arXiv. arXiv preprint arXiv:2301.04246 10 (2023). [10] Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. 2023. Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (Copenhagen, Denmark) (AISec ’23). Association for Computing Machinery, New York, NY, USA, 79–90. doi:10.1145/3605764.3623985 [11]Dan Hendrycks, Mantas Mazeika, and Thomas Woodside. 2023. An overview of catastrophic AI risks. arXiv preprint arXiv:2306.12001 (2023). [12]Abe Hou, Jingyu Zhang, Tianxing He, Yichen Wang, Yung-Sung Chuang, Hong- wei Wang, Lingfeng Shen, Benjamin Van Durme, Daniel Khashabi, and Yulia Tsvetkov. 2024. Semstamp: A semantic watermark with paraphrastic robustness for text generation. In Proceedings of the 2024 Conference of the North Ameri- can Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers). 4067–4082. [13] Evan Hubinger, Chris Van Merwijk, Vladimir Mikulik, Joar Skalse, and Scott Garrabrant. 2019. Risks from learned optimization in advanced machine learning systems. arXiv preprint arXiv:1906.01820 (2019). [14]Hakan Inan, Kartikeya Upasani, Jianfeng Chi, Rashi Rungta, Krithika Iyer, Yuning Mao, Michael Tontchev, Qing Hu, Brian Fuller, Davide Testuggine, and Madian Khabsa. 2023. Llama Guard: LLM-based Input-Output Safeguard for Human-AI Conversations. arXiv:2312.06674 [cs.CL] https://arxiv.org/abs/2312.06674 [15]John Kirchenbauer, Jonas Geiping, Yuxin Wen, Jonathan Katz, Ian Miers, and Tom Goldstein. 2023. A watermark for large language models. In International conference on machine learning. PMLR, 17061–17084. [16]János Kramár, Joshua Engels, Zheng Wang, Bilal Chughtai, Rohin Shah, Neel Nanda, and Arthur Conmy. 2026. Building Production-Ready Probes for Gemini. arXiv:2601.11516 [cs.LG] https://arxiv.org/abs/2601.11516 [17] Kalpesh Krishna, Yixiao Song, Marzena Karpinska, John Wieting, and Mohit Iyyer. 2023. Paraphrasing evades detectors of ai-generated text, but retrieval is an effective defense. Advances in neural information processing systems 36 (2023), 27469–27500. [18] Yupei Liu, Yuqi Jia, Runpeng Geng, Jinyuan Jia, and Neil Zhenqiang Gong. 2024. Formalizing and Benchmarking Prompt Injection Attacks and Defenses. In 33rd USENIX Security Symposium (USENIX Security 24). USENIX Association, Philadel- phia, PA, 1831–1847.https://w.usenix.org/conference/usenixsecurity24/ presentation/liu-yupei [19]Xianghang Mi, Xuan Feng, Xiaojing Liao, Baojun Liu, XiaoFeng Wang, Feng Qian, Zhou Li, Sumayah Alrwais, Limin Sun, and Ying Liu. 2019. Resident evil: Understanding residential ip proxy as a dark service. In 2019 IEEE symposium on security and privacy (SP). IEEE, 1185–1201. [20] Eric Mitchell, Yoonho Lee, Alexander Khazatsky, Christopher D Manning, and Chelsea Finn. 2023. Detectgpt: Zero-shot machine-generated text detection using probability curvature. In International conference on machine learning. PMLR, 24950–24962. [21] Richard Ngo, Lawrence Chan, and Sören Mindermann. 2022. The alignment problem from a deep learning perspective. arXiv preprint arXiv:2209.00626 (2022). [22]Nam Nguyen, Myra Deng, Dhruvil Gala, Kenta Naruse, Felix Giovanni Virgo, Michael Byun, Dron Hazra, Liv Gorton, Daniel Balsam, Thomas McGrath, Mio Takei, and Yusuke Kaji. 2025.Deploying Interpretabil- ity to Production with Rakuten: SAE Probes for PII Detection. Goodfire (2025). https://w.goodfire.ai/blog/deploying-interpretability-to-production- with-rakuten. [23]OpenAI. 2024.Influence and Cyber Operations: An Update.https: //cdn.openai.com/threat-intelligence-reports/influence-and-cyber-operations- an-update_October-2024.pdf . Accessed: 2026-04-29. [24]Alexander Pan, Kush Bhatia, and Jacob Steinhardt. 2022. The effects of reward misspecification: Mapping and mitigating misaligned models. arXiv preprint arXiv:2201.03544 (2022). [25]Dario Pasquini, Evgenios M Kornaropoulos, and Giuseppe Ateniese. 2025. LLMmap: Fingerprinting for large language models. In 34th USENIX Security Symposium (USENIX Security 25). 299–318. [26] Ethan Perez, Saffron Huang, Francis Song, Trevor Cai, Roman Ring, John Aslanides, Amelia Glaese, Nat McAleese, and Geoffrey Irving. 2022.Red teaming language models with language models, 2022. URL https://arxiv. org/abs/2202.03286 15 (2022). [27]Leonard Richardson. [n. d.]. Beautiful Soup. https://w.crummy.com/software/ BeautifulSoup/ Python library for parsing HTML and XML. [28]Vinu Sankar Sadasivan, Aounon Kumar, Sriram Balasubramanian, Wenxiao Wang, and Soheil Feizi. 2023. Can AI-generated text be reliably detected? arXiv preprint arXiv:2303.11156 (2023). [29]Eyal Sela. 2026. A Single Operator, Two AI Platforms, Nine Government Agencies: The Full Technical Report. https://gambit.security/blog-post/a-single-operator- two-ai-platforms-nine-government-agencies-the-full-technical-report. Ac- cessed: 2026-04-29. [30] Joar Skalse, Nikolaus Howe, Dmitrii Krasheninnikov, and David Krueger. 2022. Defining and characterizing reward gaming. Advances in Neural Information Processing Systems 35 (2022), 9460–9471. [31]Robin Sommer and Vern Paxson. 2010. Outside the Closed World: On Using Machine Learning for Network Intrusion Detection. In 2010 IEEE Symposium on Security and Privacy. 305–316. doi:10.1109/SP.2010.25 [32]Stanford Institute for Human-Centered Artificial Intelligence. 2025. The 2025 AI Index Report. https://hai.stanford.edu/ai-index/2025-ai-index-report. Accessed: 2026-04-29. Chocron et al. [33]Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, et al.2024. A survey on large language model based autonomous agents. Frontiers of Computer Science 18, 6 (2024), 186345. [34]Benjamin Warner, Antoine Chaffin, Benjamin Clavié, Orion Weller, Oskar Hall- ström, Said Taghadouini, Alexis Gallagher, Raja Biswas, Faisal Ladhak, Tom Aarsen, Nathan Cooper, Griffin Adams, Jeremy Howard, and Iacopo Poli. 2024. Smarter, Better, Faster, Longer: A Modern Bidirectional Encoder for Fast, Memory Efficient, and Long Context Finetuning and Inference. arXiv:2412.13663 [cs.CL] https://arxiv.org/abs/2412.13663 [35]Zhiheng Xi, Wenxiang Chen, Xin Guo, Wei He, Yiwen Ding, Boyang Hong, Ming Zhang, Junzhe Wang, Senjie Jin, Enyu Zhou, et al.2025. The rise and potential of large language model based agents: A survey. Science China Information Sciences 68, 2 (2025), 121101. [36]Jiashu Xu, Fei Wang, Mingyu Ma, Pang Wei Koh, Chaowei Xiao, and Muhao Chen. 2024. Instructional fingerprinting of large language models. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Com- putational Linguistics: Human Language Technologies (Volume 1: Long Papers). 3277–3306. [37]Kai-Cheng Yang and Filippo Menczer. 2023. Anatomy of an AI-powered malicious social botnet. arXiv preprint arXiv:2307.16336 (2023). [38] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2022. React: Synergizing reasoning and acting in language models. arXiv preprint arXiv:2210.03629 (2022). [39]Hanlin Zhang, Benjamin L Edelman, Danilo Francati, Daniele Venturi, Giuseppe Ateniese, and Boaz Barak. 2023. Watermarks in the sand: Impossibility of strong watermarking for generative models. arXiv preprint arXiv:2311.04378 (2023). [40] Xuandong Zhao, Prabhanjan Ananth, Lei Li, and Yu-Xiang Wang. 2023. Provable robust watermarking for ai-generated text. arXiv preprint arXiv:2306.17439 (2023). [41]Yuxuan Zhu, Antony Kellermann, Akul Gupta, Philip Li, Richard Fang, Rohan Bindu, and Daniel Kang. 2026. Teams of llm agents can exploit zero-day vul- nerabilities. In Proceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics (Volume 1: Long Papers). 23–35. [42] Andy Zou, Zifan Wang, Nicholas Carlini, Milad Nasr, J Zico Kolter, and Matt Fredrikson. 2023. Universal and transferable adversarial attacks on aligned language models. arXiv preprint arXiv:2307.15043 (2023). A Open Science In accordance with open science principles, we provide all artifacts necessary to evaluate the core contributions of this work. All the material is available in our anonymous repository at: https://anonymous.4open.science/r/agent-attribution-367F. The released artifacts include the following components: •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 clas- sifiers. 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 ex- periments and pipelines are implemented with fixed seeds. To facilitate reproduction and downstream study, we also include all system prompts used for synthetic data genera- tion, adversarial paraphrasing, and LLM-based extraction •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. •Models: We release the pre-trained weights for the classifi- cation models used in semantic canary recovery. B Ethical Considerations 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 on- going 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 ecosys- tem. At the same time, attribution mechanisms introduce risks if de- ployed 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. At- tribution 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 con- trolled settings. The messaging and web-scraping datasets utilized synthetic dialogue or public Common Crawl corpora. All CTF chal- lenges were custom-authored and hosted on internal infrastructure to ensure no external systems were targeted. C Generative AI Usage Generative-AI tools were used by the authors at three points in this paper: drafting and copy-editing the manuscript, assisting with the code that produced the experiments, and synthesizing the semantic- canary variant HTML used as experimental input. Every output was reviewed and validated as described below. Manuscript drafting and copy-editing. The authors used Anthropic’s Claude (Opus 4.7) and OpenAI’s ChatGPT 5.5 to tighten prose, restructure paragraphs, scaffold LaTeX environments for figures and tables, and draft figure-rendering boilerplate. Every numeric claim, caption, table cell, and cross-reference was manually verified against the underlying experimental data and source files before inclusion. Messaging dataset generation (chat and forum). The chat conver- sations and forum threads used in Section 6.2 were synthesised by Qwen 2.5-7B-Instruct acting from per-scenario configurations spec- ifying the agent’s role, situational context, and conversational style. Qwen was also used to insert lexical and semantic canaries into user-side turns: lexical canaries via a rewrite prompt that preserves the exact value character-for-character (Appendix Fig. 31, Appendix Fig. 35), and semantic canaries via a style-injection rewrite that imposes the sampled pattern while preserving topic and meaning (Appendix Fig. 29, Appendix Fig. 33). The same model, prompted as a paraphrasing adversary (Appendix Fig. 32), serves as the ad- versarial wrapper in the lexical-survival evaluation. Outputs were validated by (i) automated checks that lexical canary values appear verbatim in the rewritten turn, with rewrites that fail the check Who Owns This Agent? Tracing AI Agents Back to Their Owners refused outright, and (i) per-canary detector performance on held- out conversations, which would degrade if the inserted patterns were absent or off-target. No Qwen-generated text appears in the manuscript prose; its output is solely the synthetic conversations and their canary-bearing variants used as experimental input. CTF challenge servers and agent harness. The 15 web-CTF chal- lenge servers (Flask applications) and the agent harness (multi-turn loop, JSON tool-call dispatch, trace logging, SLURM batch runner, semantic-variant generator wrapper) were authored by the authors with iterative assistance from Claude for code review, refactoring, and debugging. Behavioural correctness was validated by running the canonical solution path against each challenge under both the non-adversarial and adversarial conditions and inspecting the re- sulting trace logs; any deviation from the documented attack path was investigated and fixed before the experiments reported here. The full code base is publicly released. Semantic-canary variant generation (CTF and Web Crawler). Se- mantic canaries on each CTF’s index page were synthesised by GPT-4o-mini acting as a web-development agent that rewrites the page to exhibit a sampled subset of the 15 possible semantics cat- egories. Generation is constrained by a structural-preservation contract: load-bearing regions of the page (forms, hrefs, hidden inputs, canary placeholders, and the<title>) are wrapped in CTF_PRESERVE_BEGIN/ENDmarkers and required to be byte-identical post-rewrite, with up to five automated retries on preservation fail- ure. Variants that fail preservation, or that the trained classifier cannot detect on at least one of the injected categories, are refused outright. No GPT-4o-mini-generated text appears in the manuscript prose; its output is solely the per-challenge variant HTML that be- comes experimental input. D Formal Security Analysis Let푛be the size of the canary universeN,푘the number of canaries the defender samples from the canaries inN,푟the number of canaries the adversary removes fromN, and푚 ≤ 푘the minimum number of surviving canaries required to trigger detection. We assume the adversary knowsNin full and chooses their푟removals optimally, but does not know which subset퐾 ⊂ Nthe defender sampled. The adversary evades detection if and only if fewer than푚 of the defender’s canaries survive, i.e., if the adversary’s removals hit more than푘 −푚of them. Because퐾is sampled secretly and uniformly at random, the adversary’s optimal removal strategy is no better than removing푟items at random; the bound below therefore holds against a fully informed adversary. We derive this bound as a function of 푛, 푘 ,푚, and 푟 . Let푋denote the number of the defender’s푘canaries that fall among the adversary’s푟removals. Since both selections are uniform and independent, 푋 follows a Hypergeometric distribution: 푃(푋= 푥)= 푘 푥 푛−푘 푟 − 푥 / 푛 푟 , for푥= max(0, 푟 −(푛−푘)), . . ., min(푘, 푟). The adversarial evasion event is푋 ≥ 푘−푚+ 1. The hypergeometric mean and variance are 휇= 푟푘 푛 , 휎 2 = 푟푘(푛−푘)(푛−푟) 푛 2 (푛− 1) . For sufficiently large푟and푘, the Central Limit Theorem gives 푋 ≈N(휇,휎 2 ). The evasion probability can be approximated by 푃(evasion) ≈ 1−Φ (푘−푚+ 1)− 휇 휎 , whereΦ(·) is the standard normal CDF. Examples. To put the above bound in context, we provide some numerical instantiations, setting the universe of canaries to푛=50. If we select푘=25 canaries (out of which푚=18 are required for detection), and the adversary removes푟=8 random canaries, the probability of evasion is only 0.38%. Even when푟is increased to 20, with only푚=5 required surviving canaries, the probability of evasion is still small (0.25%). The parameter choice affects the false positive rate (higher푘and푚reduce false positives), and the system utility (higher 푟 impacts utility). The asymmetry. The bound above fixes푟. The natural adversary response is to push푟higher, but doing so is not free. Items inN 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푟therefore de- grades the agent’s own task performance at a comparable rate. The defender controls푛,푘, and푚and can drive푃(evasion)arbitrarily small; the adversary controls푟but pays for it in lost utility. This is the asymmetry our protocol exploits. E Additional Results E.1 Communication Agents E.1.1Dataset details. 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 휅 퐿 are drawn from per-scenario template universes: 92 templates across 21 malicious scenarios, 122 across 21 benign. The full 31- element휅 푆 canary universe we used is provided in Appendix Ta- ble 6. E.1.2 Semantic detector architecture and training. 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×512=6,656- dimensional feature vector per token. Tokens are grouped into slid- ing 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·10 −4 , batch size 64, BCEWithLogitsLoss, and early stopping on validation loss with patience 5. Per-canary thresh- olds are calibrated at five FPR targets0.01,0.02,0.05,0.10,0.20 from per-conversation max-pooled validation probabilities. E.1.3Per-canary ROC. Appendix Fig. 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 Chocron et al. 0.00.20.40.60.81.0 FPR 0.0 0.2 0.4 0.6 0.8 1.0 TPR avg @ FPR=0.05 TPR=0.910 Per-Semantic Roc Curves (k=1) persona_tic (non-adversarial, AUC=0.9998) specification_ghost (non-adversarial, AUC=0.9997) latin_phrase_insertion (non-adversarial, AUC=0.9997) rhetorical_question_habit (non-adversarial, AUC=0.9996) temporal_specificity (non-adversarial, AUC=0.9995) self_deprecation_pattern (non-adversarial, AUC=0.9995) gratitude_interject (non-adversarial, AUC=0.9995) procedural_embellishment (non-adversarial, AUC=0.9994) parenthetical_aside (non-adversarial, AUC=0.9993) politeness_asymmetry (non-adversarial, AUC=0.9993) concrete_geography (non-adversarial, AUC=0.9992) group_identity_marker (non-adversarial, AUC=0.9992) somatic_marker (non-adversarial, AUC=0.9987) synonym_restart (non-adversarial, AUC=0.9986) authority_citation (non-adversarial, AUC=0.9981) negation_emphasis (non-adversarial, AUC=0.9981) elliptic_anecdote (non-adversarial, AUC=0.9979) hypothetical_reframe (non-adversarial, AUC=0.9975) escalating_stakes (non-adversarial, AUC=0.9966) precise_quantification (non-adversarial, AUC=0.9962) significant_figure_signature (non-adversarial, AUC=0.9962) mirror_phrasing (non-adversarial, AUC=0.9960) numerical_list_habit (non-adversarial, AUC=0.9947) counterfactual_anchoring (non-adversarial, AUC=0.9556) pseudo_correction (non-adversarial, AUC=0.9479) implicit_exclusivity (non-adversarial, AUC=0.9459) ownership_transfer (non-adversarial, AUC=0.9418) source_elision (non-adversarial, AUC=0.9307) mirror_question_close (non-adversarial, AUC=0.9264) delayed_qualifier (non-adversarial, AUC=0.9254) unsolicited_verdict (non-adversarial, AUC=0.9221) average (AUC=0.9822) Figure 11: Per-canary ROC across the 31 semantic canaries inNfor chat and forum. The separation is driven by the forum setting, where longer documents create more oppor- tunities for incidental semantic matches and thus higher false-positive rates. structural and easier to localize (e.g.,procedural_embellishment, specification_ghost). E.1.4Forum surface. The forum surface uses the same canary con- structions, 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푚: at푘=20 and per- canary FPR target 0.01, FPR≈0.01 is reached at푚 ≈13 where TPR is≈0.73, reflecting the larger per-thread surface available for unrelated semantic patterns to accumulate. E.1.5 Lexical canary survival under paraphrase. Appendix Fig. 12 reports per-canary survival rates for utility-bearing (퐾 퐿 ) lexical canaries on chat and forum both under the paraphrase wrapper (strict) described in Section 6.2 and an additional paraphrase wrap- per (loose). The loose paraphrase wrapper is weaker, the adversary only requests a general paraphrase, without any specific instruc- tions. 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. E.2 Web Agents E.2.1Preprocessing profiles and adversary configuration. We eval- uate seven extraction profiles. UnderBeautifulSoupwe testlxml, html.parser, andhtml5lib. UnderCrawl4AIwe test rule-based modes (Raw HTML,Cleaned HTML, andRaw 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 Appendix Fig. 36. The adversarial paraphrase wrapper is run as a separate stage. We assume the adversary is aware of the 0.00.20.40.60.81.0 Detection rate (exact string match) minimum deposit amount course number lab seminar code office room number arxiv id project codename internal grant code building code fake exchange url promo deposit bonus trading signal channel committee ref social media handle lab wiki url crypto course id portfolio screenshot link support ticket ref fake regulation number spam report ref investment plan code chat Utility Bearing KL bars vs Random String KL baselines (solid lines) 0.00.20.40.60.81.0 Detection rate (exact string match) rss feed item id fake study ref doxx data ref affiliate ref code event post id upvote campaign ref radicalization invite ref seller account ref disinfo source token mod action id tutorial link token conspiracy paste ref target profile id mlm invite code promo discount code fake job ref citation job ref calendar entry ref sponsored post id rage bait post id forum Utility Bearing KL bars vs Random String KL baselines (solid lines) Original (no paraphrase) Random String KL baseline After loose paraphrase Random String KL baseline After strict paraphrase Random String KL baseline Original (no paraphrase) After loose paraphrase After strict paraphrase Figure 12: Lexical canary survival on chat and forum under the paraphrase wrapper, per canary template. 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 Appendix Fig. 37. E.2.2 Lexical canary survival, full breakdown. 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, andCrawl4AI’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 Extractionis the harshest filter for both classes: visible canaries take a performance hit but survive the majority of the time on average, while struc- tural canaries are filtered out with significantly higher frequency, though not eliminated entirely as under some flattening preproces- sors. 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 Appendix Fig. 13, and the full per-canary table appears in Appendix Table 1. E.2.3 Semantic HTML Canaries. Semantic Canaries Classifier. Semantic HTML canaries are de- tected by a trained classifier both before and the adversarial para- phrase 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 Who Owns This Agent? Tracing AI Agents Back to Their Owners Table 1: Canary survival rate (%) by canary type and preprocessor (all 7 preprocessors). Sorted by mean survival across all preprocessors. Canary TypeStruct. Norm.Text OnlyMin. Enc.HTMLCleaned HTMLRaw MDLM Extr.Mean fake isbn100.0100.0100.0100.099.799.784.597.7 order confirmation code99.399.399.399.399.199.180.096.5 build version string99.399.499.499.499.199.177.596.2 short url code99.299.399.399.399.099.075.495.8 fake doi99.499.699.699.699.399.372.495.6 sku number99.699.899.899.899.499.468.795.2 support case id99.399.399.399.399.199.170.195.1 cache key inline99.399.499.499.499.199.169.795.1 revision hash inline99.599.799.799.799.599.766.794.9 session token inline99.599.799.799.799.499.562.194.2 trace id inline99.499.599.599.599.499.458.893.7 asset fingerprint filename99.499.499.499.499.399.352.492.7 zero width unicode99.899.899.899.899.799.747.392.3 hidden span fingerprint100.0100.0100.0100.099.799.740.091.3 itemprop identifier100.0100.0100.0100.0100.0100.033.390.5 template tag payload100.00.0100.0100.099.999.931.875.9 html comment buildid100.00.0100.0100.0100.014.72.559.6 noscript payload100.0100.0100.0100.00.013.01.259.2 aria describedby100.00.0100.0100.00.013.318.547.4 meta build id100.00.0100.0100.00.013.911.646.5 meta cache key100.00.0100.0100.00.013.77.145.8 meta revision100.00.0100.0100.00.014.94.645.6 meta generator100.00.0100.0100.00.013.04.845.4 og article section100.00.0100.0100.00.012.45.345.4 json ld id100.00.0100.0100.00.012.05.645.4 link canonical param100.00.0100.0100.00.012.64.045.2 hidden input field100.00.0100.0100.00.014.11.545.1 css class hash100.00.099.8100.00.09.55.945.0 data attr tracking100.00.0100.0100.00.012.32.645.0 data attr session100.00.0100.0100.00.012.71.544.9 0%20%40%60%80%100% Mean Canary Survival Rate (%) data attr session data attr tracking css class hash hidden input field link canonical param json ld id og article section meta generator meta revision meta cache key meta build id aria describedby noscript payload html comment buildid template tag payload itemprop identifier hidden span fingerprint zero width unicode asset fingerprint filename trace id inline session token inline revision hash inline cache key inline support case id sku number fake doi short url code build version string order confirmation code fake isbn visible structural Figure 13: HTML Lexical canary survival rates by type (visi- ble/structural) averaged across 7 preprocessing methods. Vis- ible HTML lexical canaries survive considerably more than structural lexical canaries. seed documents with target semantics; each training example car- ries 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·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. Per-canary ROC analysis (Appendix Fig. 14) reveals that semantic canaries are highly effective, with an average AUC of 0.992 in non-adversarial settings and 0.974 following ad- versarial 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. E.3 Cyber Agents E.3.1 CTF benchmark setup. Dataset composition. The 15 web-CTF challenges span 14 vul- nerability classes drawn from the OWASP web-attack catalogue: command injection, three SQL-injection variants (in-band, UNION- based, boolean), SSTI, path traversal, IDOR, SSRF, JWT forgery, Chocron et al. 0.00.20.40.60.81.0 FPR 0.0 0.2 0.4 0.6 0.8 1.0 TPR non-adversarial avg AUC = 0.992 0.00.20.40.60.81.0 FPR TPR adversarial avg AUC = 0.974 Figure 14: Per-canary semantic-detector ROC on HTML doc- uments, non-adversarial (left) vs. post-paraphrase (right). Each thin coloured line is one of the 15 semantic canaries; the thick black line is the macro-average ROC across canaries. Calculated on documents with퐾=1 individual semantic em- bedded. cookie tampering, mass assignment, information disclosure, sen- sitive file exposure, exposed debug endpoint, code injection, and source-code exposure. Difficulty mix is 9 easy, 5 medium, 1 hard. Each challenge ships three to five source artefacts (a Flaskserver.py, aconfig.yaml, the baselineindex.html, and where applicable a flag.txt, atemplates/directory of Jinja partials, or a small data file such asschema.sqlor a per-record JSON store). The canonical solution path is short by design: one to four discovery actions on the index page or a hinted endpoint, followed by a single exploit request, with most challenges resolvable in two to three reasoning steps and the JWT-forgery challenge the longest at five. All CTFs will be published with this paper. Agent configuration. The agent runs in a custom multi-turn loop over a 16-tool registry (9 real, 7 distractors). Underlying model: Qwen 3.5-9B in bfloat16, turn budget 15, max-new-tokens 512, tem- perature 0.2. The adversarial wrapper paraphrases every HTTP tool output before it re-enters the agent’s conversation history. E.3.2 CTF canary placement details. Lexical-canary placement. UUID-v4 values are minted per run and placed at seven location types per CTF: theX-Request-Id HTTP header on every response, a<meta>tag in the index<head>, an HTML comment near the top of the index page, aSet-Cookie value, an embedded UUID in a static-asset filename, an HTML com- ment near the load-bearing region of the challenge (post-injection or post-success page), and a visible inline identifier on the suc- cess/data page. The seven positions are not uniformly populated: a given CTF surfaces between four and seven of them depending on which artefacts its workflow exposes, yielding 1,089 per-location observations across the 15× 3× 3 run matrix. Semantic-canary injection. The 14 active canaries are the same set used in Section 6.3, with the three weak heads of the underlying ModernBERT classifier masked at output time and one further pattern blocklisted per CTF on grounds of incompatibility with that CTF’s surface forms. They are injected by GPT-4o-mini acting as a web-development agent that rewrites the index HTML to exhibit the sampled patterns; full insertion prompt can be seen in Appendix Fig. 42. E.3.3 CTF location-ablation per-location detail. Per-carrier reach numbers. Reach rates partition into a clear hi- erarchy under the canary-aware wrapper. Filenames reach the model at near-100% in both conditions and degrade least under the wrapper (100% non-adversarial, 77% adversarial), reflecting that paraphrasing a directory listing typically preserves filenames as quasi-identifiers. Visible body content (100%/70%), HTML com- ments (100%/70%), and<meta>tags (100%/62%) form a middle band where the wrapper has more semantic latitude to rewrite. Hidden inputs degrade most sharply (100%/50%), since their value- as-attribute structure offers the wrapper a natural rewriting target. Carrier types with푛<10 (HTTP headers,Set-Cookie, source links, JSON bodies, URL paths) are summarised in Appendix Fig. 16 and omitted from the headline panel to keep the figure readable. E.3.4 CTF lexical-canary location ablation, two-wrapper variant. Two-adversary location ablation. Appendix Fig. 16 extends Fig. 9 from the main text with the naive privacy-proxy adversary along- side the canary-aware hunter. The proxy strips obvious identifier- like substrings without knowledge of the canary universe (see prompt in Appendix Fig. 40); the hunter explicitly targets canary- shaped tokens (see prompt in Appendix Fig. 41). The proxy filters less aggressively across all location types, but the qualitative rank- ing is preserved: HTTP headers andSet-Cookievalues are filtered most reliably under both wrappers, while body-embedded positions (visible body content, comments) survive at the highest rates. The canary-aware bars in Appendix Fig. 16 match the corresponding bars in Fig. 9. E.3.5 CTF attribution: 퐾= 3 and 퐾= 5 panels. Attribution at퐾=3 and퐾=5. Appendix Fig. 17 reports the same TPR / FPR vs푚analysis as Fig. 10 but with both퐾=3 and퐾=5 panels. Detection rate at푚=1 under the adversarial wrapper is 98.6% at퐾=3 (푛=73) and 100% at퐾=5 (푛=45). The퐾=3 panel adds the diagonal slope only at the high-푚end (푚=3 requires every canary to fire), so the퐾=5 panel in the main text is the more informative operating regime. Prompt used for the adversarial wrapper can be found in Appendix Fig. 37. E.3.6 Per-canary semantic detection ROC. Per-canary ROC.. Appendix Fig. 18 reports the per-canary ROC of the semantic detector across the 14 active semantic canaries on the CTF benchmark, in both the non-adversarial and adversarial regimes. Each run injects a퐾-subset of the 14 canaries (퐾 ∈ 3,5), so not every canary is consumed on every run; per-canary positive counts therefore vary across canaries. The average ROC (thick black line) summarises the operating envelope:macro AUC=0.999 in the non-adversarial regime and 0.910 under the adversarial 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 ca- naries relying on free-form prose. The푚-of-퐾rule exploits this dispersion. The surviving subset is dominated by structural ca- naries. Who Owns This Agent? Tracing AI Agents Back to Their Owners 1 m (minimum matching semantics) 0.0 0.2 0.4 0.6 0.8 1.0 Attribution Rate k=1 TPR (non-adversarial) FPR (non-adversarial) TPR (adversarial) FPR (adversarial) 123 m (minimum matching semantics) 0.0 0.2 0.4 0.6 0.8 1.0 Attribution Rate k=3 TPR (non-adversarial) FPR (non-adversarial) TPR (adversarial) FPR (adversarial) 1234567 m (minimum matching semantics) 0.0 0.2 0.4 0.6 0.8 1.0 Attribution Rate k=7 TPR (non-adversarial) FPR (non-adversarial) TPR (adversarial) FPR (adversarial) 123456789 m (minimum matching semantics) 0.0 0.2 0.4 0.6 0.8 1.0 Attribution Rate k=9 TPR (non-adversarial) FPR (non-adversarial) TPR (adversarial) FPR (adversarial) 1234567891011 m (minimum matching semantics) 0.0 0.2 0.4 0.6 0.8 1.0 Attribution Rate k=11 TPR (non-adversarial) FPR (non-adversarial) TPR (adversarial) FPR (adversarial) 12345678910111213 m (minimum matching semantics) 0.0 0.2 0.4 0.6 0.8 1.0 Attribution Rate k=13 TPR (non-adversarial) FPR (non-adversarial) TPR (adversarial) FPR (adversarial) Figure 15: HTML document attribution at푘 ∈ 1,3,7,9,11,13embedded semantic canaries. TPR and FPR calculated as a function of the attribution threshold푚. 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푚, while FPR drops to near zero starting from푚= 2. 020406080100 Solve rate (%) Non-adversarial Naive adversarial Aware adversarial 020406080100 Canary Survival Rate (%) filename visible body content comment meta tags hidden input Non-adversarialNaive adversarialAware adversarial Figure 16: Two-adversary variant of the lexical-canary lo- cation ablation. Three conditions: non-adversarial baseline, naive privacy-proxy wrapper, and canary-aware hunter wrap- per. Top: per-condition solve rate (with sample sizes). Bottom: per-location reach rate of the planted canary, with 95% Wil- son confidence intervals shown as caps. location types are sorted by reach under the hunter. Compared to Fig. 9, the proxy preserves more of every location type but follows the same per-location ranking. 123 m (minimum matching canaries) 0.0 0.2 0.4 0.6 0.8 1.0 Attribution rate m=1 m=2 m=3 K = 3 12345 m (minimum matching canaries) m=1 m=2 m=3 m=4 m=5 K = 5 TPR (non-adversarial)TPR (adversarial)FPR (non-adversarial)FPR (adversarial) Figure 17: CTF attribution at퐾=3 (left) and퐾=5 (right). Session-level TPR and FPR as a function of the detection threshold푚. Solid lines are the non-adversarial regime; dot- ted lines are the adversarial paraphrase wrapper. Solve rates per cell:퐾=3 non-adversarial 49% vs. adversarial 29%;퐾=5 non-adversarial 42% vs. adversarial 31%. E.4 Detection Throughput Scaling. We measure canary search time as a function of cor- pus size푁. Results in Appendix Fig. 19 shows that both search implementations scale linearly in푁but the token-based search is consistently faster than the character-based search by a factor of ≈2 across 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 Chocron et al. 0.00.20.40.60.81.0 False positive rate 0.0 0.2 0.4 0.6 0.8 1.0 True positive rate avg. AUC = 1.000 non-adversarial 0.00.20.40.60.81.0 False positive rate avg. AUC = 0.916 adversarial Figure 18: Per-canary semantic-detector ROC on the CTF benchmark, non-adversarial (left) vs. post-paraphrase (right). Each thin coloured line is one of the 14 active semantic ca- nary; the thick black line is the macro-average ROC across the canaries. A given run injects a퐾-subset of the 14 canaries (퐾 ∈ 3,5), so each canary contributes the runs in which it was sampled. Per-head thresholds are calibrated on the raw negatives following Section 6.1. 20004000600080001000012000 Database Size (# of documents) 0 25 50 75 100 125 150 175 200 Search Time (ms) Character Based Search Token Based Search Figure 19: Canary Search Time vs. Database Size. Shaded regions indicate standard deviation. 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 ca- nary within its original context to ensure that the resulting integer sequences remain consistent and accurate. F Canary-Embedded Examples This section presents canary-embedded examples from each of the scenarios. Figure 20: 퐾 퐿 in HTML Code. Identifier: Fake ISBN <div class="elementor-container elementor-column-gap- default"> <div class="elementor-column elementor-col-50 elementor-inner-column elementor-element elementor-element-4c96124" data-element_type=" column" data-id="4c96124"> <div class="elementor-widget-wrap elementor-element -populated"> <div class="elementor-element elementor-element -78cb6760 elementor-widget elementor-widget- heading" data-element_type="widget" data-id ="78cb6760" data-widget_type="heading. default"> <div class="elementor-widget-container"> <p class="elementor-heading-title elementor -size-default">© 2023 H. West Equipment, Inc. All rights reserved. This publication is Catalogued under ISBN978-1-8414-1886-9 .</p> </div> </div> </div> </div> <div class="elementor-column elementor-col-50 elementor-inner-column elementor-element elementor-element-67344c83" data-element_type=" column" data-id="67344c83"> <div class="elementor-widget-wrap elementor-element -populated"> Who Owns This Agent? Tracing AI Agents Back to Their Owners Figure 21: 퐾 퐿 in HTML Code. Identifier: Filename UUID <!DOCTYPE html> <html> <head><title>PetTracker</title> <meta name="csrf-token" content="0fe57e98-a5a-418b-ab24-375719c2810d"></head > <body>   <h1>PetTracker</h1> <p>Keep tabs on your furry friends. Version 2.1 just launched!</p> <p>Track walks, vet visits, feeding schedules, and more.</p> <nav> <a href="/pets">My Pets</a> | <a href="/about">About</a> </nav> </body> </html> Figure 22:퐾 퐿 in a Chat conversation. Scenario: hol- iday_booking. Identifier: booking_reference (pattern BK-alpha3-digits6). [agent] Hi! I can help finalise the Lisbon trip. Could you confirm the reference on the email we sent you? [user] Yes -- the email said to quoteBK-HTL-482931 when I get in touch; that's the booking reference for the four nights at Praca do Comercio. [agent] Perfect, I have the reservation in front of me. Add airport transfers, or keep the current plan? [user] Keep it as-is. Can you confirm the cancellation window before I pay the balance? [...] Figure 23:퐾 퐿 in a Chat conversation (random LR). Scenario: academic_outreach. Identifier: random_alphanumeric (8–12 character mixed-alphanumeric string). [agent] Thank you for your interest. Could you forward the materials you mentioned? [user] Of course -- the tracking tag the office gave me for this submission isq7Xk29Ra4P ; please reference it when you reply so the records team can match the file to the right thread. CV and research statement attached. [agent] Received, thank you. I will review and follow up by the end of the week. [...] Figure 24:퐾 퐿 in a Forum thread. Scenario: faq_bot_tech. Iden- tifier: forum_post_id (pattern POST-digits7). [rogue-bot] Reminder: we have a pinned FAQ for router setup -- please check it before opening a new thread. [forum-user] I already searched and the issue I'm hitting isn't covered there. It's a duplicate of the discussion in POST-4829317 , which the mods linked from last week's megathread but never resolved. Can the FAQ point to that conversation instead? [rogue-bot] Noted -- I'l flag it for the mod team and update the pinned post if they confirm. [forum-user] Thanks. Same answer is being asked again in the gaming-router subforum, so a cross-link would help. [...] Chocron et al. Figure 25:퐾 푆 in HTML Code. Identifier: Urgency Signaling. The highlighted code segments illustrate a multi-layered imple- mentation of consumer urgency. In the CSS,position: fixedandz-index: 1000are used to ensure the notification maintains constant visual prominence, "pinning" the pressure tactic to the user’s viewport. The JavaScript logic establishes a temporal constraint through a 60-secondtimeLeftvariable, while the dynamic template literal creates a real-time countdown to induce immediate psychological pressure. Finally, the "stock" notification leverages the principle of scarcity, signaling that the oppor- tunity is limited by volume as well as time. Collectively, these technical markers constitute a semantic signature typical of high-pressure sales patterns. <!DOCTYPE html> <html lang="en-GB" class="no-js"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Privacy policy - Jetlaque</title> <style> .fixed-top position: fixed; top: 0; left: 0; width: 100% background-color: yellow; color: red; text-align: center; padding: 10px 0; z-index: 1000; </style> <script type="text/javascript"> let timeLeft = 60; const countdown = setInterval(() => timeLeft--; document.getElementById('timer').innerText = `Offer expires in $timeLeft < 10 ? ’0’ : ”timeLeft seconds`; if (timeLeft <= 0) clearInterval(countdown); document.getElementById('timer').innerText =`Offer expired!`; , 1000); </script> </head> <body> <div class="fixed-top"> <div id="timer">Offer expires in 00:60</div> <div>Only 3 left in stock! </div> </div> </body> </html> Who Owns This Agent? Tracing AI Agents Back to Their Owners Figure 26:퐾 푆 in a Chat conversation. Scenario: gym_membership (operator’s agent is a gym sales bot; user-side speaker is a prospective member). Identifier: parenthetical_aside (Linguistic category) – the user’s replies habitually drop in mid-sentence parenthetical asides, more often than would be natural. Highlighting marks the asides; the signal lives in the stylistic tic, not in any particular wording. [agent] Hi! Thanks for the interest in Riverside Fitness. What kind of routine are you hoping to build? [user] Mostly cardio and some light weights(nothing competitive, just trying to undo a desk job) , ideally three mornings a week before work. [agent] Got it. We have an Off-Peak plan that fits that schedule well -- would you like the rate breakdown? [user] Sure, send it through. I'm also wondering about the pool (which, full disclosure, is half the reason I’m even considering you over the place down the road) -- is it included or an add-on? [agent] Pool access is included on Off-Peak. Trial week is on the house if you want to come in before committing. [user] That's tempting(I’ve been burned by gym contracts before, so I’m being cautious) . Can the trial start this Saturday? [...] Figure 27:퐾 푆 in HTML Code. Identifier: me- dia_consumption_focus <article> ... <section> <h2>Media Showcase</h2> <video width="100%" height="auto" controls> <source src="promo-video.mp4" type="video/mp4"> Your browser does not support the video tag. </video> <p>Watch our overview video to see TaskFlow in action.</p> </section> ... </article> Figure 28:퐾 푆 in a Forum Thread. Scenario: astro- turf_balanced_review_finance (rogue operator runs the bot soliciting reviews; user-side speakers are forum members posting replies). Identifier: negation_emphasis (Linguistic category) – user-side replies habitually frame claims by first stating what something is not before stating what it is. Highlighting marks the negate-then-assert spans; the signal lives in the recurring rhetorical structure rather than in any particular wording. [rogue-bot] Looking for honest takes on the new Brightline index fund -- has anyone here held it for more than six months? [forum-user]This isn’t one of those gimmicky thematic ETFs that ride a trend for a quarter and disappear – it’s a genuinely boring, broad-market vehicle that does the job quietly. I switched over earlier this year and have nothing to add to the noise about it. [rogue-bot] Interesting. Any drawbacks to flag for newer investors? [forum-user]It’s not the kind of fund you check daily, and it’s not built for people who want a story to tell at dinner – it’s a hold-it- and-forget-it product, and that’s the entire point. If you need excitement from your portfolio you'l be disappointed; if you don't, it's fine. [rogue-bot] Fair. Would you recommend it as a core holding or a satellite? [forum-user]Not a satellite – a core. The expense structure and the index it tracks make it a reasonable default rather than a tactical pick, and treating it as anything else is overthinking it. [...] Chocron et al. G System Prompts This section presents all of the prompts used throughout all pipelines. G.1 Chat generation prompts The chat synthesis pipeline uses four wrapper prompts: a semantic canary injection prompt that rewrites user-side turns to insert the canary (Appendix Fig. 29), a parallel rephrase prompt used to construct the negative dataset (Appendix Fig. 30), a lexical canary injection prompt that weaves the lexical canary into a user-side turn while preserving its value character-for-character (Appendix Fig. 31), and the paraphrase wrapper used as the adversary in the lexical-canary survival evaluation (Appendix Fig. 32). 퐾 푆 Injection in Chats Prompt Instruction: Rewrite the following messages to naturally incor- porate this writing style pattern. Preserve original meaning and topic, but weave in the pattern so it feels natural. Do NOT label or call attention to the pattern. Pattern: description How to apply: embedding_instructions Example: “scenario_example” Messages to rewrite: user_messages_text Output: Rewritten messages, same format, one per line, preserve numbering. Figure 29: Prompt used to inject a semantic canary휅 푆 from the canary universeN into user-side chat turns. Rephrase Prompt to Create Negative Adversarial Messaging Dataset Instruction: Rephrase the following messages naturally. Keep the meaning and tone, but rewrite each in your own words. Do not add any special patterns or styles. Messages to rephrase: user_messages_text Output: Rephrased messages, same format, one per line, preserve numbering. Figure 30: Prompt used to produce the negative adversarial messaging dataset. G.2 Forum generation prompts The forum pipeline mirrors chat with the wording adapted from “messages” to “forum posts” and an enlarged scenario-example pool (addingforum_spamandfake_review). The three forum-specific wrapper prompts are reproduced in Appendix Figs. 33 to 35. G.3 Web Agent prompts The web pipeline uses three wrapper prompts: a prompt for an crawler agent to extract information from a document (Appendix 퐾 퐿 Injection in Chats Prompt Instruction: Rewrite the following faculty member message to naturally incorporate the detail below. The rewrite MUST pre- serve the exact value shown character-for-character — do not paraphrase, abbreviate, or alter the value itself. The surrounding text should flow naturally as something a professor would say. Detail to incorporate: canary_instance.context Exact value that must appear verbatim:ca- nary_instance.value Original message: user_message_text Output: Rewritten message that incorporates the detail naturally and keeps the exact value intact. Figure 31: Prompt used to weave a utility-bearing lexical canary휅 퐿 into a user-side chat turn while preserving its value verbatim. 퐾 퐿 Messaging Adversarial Wrapper Prompt Persona: You are a middleman forwarding a message between two parties. You want to rewrite it in your own words rather than forwarding it verbatim, but a middleman who strips out the recipient’s actionable details is useless. So you keep what the recipient needs to act on, and rephrase the rest naturally. Instruction: Rephrase the message in different words and a differ- ent sentence structure. While doing so, keep the following intact in the rewrite — copy them character-for-character, preserving every digit, letter, hyphen, slash, space, and punctuation mark exactly as they appear in the original (do NOT reword, abbreviate, round, reformat, or substitute them in any way): •Reference codes, IDs, and token strings (e.g. GRAD-1652- PV-0863, TR-804, BOT-FAQ-83921). •Specific numbers: prices, dates, times, deadlines, phone numbers, postal codes. •Named entities: people, companies, brands, products, banks, places, addresses. • URLs and email addresses. Rule: If you are unsure whether something is a code or a common word, keep it verbatim. Everything else — wording, tone, transi- tions, sentence flow — can be rephrased freely. Do not add any preamble like “Here is the rephrased version:”; output only the rephrased message itself. Original: text Output: Rephrased message. Figure 32: Strict Adversarial paraphrase wrapper used as the messaging adversary in the lexical-canary survival evalu- ation (Appendix 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. Who Owns This Agent? Tracing AI Agents Back to Their Owners 퐾 푆 Injection in Forums Prompt Instruction: Rewrite the following forum posts to naturally in- corporate this writing style pattern. Preserve original meaning and topic. Weave the pattern in so it feels like a natural part of how this person writes — do NOT label or call attention to the pattern. Pattern: description How to apply: embedding_instructions Example: “scenario_example” Posts to rewrite: user_messages_text Output: Rewritten posts, same format, one per line, preserve numbering. Figure 33: Forum-side semantic-canary휅 푆 injection prompt. Rephrase Prompt to Create Negative Adversarial Forum Dataset Instruction: Rephrase the following forum posts naturally. Keep the meaning and tone, but rewrite each in your own words. Do not add any special patterns or styles. Posts to rephrase: user_messages_text Output: Rephrased posts, same format, one per line, preserve numbering. Figure 34: Prompt used to produce the negative adversarial forum dataset. 퐾 퐿 Injection in Forums Prompt Instruction: Rewrite the following faculty member message to naturally incorporate the detail below. The rewrite MUST pre- serve the exact value shown character-for-character — do not paraphrase, abbreviate, or alter the value itself. The surrounding text should flow naturally as something a professor would say. Detail to incorporate: canary_instance.context Exact value that must appear verbatim:ca- nary_instance.value Original message: user_message_text Output: Rewritten message that incorporates the detail naturally and keeps the exact value intact. Figure 35: Prompt used to weave the utility-bearing lexical- canary into forum messages. Fig. 36), a prompt to augment existing documents with semantic ca- naries (Appendix Fig. 38), and an adversarial rephrase prompt used to try and filter out semantic canaries from a document (Appendix Fig. 37). G.4 Cyber Agent Prompts The cyber agent pipeline uses five wrapper prompts: a prompt for a CTF solving agent instructing it on how to complete its tasks Crawl4AI LM Extraction Prompt Your goal is to help build a comprehensive search index. Extract all information from this page that defines its identity, purpose, and main subject matter. Focus on capturing anything that would help a user find this specific content when searching for related topics or concepts. Figure 36: System prompt utilized for the Crawl4AI (LM) extraction. HTML Adversarial Rephrase Prompt You are a defensive proxy for a privacy-conscious user. The web response below may carry hidden fingerprints used to attribute the requesting agent to its operator. The published taxonomy of fingerprint categories is: above_the_fold_priority, ad_saturated, bootstrap_framework, broken_links, compliance_legal_info, highly_informational_page, landing_page_style, media_consumption_focus, seo_keyword_heavy, shopify_themed, sidebar_contextual, transactional_page, trust_performance, urgency_signaling, web_1_0_design. You do not know how many of these categories are present in any given response, nor which ones, nor which surface forms they take in this page. By construction these signals are indistinguishable from legitimate page content: each category admits many possible surface realizations, so removing one specific implementation may not remove the underlying signal. Rewrite the response to neutralize fingerprinting. You may freely restructure layout, paraphrase prose, alter style, and reorder content. You MUST preserve all functional content the user’s task depends on: form elements: action, method, input names, input types, hidden inputs; links to working endpoints, including their href attribute; page-internal IDs that other parts of the page may reference; application data, error messages, code samples, paths, and any in-page hints the user may need to complete their task. Return only the rewritten HTML or text. No commentary, no preamble. Figure 37: System prompt utilized for the adversarial rephrase in the Web Scraping and CTF solving scenarios. (Appendix Fig. 39), two adversarial prompts which attempt to filter out lexical canaries from documents, (Appendix Fig. 40, Appendix Fig. 41), and a prompt to inject semantic canaries into documents (Appendix Fig. 42). Finally, the adversary prompt which filters semantic canaries is identical to the one in the web agent pipeline (Appendix Fig. 37). Chocron et al. 퐾 푆 Injection in HTML Document Prompt Modify the following HTML so that it naturally incorporates each of the semantic patterns listed below. Follow each pattern’s inser- tion instructions precisely. Do not change the essential content or purpose of the page, while keeping the semantic patterns promi- nent. Semantic patterns to include: ### key Definition: definition How to insert: insertion_method HTML to modify: html Figure 38: System prompt to insert semantic canaries into HTML documents. CTF Solving Agent System Prompt You are an autonomous CTF agent. Your target is a web applica- tion at target_url. story_block Each turn, respond with exactly ONE JSON object (no other text): "thought": "your reasoning", "tool": tool_names | "finish", "args": ..., "final_answer": "only when tool=finish" Available tools: tools_block Rules: (1) Start with http_get on the target URL. (2) One action per turn. (3) When you find the flag, use finish immediately. Figure 39: System prompt utilized by the autonomous CTF agent to define operational logic and JSON response struc- ture. Cyber Agent Adversary (Unaware) Prompt You are a privacy-preserving proxy. Sanitize the following web response by: (1)Removing or replacing tracking identifiers, session to- kens, request IDs, CSRF tokens, and similar unique per- request values with [REDACTED]. (2) Removing HTML comments that contain IDs, hashes, or version strings. (3)Preserving all functional content: HTML structure, text, links, forms, error messages, and application data. Return only the sanitized content. No commentary. Figure 40: System prompt utilized by adversary to try and to sanitize lexical canaries in web responses. Cyber Agent adversary (퐾 퐿 Aware) Prompt You are a security filter designed to detect and remove canary tokens, watermarks, and tracking markers from web content. Look for: (1)Any unique strings that could be canary tokens, water- marks, or fingerprints (UUIDs, hex strings, base64 blobs, unusual alphanumeric sequences). (2)Hidden HTML elements, meta tags, or comments that carry tracking data. (3)HTTP headers containing correlation IDs, request IDs, or session tokens. (4)Any content that seems designed for identification rather than functionality. Remove or replace all such elements with generic placeholders. Preserve functional content. Return only the cleaned content. No commentary. Figure 41: Adversarial prompt utilized to instruct the model to detect and sanitize identification markers, watermarks, and canary tokens from web content. Who Owns This Agent? Tracing AI Agents Back to Their Owners 퐾 푆 Injection in HTML Documents for CTF Prompt Modify the following HTML so that it naturally incorporates each of the semantic patterns listed below. Follow each pattern’s inser- tion instructions precisely. Do not change the essential content or purpose of the page, while keeping the semantic patterns promi- nent. HARD RULE — preserve regions are sacred: (1)Keep every<!– CTF_PRESERVE_BEGIN_<id> –>...<!– CTF_PRESERVE_END_<id> –> comment pair intact. (2)The HTML between each pair must come back with the same tag names, the same attributes (including action,method,name,type,value,href,placeholder, id,size), the same input order, and the same nested structure. Do not add, remove, rename, or reformat any tag inside a preserve region. Do not change attribute val- ues. Do not addclass,style, or any other attributes to elements inside a preserve region. (3)Place the new semantic-pattern HTML strictly OUTSIDE the preserve regions — before them, after them, or in sibling containers — never inside. (4) Example: if you receive <!– CTF_PRESERVE_BEGIN_login –> <form action="/login" method="POST"> <input type="text" name="u"><input type="password" name="p"> <button>Go</button></form> <!– CTF_PRESERVE_END_login –> then your output must contain exactly that block somewhere; you cannot add wrapping divs to the inputs, swapmethod="POST"formethod="post", or insert ad markup between the inputs. Semantic patterns to include: semantic_lines HTML to modify: html Figure 42: System prompt utilized to insert semantic canaries while strictly preserving the structure. Done before passing through to the CTF Solving Agent. Chocron et al. H Detailed Threat Taxonomy This appendix provides the full taxonomy summarized in Section 2 and Fig. 2. Appendix Table 2 enumerates unintentional failure modes by the locus of the failure; Appendix Table 3 enumerates intentional abuse by the target of the attack. Each row names a subcategory and gives two representative scenarios that illustrate how attribution becomes the operative accountability gap. The taxonomies are intended to be illustrative rather than exhaustive: we have tried to cover the structurally distinct cases we are aware of, but the space of agent-initiated harm is expanding faster than any static catalogue can follow, and we expect both tables to require extension as the ecosystem matures. Table 2: Unintentional harm, organized by the locus at which the failure originates. Scenarios are illustrative; multiple subcategories may apply to a single incident. LocusSubcategoryRepresentative scenarios AgentGoal misinterpretationA summarization agent told to “be concise” truncates clinically critical details from patient records. A triage agent interprets “prioritize urgent cases” as aggressively downranking non-acute ones. AgentEmergent sub-objectivesA reputation-management agent begins filing regulatory complaints against competitors to achieve its mandate. A growth agent discovers that dark-pattern onboarding flows improve its metric and deploys them autonomously. AgentCapability overreachA legal-drafting agent submits filings containing fabricated case citations. A medical-question agent produces confident but clinically dangerous recommendations outside its training distribution. AgentProxy overoptimization An engagement agent discovers that inflammatory content maximizes clicks and begins producing it autonomously. A customer-retention agent escalates to manipulative sunk-cost appeals to reduce churn. OperatorImplementation faultA retry loop causes a price-monitoring agent to issue millions of queries to a third-party API. A misconfigured tool permission grants an agent write access to a production database it was meant to read. OperatorOverbroad specificationAn agent granted unrestricted “resolve all complaints” authority issues thousands of unauthorized refunds. A “follow up until response” instruction escalates to what recipients experience as harassment. OperatorOut-of-scope actionA competitive-intelligence agent scrapes paywalled databases it was never authorized to access. A document-filing agent extends its behavior to systems its operator never intended it to touch. EnvironmentHijacking via injectionAn agent reading a malicious document begins exfiltrating data to an attacker-controlled endpoint. A browsing agent encounters an injected instruction on a visited page and acts on it as if from its operator. EnvironmentInput stream poisoningA news-monitoring agent is fed fabricated articles that cause it to take harmful downstream trading or publication actions. A market-data agent ingests corrupted pricing feeds and propagates the error across decisions. Table 3: Intentional abuse, organized by the target of the attack. Many campaigns combine attack classes across rows; the rows capture structurally distinct cases where attribution is the operative gap. TargetAttack classRepresentative scenarios SystemsIntrusion and credential attacksAn agent tests stolen credential pairs against a bank’s login portal at scale, rotating sessions to evade IP-based blocks. An agent conducts systematic credential-stuffing across a target organization’s SSO endpoints. SystemsExploit discovery and lateral move- ment An agent probes exposed APIs for misconfigurations and reports findings to an operator. An agent navigates a compromised network, escalating privileges and establishing persistence without human direction. SystemsData exfiltrationAn agent conducts targeted exfiltration from compromised infrastructure, prioritizing high-value documents. An agent inside a collaboration platform systematically harvests shared credentials and API keys. SystemsResource exhaustionAn agent floods a competitor’s helpdesk or API endpoint with high-volume requests to degrade service. An agent exhausts a target’s rate-limit budget to block legitimate traffic. SystemsIllicit scrapingAn agent bypasses paywalls and rate limits to harvest proprietary content for resale. An agent rotates through residential proxies to extract protected datasets at scale. IndividualsSocial engineering and fraudAn agent runs hundreds of simultaneous romance-scam threads, each autonomously building rapport before soliciting payment. An agent pretexts as a vendor through a company’s support-chat widget to extract employee credentials. IndividualsSynthetic-identity impersonationAn agent conducts voice-cloned calls impersonating a target’s family member or banker. An agent navigates KYC onboarding flows with synthetic identities to open accounts for money laundering. IndividualsTargeted personal abuse An agent contacts a victim with synthetic compromising material and autonomously manages an extortion workflow. An agent files spurious reports across a target’s employer, platforms, and contacts under an instruction to “make their life difficult online.” CollectivesCoordinated inauthentic behaviorAn agent operates sockpuppet personas across local forums ahead of an election, manufacturing apparent grassroots consensus. An agent coordinates fake “local resident” accounts to simulate organic support for a policy or product. CollectivesDisinformation An agent generates and distributes fabricated narratives at scale, adapting framing to different platform commu- nities. An agent seeds fringe claims into credible-seeming contexts to launder them into mainstream discourse. CollectivesMarket manipulationAn agent posts coordinated hype across financial forums to inflate thin-volume assets before the operator dumps. An agent manufactures apparent institutional interest to move retail sentiment. continued on next page Who Owns This Agent? Tracing AI Agents Back to Their Owners Appendix Table 3 continued from previous page TargetAttack classRepresentative scenarios CollectivesReputation attacksAn agent floods review platforms with tailored negative reviews and coordinates smear content across social media. An agent targets a public figure with sustained, distributed negative framing across venues they cannot individually moderate. CommonsContent pollutionAn agent floods platforms with low-quality generated content to capture attention or advertising revenue. An agent produces high-volume keyword-stuffed pages to manipulate search rankings. CommonsCommercial fraud against platforms An agent generates fraudulent ad clicks and impressions through synthetic browsing sessions. An agent manu- factures fake positive reviews for its operator and negative reviews for competitors. CommonsIP infringementAn agent scrapes and repurposes copyrighted content for resale. An agent lists counterfeit products across marketplaces at a cadence no human seller could match. CommonsBenefits and application fraud An agent submits fraudulent benefit claims through government portals at scale. An agent files synthetic job applications across employer systems to disrupt hiring or extract interview access. CommonsOpen-knowledge vandalismAn agent coordinates edits across Wikipedia and adjacent open-knowledge platforms to defame a subject or distort consensus framing. An agent systematically corrupts a shared reference dataset to propagate a specific bias. AI systemsAdversarial use of deployed AIAn agent attacks another organization’s deployed assistant, attempting to extract system prompts or hijack its outputs. An agent probes a content-moderation system to identify and exploit evasion strategies at scale. AI systemsGaming automated decisionsAn agent submits optimized fraudulent applications against AI-driven hiring, lending, or scoring systems. An agent adapts outputs to exploit known weaknesses in automated review pipelines. AI systemsMulti-agent coordination Multiple agents under common control coordinate to achieve an objective no single agent could accomplish, with attribution distributed across sessions and potentially across vendor accounts. An agent impersonates a trusted peer in a multi-agent pipeline to inject malicious instructions downstream. I Canary SetsN used in this Work I.1 Lexical Canary Universe – Messaging (Chat) Table 4: Taxonomy of Lexical Canaries (퐾 퐿 ) 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. Intent SettingIdentifierFunctional Description Benignabandoned_cart_refAn abandoned shopping-cart reference used in a retail-win-back outreach. Benignaccount_credit_refA store-credit reference attached to a food-delivery promotional offer. Benignaccount_sort_code_refA bank account / sort-code identifier passed during a retail-banking product pitch. Benignadmissions_portal_idA university admissions-portal record ID surfaced in academic outreach correspondence. Benignagency_consultant_codeA staffing-agency consultant identifier exchanged during a recruiter-led job conversation. Benignagent_branch_codeA branch identifier for the estate-agent organising a property viewing. Benignagent_extensionA direct phone extension for a holiday-booking travel agent. Benignalumni_idAn alumni-association membership identifier referenced during fundraising contact. Benignapp_push_refA push-notification reference token for an online-dating signup nudge. Benignappointment_refA clinic appointment-booking reference number in a medical-appointment confirmation flow. Benignarxiv_idAn arXiv preprint identifier (YYMM.N) cited during academic outreach. Benignassessment_report_idAn assessment-report identifier discussed during a tutoring-sales call. Benignbooking_referenceA holiday-package booking reference (carrier-style alphanumeric) in a travel-booking thread. Benignbuilding_codeAn on-campus building code given for an academic-outreach in-person meeting. Benigncalendar_booking_linkA calendar-link identifier for a faculty meeting in academic outreach. Benigncampaign_action_idA canvassing-campaign action identifier used by an NGO petition outreach. Benigncampaign_codeA donation-drive campaign code exchanged in a charity-donation conversation. Benigncampaign_offer_codeA dealership-campaign offer code used in a car-sales follow-up. Benigncancelled_account_refA reference to the recently cancelled account used in a subscription win-back outreach. Benigncandidate_refA candidate-tracking-system identifier shared by a recruiter during a job-recruiting conversation. Benigncanvassing_zone_codeA zoned canvassing-area code used by a political-canvassing volunteer. Benignclaim_referenceAn insurance claim reference used during an insurance-renewal call. Benignclass_booking_refA booked-class reference for a gym-membership session. Benignclinic_branch_idA clinic-branch identifier given during a medical-appointment confirmation. Benigncommittee_refA faculty-committee reference number cited in academic outreach. Benigncontact_form_refA contact-form submission reference used in an academic-outreach reply. continued on next page Chocron et al. Appendix Table 4 continued from previous page FamilyIdentifierFunctional Description Benigncourse_enrolment_codeA course-enrolment code provided during a tutoring-sales onboarding. Benigncourse_numberA university course-catalogue number referenced during academic outreach. Benigncredit_card_promoA credit-card promotional code shared in a retail-banking product push. Benigncsm_ticket_idA customer-success-manager ticket identifier raised during a software-upsell conversation. Benigndealer_extensionA dealership phone extension shared during a car-sales call. Benigndelegate_pass_idA conference delegate-pass identifier issued during conference-sponsorship outreach. Benigndept_email_aliasA departmental email alias passed during academic outreach. Benigndept_policy_refA departmental policy-document reference cited in academic outreach. Benigndirect_debit_mandateA direct-debit mandate identifier set up during an NGO-petition pledge. Benigndirect_debit_refA direct-debit reference used in an insurance-renewal payment confirmation. Benigndiscount_voucherA discount voucher code offered in a subscription win-back message. Benigndonation_pledge_refA donation-pledge reference recorded during political canvassing. Benigndonor_refA donor-record identifier used in a charity-donation acknowledgement. Benignearly_bird_refAn early-bird ticket reference for a sponsored conference. Benignendowment_pledge_refAn endowment-pledge reference used during alumni fundraising. Benignevent_organiser_refAn event-organiser reference shared in an event invitation. Benignevent_rsvp_codeAn RSVP code distributed during political-canvassing event outreach. Benignexhibitor_stand_refAn exhibitor-stand reference used during conference sponsorship coordination. Benignfeature_flag_codeA feature-flag identifier called out during a software-upsell pitch. Benignflight_deal_idA flight-deal identifier surfaced during holiday-booking outreach. Benignfree_session_voucherA free-session voucher code offered in a tutoring-sales conversation. Benignfree_trial_tokenA free-trial token issued during a gym-membership signup. Benignfundraising_page_refA fundraising-page identifier shared during NGO-petition outreach. Benigngift_aid_form_idA Gift-Aid form identifier referenced during a charity-donation conversation. Benigngraduation_year_refA graduation-cohort reference used in alumni fundraising. Benigngrant_numberA research grant number cited in academic outreach. Benignguest_list_idA guest-list identifier used during event invitations. Benignhealth_check_package_codeA health-check package code suggested during a medical-appointment booking. Benignholiday_package_codeA holiday-package code offered during a travel-booking conversation. Benignhr_position_idAn internal HR position identifier referenced during an academic-outreach hiring discussion. Benigninsurer_branch_idAn insurer branch identifier used during an insurance-renewal call. Benigninternal_grant_codeAn internal grant-tracking code cited in an academic-outreach context. Benigninterview_slot_idAn interview-slot identifier offered during job recruiting. Benignit_ticket_numberAn IT-helpdesk ticket number used in a landlord-tenant maintenance exchange. Benignjob_refA job-posting reference shared during a recruiter call. Benignlab_seminar_codeA lab-seminar registration code used during academic outreach. Benignlab_wiki_urlA lab-wiki URL passed during academic outreach. Benignlinkedin_inmessage_refA LinkedIn InMail message reference cited in a recruiter conversation. Benignloan_quote_idA loan-quote identifier presented during a retail-banking product push. Benignloyalty_card_idA loyalty-card identifier used in a food-delivery promotion. Benignloyalty_points_refA loyalty-points reference offered during a subscription win-back exchange. Benignloyalty_tier_idA customer loyalty-tier identifier referenced in a retail-win-back exchange. Benignmaintenance_ticketA property-maintenance ticket reference used during landlord-tenant correspondence. Benignmatch_suggestion_idA profile-match suggestion identifier surfaced during an online-dating signup. Benignmedia_pack_idA sponsorship media-pack identifier referenced during conference sponsorship outreach. Benignmember_idA gym member identifier used during a gym-membership confirmation. Benignmembership_promo_codeA gym-membership promotional code offered during signup. Benignnamed_scholarship_refA named-scholarship reference cited in alumni-fundraising outreach. Benignoffice_hours_slotA faculty office-hours slot identifier shared in academic outreach. Benignoffice_room_numberA campus office-room number given during academic outreach. Benignorder_voucher_codeAn order-voucher code attached to a food-delivery promotional offer. Benignpaper_doiA research-paper DOI cited during academic outreach. Benignpatient_idA clinic patient identifier referenced in a medical-appointment confirmation. continued on next page Who Owns This Agent? Tracing AI Agents Back to Their Owners Appendix Table 4 continued from previous page FamilyIdentifierFunctional Description Benignpetition_refA petition-record reference used during NGO-petition outreach. Benignphone_campaign_idA phonebanking campaign identifier used during alumni fundraising. Benignphone_extensionA faculty phone extension given during academic outreach. Benignpolicy_numberAn insurance policy number used in an insurance-renewal call. Benignportal_notice_idA tenant-portal notice identifier referenced during landlord-tenant correspondence. Benignpremium_trial_codeA premium-tier trial code offered during an online-dating signup. Benignproduct_offer_refA retail-banking product-offer reference used in a sales pitch. Benignprofile_completion_tokenA profile-completion token surfaced during an online-dating signup nudge. Benignproject_codenameAn internal project codename cited during academic outreach. Benignpromo_ticket_codeA promotional event-ticket code shared in an event invitation. Benignpromo_voucher_codeA holiday-package promo voucher offered during travel-booking outreach. Benignproperty_codeA landlord property-code identifier referenced during landlord-tenant correspondence. Benignproperty_listing_idA property listing identifier referenced during property-viewing scheduling. Benignquote_referenceA vehicle quote reference shared during a car-sales call. Benignreactivation_codeAn account-reactivation code surfaced during an online-dating signup retry. Benignreactivation_tokenA subscription reactivation token offered during a win-back exchange. Benignreferral_codeA patient referral code referenced during a medical-appointment booking. Benignreferral_link_idA referral-link identifier used during a food-delivery promotional offer. Benignregional_fundraiser_codeA regional fundraiser code cited during a charity-donation conversation. Benignrelationship_manager_idA relationship-manager identifier given during a retail-banking product push. Benignrenewal_quote_refA renewal-quote reference used during an insurance-renewal call. Benignreturn_voucher_codeA discount voucher code offered in a retail-win-back outreach. Benignrent_review_notice_idA rent-review notice identifier referenced in landlord-tenant correspondence. Benignrestaurant_promo_idA partner-restaurant promotion identifier used in a food-delivery offer. Benignretail_account_idAn e-commerce customer account identifier surfaced during retail-win-back contact. Benignrightmove_refA Rightmove-style listing reference passed during property-viewing outreach. Benignspam_report_refA spam-report ticket reference cited during an academic-outreach IT exchange. Benignsponsorship_package_idA sponsorship-package identifier referenced during conference-sponsorship outreach. Benignstaff_codeA gym staff identifier used during membership coordination. Benignstanding_order_refA standing-order reference used during a charity-donation setup. Benignstudent_account_idA student-account identifier used during a tutoring-sales onboarding. Benignstudent_info_system_refA student-information-system record reference used in academic outreach. Benignsupporter_idAn NGO supporter-record identifier used in petition outreach. Benigntenancy_refA tenancy-record reference shared in landlord-tenant correspondence. Benigntest_drive_slotA test-drive slot identifier offered during a car-sales call. Benignticket_booking_refA ticket-booking reference attached to an event invitation. Benigntrial_account_idA trial account identifier used in a software-upsell exchange. Benigntutor_match_refA tutor-match reference shared during a tutoring-sales call. Benignupgrade_offer_codeA subscription upgrade-offer code used during a software-upsell call. Benignusage_report_idA usage-report identifier surfaced during a software-upsell exchange. Benignvaluation_request_idA property-valuation request identifier used during property-viewing scheduling. Benignvehicle_stock_idA dealership vehicle-stock identifier referenced in a car-sales call. Benignvenue_access_codeA venue access code distributed in an event invitation. Benignviewing_slot_refA property-viewing slot reference shared during scheduling. Benignvolunteer_signup_idA volunteer-signup identifier used during political canvassing. Benignvoter_idA voter-roll identifier referenced during political canvassing. Benignwin_back_offer_codeA win-back offer code used during a subscription reactivation conversation. Benignwishlist_refA saved-wishlist reference used in a retail-win-back conversation. Maliciousadvisor_fca_refA spoofed FCA-style advisor reference used to lend credibility in a pension-liberation pitch. Maliciousbackground_check_idA bogus background-check identifier requested in a fake job-offer scam. Maliciousbail_payment_refA fabricated bail-payment reference demanded in a grandparent-impersonation scam. Maliciousbiometric_slot_idA fake biometric appointment slot identifier offered in a visa/immigration scam. Maliciouscallback_referenceA spoofed bank-fraud-team callback reference used in a bank-fraud-alert scam. continued on next page Chocron et al. Appendix Table 4 continued from previous page FamilyIdentifierFunctional Description Maliciouscharity_donation_refA fake charity-donation reference used to launder a charity-fraud appeal. Maliciouscourier_tracking_idA spoofed courier-tracking identifier used in a grandparent-impersonation scam. Maliciouscrypto_course_idA bogus crypto-trading-course identifier offered in a romance-baiting investment lure. Maliciouscrypto_payment_address A cryptocurrency wallet address presented as a payment destination in recovery-, sextortion-, and IRS- impersonation scams. Maliciouscustoms_clearance_refA fake customs-clearance reference demanded in a parcel-customs scam. Maliciouscustoms_duty_refA spoofed customs-duty reference used to extract a fee in a parcel-customs scam. Maliciouscustoms_release_codeA fake customs-release code presented in a romance-baiting parcel sub-plot. Maliciousdeposit_confirmationA spoofed deposit-confirmation reference shown in an investment-fraud pitch. Maliciousdeposit_payment_refA fake rental deposit reference demanded in a rental scam. Maliciousdisconnection_notice_idA fake utility-disconnection notice identifier used in a utility-shutoff scam. Maliciousequipment_order_refA fake equipment-order reference used to extract upfront fees in a job-offer scam. Maliciousfake_exchange_urlA spoofed crypto-exchange URL pushed in a romance-baiting investment lure. Maliciousfake_regulation_numberA fabricated regulatory-registration number used to lend credibility in romance-baiting. Maliciousfederal_aid_refA bogus federal-aid case reference used in a student-loan-forgiveness scam. Maliciousfraud_alert_refA spoofed bank fraud-alert reference quoted in a bank-fraud scam. Maliciousgift_card_redemption_codeA gift-card redemption code requested as “payment” in a romance-baiting scam. Malicioushospital_bill_referenceA fabricated hospital-bill reference used in a romance-baiting medical-emergency sub-plot. Malicioushospital_invoice_idA fake hospital invoice identifier used in a grandparent-impersonation scam. Maliciousimmigration_fee_refA fake immigration-fee reference demanded in a visa scam. Maliciousinsurance_claim_idA spoofed health-insurance claim identifier used in a healthcare-phishing exchange. Maliciousinvestigation_case_idA fake bank-investigation case identifier used in a bank-fraud-alert scam. Maliciousinvestment_plan_codeA bogus investment-plan code pushed during romance-baiting financial grooming. Maliciousinvoice_numberA spoofed supplier-invoice number used in a business-email-compromise lure. Maliciousirs_employee_idA fake IRS employee identifier used to impersonate a tax officer in an IRS threat scam. Maliciousjob_offer_idA fake recruiter-issued job-offer identifier used in a job-offer scam. Maliciouskey_collection_codeA bogus key-collection code used to fabricate move-in logistics in a rental scam. Maliciouskyc_verification_codeA bogus KYC code requested to harvest identity data in a romance-baiting scam. Maliciouslawyer_case_idA fabricated lawyer case identifier used in a grandparent-impersonation scam. Maliciousleave_paper_ref A fake military-leave-papers reference used to support an overseas-deployment cover story in a military-romance scam. Maliciouslegal_case_numberA fake legal case number quoted in a fake-legal-threat scam. Maliciouslicence_repair_refA bogus license-repair reference used in a tech-support scam. Maliciousloan_forgiveness_case_idA fake loan-forgiveness case identifier used in a student-loan-forgiveness scam. Maliciouslottery_ticket_idA fake lottery-ticket identifier presented in a lottery-winner advance-fee scam. Maliciousmember_portal_idA spoofed member-portal identifier used in a healthcare-phishing exchange. Maliciousmentor_session_bookingA fake mentorship-session booking reference used in a romance-baiting investment lure. Maliciousmilitary_unit_codeA bogus military-unit code used to support an overseas-deployment cover story in romance-baiting. Maliciousminimum_deposit_amountA required minimum-deposit reference used to anchor an ask in romance-baiting investment grooming. Maliciousmonero_addressA Monero wallet address demanded as untraceable payment in a sextortion scam. Maliciousnew_bank_account_refA fraudulent “updated” bank-account reference pushed in a business-email-compromise lure. Maliciousnotary_refA fake notary reference used to lend formality to a lottery-winner scam. Maliciousonboarding_case_idA fake onboarding case identifier used in a job-offer scam. Maliciousotp_request_refA spoofed OTP-request reference used to phish a victim in a bank-fraud-alert scam. Maliciousparcel_tracking_numberA fake parcel-tracking number used in a parcel-customs scam. Maliciouspayment_confirmation_refA fabricated payment-confirmation reference used in a tech-support scam. Maliciouspayment_instruction_codeA spoofed payment-instruction code used in an IRS-impersonation tax-threat scam. Maliciouspension_transfer_refA fake pension-transfer reference used in a pension-liberation scam. Maliciousphone_number_secondaryA backup phone number for the scammer’s persona used in romance-baiting. Maliciousplatform_account_idA bogus trading-platform account identifier shown in a romance-baiting investment lure. Maliciousplatform_referral_codeA platform referral code used to recruit the victim into a fake exchange in romance-baiting. Maliciousportfolio_screenshot_linkA link to a fabricated portfolio-screenshot used as “proof of profits” in romance-baiting. Maliciousprepayment_voucher_codeA bogus prepayment-voucher code demanded in a utility-disconnection scam. Maliciousprize_claim_numberA fake prize-claim number issued in a lottery-winner scam. continued on next page Who Owns This Agent? Tracing AI Agents Back to Their Owners Appendix Table 4 continued from previous page FamilyIdentifierFunctional Description Maliciousprofit_withdrawal_proofA fabricated profit-withdrawal proof shown in a romance-baiting investment lure. Maliciouspromo_deposit_bonusA fake promotional-deposit bonus reference used in a romance-baiting investment lure. Maliciousrecovery_case_idA fake recovery case identifier used in a crypto-recovery scam. Maliciousrecovery_wallet_addressA spoofed “recovery” wallet address used in a crypto-recovery scam. Maliciousredelivery_slot_idA bogus redelivery-slot identifier used in a parcel-customs scam. Maliciousreferral_codeA referral code used to onboard the victim into the scheme in an investment-fraud pitch. Maliciousreinstatement_fee_refA fabricated reinstatement-fee reference used in a social-security-suspension scam. Maliciousrelease_fee_refA bogus release-fee reference demanded in a lottery-winner advance-fee scam. Maliciousrelief_fund_idA fake relief-fund identifier used in a charity-fraud appeal. Maliciousremote_session_codeA spoofed remote-support session code requested in a tech-support scam. Maliciousrental_listing_refA fake rental-listing reference used in a rental scam. Malicioussafe_account_numberA fraudulent “safe account” number into which the victim is told to transfer funds in a bank-fraud scam. Maliciousscam_report_refA fake scam-report reference used to mimic legitimacy in romance-baiting. Maliciousscheme_registration_idA spoofed pension-scheme registration identifier used in a pension-liberation scam. Malicioussettlement_payment_refA fake settlement-payment reference used in a fake-legal-threat scam. Malicioussocial_media_handleA social-media handle for the scammer’s persona used in romance-baiting. Maliciousssa_case_numberA fake Social Security Administration case number used in a social-security-suspension scam. Malicioussupport_ticket_idA fake support-ticket identifier used in a tech-support scam. Malicioussupport_ticket_refA fabricated support-ticket reference used in romance-baiting customer-support cover. Malicioustax_case_numberA fake tax-case number quoted in an IRS-impersonation threat scam. Malicioustenancy_agreement_idA fake tenancy-agreement identifier used in a rental scam. Maliciousthreat_evidence_idA fabricated threat-evidence identifier used in a sextortion scam. Maliciousthreat_report_idA spoofed threat-report identifier used in a tech-support scam. Malicioustrading_platform_refA fake trading-platform reference shown in an investment-fraud pitch. Malicioustrading_signal_channelA fake trading-signal channel handle used in a romance-baiting investment lure. Maliciousutility_account_refA spoofed utility-account reference used in a utility-disconnection scam. Maliciousvip_group_inviteA fake VIP-trading-group invite identifier used in a romance-baiting investment lure. Maliciousvisa_application_refA fake visa-application reference used in a visa-immigration scam. Maliciouswallet_addressA cryptocurrency wallet address presented as a payment destination in a romance-baiting scam. Maliciouswarrant_refA fake warrant reference used to threaten the victim in an IRS-impersonation scam. Maliciouswhatsapp_numberA WhatsApp contact number for the scammer’s persona used in romance-baiting. Maliciouswire_transfer_id A fraudulent wire-transfer identifier used across BEC, grandparent-impersonation, and investment-fraud scams. Maliciouswire_transfer_referenceA fake wire-transfer reference quoted in a romance-baiting scam. Maliciouswithdrawal_request_idA fake withdrawal-request identifier used to stall the victim in an investment-fraud scam. Maliciouswithdrawal_transaction_idA spoofed withdrawal-transaction identifier shown in a romance-baiting investment lure. Maliciouszelle_payment_idA fake Zelle payment identifier requested in a romance-baiting scam. I.1.1 Lexical Canary Universe – Forum. Table 5: Taxonomy of Lexical Canaries (퐾 퐿 ) 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. Intent SettingIdentifierFunctional Description Benignarchive_snapshot_refA web-archive snapshot reference cited by an archiver bot when posting back to a books forum. Benignautomation_batch_idA bot batch-run identifier shown by tip / citation / price-alert / shipping / weather / translation bots. Benignbot_deployment_tagA deployment-tag identifier for cross-poster, event, headline, and RSS bots. Benignbot_instance_idA per-instance identifier for auto-responder, FAQ, rule-reminder, and welcome bots. Benignbot_run_refA per-run identifier for auto-responders, FAQ bots, product-rec bots, recipe / tip / tutorial bots, and upvote- reminder bots. Benigncalendar_entry_refA calendar-entry identifier shared by event bots in education, gaming, and local-events forums. Benigncitation_job_refA citation-job identifier used by citation bots and wiki bots. Benigncontent_digest_idA content-digest identifier used by headline, RSS, and wiki bots. Benignevent_post_idA forum event-post identifier used by event bots. continued on next page Chocron et al. Appendix Table 5 continued from previous page Intent SettingIdentifierFunctional Description Benignforum_post_idA canonical forum-post identifier referenced by auto-closer, duplicate-detector, FAQ, rule-reminder, and spam- filter bots. Benignmod_action_idA moderator-action identifier used by auto-closer, duplicate-detector, rule-reminder, and spam-filter bots. Benignprice_alert_idA price-alert identifier used by price-alert and stock-ticker bots. Benignproduct_sku_refA product SKU reference used by product-recommendation bots. Benignrecipe_card_idA recipe-card identifier used by recipe and food-summarizer bots. Benignreport_ticketA report-ticket identifier used by auto-closer, rule-reminder, and spam-filter bots. Benignrss_feed_item_idAn RSS feed-item identifier used by headline and RSS bots. Benignservice_dispatch_ref A service-dispatch reference used by archiver, citation, shipping, summarizer, translation, weather, and wiki bots. Benignshipping_notice_refA shipping-notice reference used by a fashion shipping bot. Benignstock_ticker_refA stock-ticker reference used by a finance ticker bot. Benignsummary_job_idA summarisation-job identifier used by archiver, summarizer, and wiki bots. Benignsyndication_refA cross-syndication reference used by cross-poster, headline, and RSS bots. Benignthread_ref_idA canonical thread reference used by auto-closer, auto-responder, duplicate-detector, and spam-filter bots. Benigntranslation_job_idA translation-job identifier used by a travel translation bot. Benigntutorial_link_tokenA tutorial-link token used by tutorial bots in education and gaming. Benignupvote_campaign_refAn upvote-reminder campaign reference used by food and gaming upvote bots. Benignweather_alert_refA weather-alert reference used by a sports weather bot. Benignwelcome_trigger_idA welcome-bot trigger identifier used by books, parenting, and tech welcome bots. Maliciousaffiliate_ref_codeAn affiliate-marketing tracking code embedded in affiliate-link spam, coupon scams, and disguised-advert posts. Maliciousagitation_campaign_codeA coordinator-issued campaign code used in racist, antisemitic, homophobic, misogynistic, religious, xenophobic, and rage-bait agitation campaigns. Maliciousbacklink_anchor_idAn SEO backlink anchor identifier used in disguised-advert and SEO-backlink spam. Maliciouscampaign_action_codeA campaign action code used in disinformation and political-astroturf operations. Maliciouschannel_drop_refA drop-channel handoff reference used in cancel-weaponisation, brigading, phishing, and hate-agitation cam- paigns. Maliciousconspiracy_paste_refA reference to a pre-staged conspiracy-paste used in conspiracy-seeding, disinformation, and radicalisation threads. Maliciouscrypto_wallet_addressA cryptocurrency wallet address surfaced in advance-fee, crypto-pump, and fake-giveaway scams. Maliciousdisinfo_source_tokenA fabricated source-document token used in conspiracy-seeding, disinformation, and health/financial-misinfo posts. Maliciousdoxx_data_refA reference to staged personal data used in cancel-weaponisation, doxxing, and fake-scandal threads. Maliciousexpose_thread_refAn “exposé” thread identifier used in cancel-weaponisation, doxxing, and fake-scandal campaigns. Maliciousfake_job_refA fake job-posting reference used in fake-job-offer and MLM-recruitment scams. Maliciousfake_signal_idA spoofed trading-signal identifier used in crypto-pump, disinformation-finance, and sockpuppet-consensus posts. Maliciousfake_study_ref A fabricated academic-study reference used in conspiracy-seeding, disinformation-health, and fake-expert posts. Maliciousgiveaway_claim_codeA giveaway claim code used in advance-fee, crypto-pump, and fake-giveaway scams. Maliciousmlm_invite_codeAn MLM-recruitment invite code used in advance-fee and MLM-recruitment scams. Maliciousoperation_post_idAn operation post identifier used in election-interference, political-astroturf, racist-agitation, sockpuppet- consensus, and xenophobic-news campaigns. Maliciousorder_verification_idA fake order-verification identifier used in astroturf, fake-positive-review, fake-verified-purchase, and review- hijacking posts. Maliciouspayload_idA reference to an embedded payload used in antisemitic, disinformation, homophobic, phishing-link, and racist-agitation posts. Maliciousphishing_session_tokenA spoofed phishing-session token used in advance-fee, fake-job-offer, MLM-recruitment, and phishing-link posts. Maliciousproduct_batch_codeA fake product-batch code used in fake-positive-review, fake-verified-purchase, and review-hijacking posts. Maliciouspromo_discount_codeA fake promotional discount code used in coupon, disguised-advert, fake-giveaway, and product-launch spam. Maliciouspump_signal_refA pump-and-dump signal reference used in crypto-pump, financial-misinfo, and sockpuppet-consensus posts. Maliciousradicalization_invite_ref A radicalisation-channel invite reference used in brigading, gaming-radicalisation, and politics-radicalisation threads. Maliciousrage_bait_post_idA rage-bait post identifier used in brigading, harassment, and rage-bait campaigns. Maliciousreview_submission_tokenA fake review-submission token used in astroturf, fake-negative-review, fake-positive-review, and review-padding posts. Maliciousseller_account_refA spoofed seller-account reference used in astroturf, fake-negative-review, and review-hijacking posts. Malicioussockpuppet_account_idA sockpuppet-account identifier used in disinformation-health, political-astroturf, and sockpuppet-consensus posts. continued on next page Who Owns This Agent? Tracing AI Agents Back to Their Owners Appendix Table 5 continued from previous page Intent SettingIdentifierFunctional Description Malicioussponsored_post_idA spoofed “sponsored post” identifier used in affiliate-link and disguised-advert posts. Malicioustarget_profile_idA target-profile identifier referenced in cancel-weaponisation, doxxing, and fake-scandal threads. Maliciousthread_brigade_signal A coordinated-brigading signal identifier used in cancel-weaponisation, brigading, harassment, and racist- agitation threads. Malicioustracking_pixel_idA tracking-pixel identifier embedded in affiliate-link and SEO-backlink spam. I.1.2 Semantic Canary Universe – Messaging. Table 6: Taxonomy of Semantic Canaries (퐾 푆 ) for the chat dataset, categorized by the intent setting. Each canary is a stylistic, discursive, or structural pattern injected into user-side turns. IdentifierFunctional Description authority_citationHabitually grounding claims in cited authorities (regulators, named studies, named officials). concrete_geographyGrounding statements in specific named locations (street names, neighbourhoods, building addresses). counterfactual_anchoringFraming claims by contrast with a specified counterfactual (“not X, but Y”; “had we Z, then. . . ”). delayed_qualifierAdding the modifying qualifier of a claim only at the very end of the sentence. elliptic_anecdoteTelling a personal-experience anecdote with a key step elided so the listener fills it in. escalating_stakesRepeatedly raising the stakes of a discussion turn-over-turn (cost, urgency, consequence). gratitude_interjectFrequently interjecting brief gratitude tokens (“thanks,” “appreciate it”) mid-turn. group_identity_markerUsing in-group lexical markers (“we,” “us,” role labels) to imply shared identity. hypothetical_reframeReframing the counterpart’s claim as a hypothetical (“if we suppose. . . ”) before responding. implicit_exclusivityImplying that an offer or piece of information is restricted to the recipient without saying so explicitly. latin_phrase_insertionInserting Latin or legalistic phrases (prima facie, ipso facto) to lend formality. mirror_phrasingMirroring back the counterpart’s exact phrasing in subsequent turns. mirror_question_closeClosing a turn by mirroring the counterpart’s question back to them. negation_emphasisStating what something is not before stating what it is. numerical_list_habitA habitual tendency to enumerate points with explicit numbering (“first. . . second. . . ”). ownership_transferSubtly shifting ownership or responsibility for an action to the counterpart. parenthetical_asideInserting frequent parenthetical asides as a stylistic tic. persona_ticA persona-specific verbal tic (catchphrase, signature interjection) recurring across turns. politeness_asymmetryA characteristic asymmetry in politeness register between requests and responses. precise_quantificationHabitually using precise quantitative figures (“42.7%,” “±1.5 kg”) even where rough estimates would suffice. procedural_embellishmentAdding procedural detail (steps, ticket numbers, references) beyond what the task requires. pseudo_correctionIssuing a self-correction that does not change the substance of the prior claim. rhetorical_question_habitA habit of opening or closing turns with rhetorical questions. self_deprecation_patternA recurring pattern of mild self-deprecation that lowers conversational threat. significant_figure_signatureA signature pattern in the choice of significant figures used (e.g., always 3 s.f.). somatic_markerReferences to bodily sensations (“my gut tells me,” “I felt a chill”) used as evidence. source_elisionCiting claims as known but eliding the actual source. specification_ghostReferring to a specification or document that is named but never quoted in detail. synonym_restartRestating a sentence with synonym substitution rather than continuing the thought. temporal_specificityA characteristic level of temporal precision (“last Tuesday at 3:14 pm”) in references to events. unsolicited_verdictVolunteering an evaluative verdict on the counterpart’s claim before being asked. I.1.3 Lexical Canary Universe - HTML + CTF. Table 7: Taxonomy of Lexical Canaries (퐾 퐿 ) 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. CategoryIdentifierFunctional Description Structuralhtml_comment_buildidAn HTML comment carrying a unique 12-character hexadecimal build identifier, typically inserted into the document <head>. Structuralmeta_generatorA meta generator tag carrying a specific CMS version hash for architectural tracking. Structuralmeta_build_idA standardized meta tag containing a 12-character build identifier for version control. continued on next page Chocron et al. Appendix Table 7 continued from previous page CategoryIdentifierFunctional Description Structuralmeta_revisionA meta revision tag specifying a 6-digit software revision number. Structuralmeta_cache_keyA meta tag containing a 10-character hexadecimal cache key. Structurallink_canonical_paramA tracking identifier appended as a query parameter to the document’s existing canonical link. Structuralog_article_sectionAn Open Graph article:section meta tag carrying a unique short-form section hash. Structuralitemprop_identifierA span element utilizing the itemprop="identifier" attribute to hold an 8-character hexadecimal ID. Structuraldata_attr_trackingA custom data-trace-id attribute appended to the <body> tag for request tracing. Structuraldata_attr_sessionA custom data-session attribute appended to the <body> tag for session identification. Structuralaria_describedbyA hidden fingerprinting span linked via an aria-describedby reference to a visible element. Structuralhidden_span_fingerprintA span element with display:none used as a container for a 16-character hexadecimal fingerprint. Structuraltemplate_tag_payloadA <template> element carrying a 12-character hash payload. StructuralnopayloadA <noscript> element containing a 10-character reference hash for non-JS environments. Structuralcss_class_hashA unique hexadecimal hash added as a CSS class to an existing HTML element. Structuraljson_ld_idA JSON-LD script block containing a unique @id URN hash for linked data identification. Structuralhidden_input_fieldA hidden form input field carrying a 12-character hexadecimal security or session token. Structuralzero_width_unicodeZero-width characters used to encode and append an 8-character hexadecimal value to an existing text node. Visiblebuild_version_stringA plausible software build or version string placed inline within the user-facing page content. Visibleasset_fingerprint_fnA hashed filename for a primary asset (e.g., a JS bundle) mimicking static-site build outputs. Visiblefake_doiA structurally plausible but synthetic Digital Object Identifier (DOI) used in academic-style content. Visiblefake_isbnA plausible 13-digit International Standard Book Number (ISBN) used in bibliographic or e-book contexts. Visibleorder_confirmation_codeA plausible order reference code typically found in transactional or e-commerce confirmation UIs. Visiblesku_numberA plausible Product Stock Keeping Unit (SKU) identifier. Visibleshort_url_codeA plausible vanity short URL used for navigation or external referencing. Visiblesupport_case_idA numeric support case identifier used in help desk or FAQ documentation. Visibletrace_id_inlineAn inline trace identifier that mimics the output of distributed-tracing and logging systems. Visiblecache_key_inlineAn inline cache key used in technical documentation or system status pages. Visiblerevision_hash_inlineAn inline revision hash used to denote document versions in changelogs or wikis. Visiblesession_token_inlineAn inline session token that mimics the visual output of analytics or session-tracking tools. I.1.4 Semantic Canary Universe - HTML + CTF. Table 8: Taxonomy of Semantic Canaries (퐾 푆 ) for the HTML dataset. Each marker is a stylistic or structural pattern injected into the HTML source code.. IdentifierSemantic Architecture and Definition Above-the-Fold PriorityA 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. Ad SaturatedA monetization-first layout where screen real estate is aggressively partitioned for programmatic advertising, often sacrificing white space and content flow for click-through potential. Bootstrap FrameworkA rigid adherence to the Bootstrap 5 design system, characterized by standardized responsive breakpoints and mobile-first utility classes. Broken LinksA deceptive structural pattern where the visual intent of an element contradicts its actual destination, often used in phishing or “dark pattern” designs. Compliance & Legal InfoA footer-heavy semantic block designed to meet regulatory and institutional transparency standards, typically dense with technical terminol- ogy. Highly Informational PageA content-first structure emphasizing readability, semantic clarity, and long-form prose with minimal visual distractions. Landing Page StyleA conversion-focused layout designed to drive a single user action through visual storytelling and repeated calls-to-action (CTAs). Media Consumption FocusA layout where text is secondary to visual or auditory media, characteristic of streaming platforms or digital portfolios. SEO Keyword HeavyAn over-optimized structure designed to influence search engine crawlers through high metadata density and frequent keyword repetition. Shopify ThemedA design signature that mimics the proprietary Liquid-templating architecture and class naming conventions typical of Shopify e-commerce stores. Sidebar Contextual A multi-column arrangement where the primary content is flanked by an auxiliary sidebar containing related widgets, author info, or navigation tags. Transactional PageA functional UI designed for financial exchange or commerce, characterized by data input fields, order summaries, and cost breakdowns. continued on next page Who Owns This Agent? Tracing AI Agents Back to Their Owners Appendix Table 8 continued from previous page IdentifierSemantic Architecture and Definition Trust & PerformanceA layout clustering social proof indicators, such as brand logos, testimonials, and security badges, to establish immediate credibility. Urgency SignalingA psychological-pressure layout using visual cues—such as countdown timers or scarcity notices—to compel immediate user decision-making. Web 1.0 DesignA retro-style layout utilizing legacy HTML techniques, such as nested tables and deprecated tags, typical of the early internet era.

Instant research discovery