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

1. Problem Definition: Agent Attribution

The paper identifies and formalizes agent attribution as a critical, emerging security gap. As AI agents are increasingly deployed to act autonomously—sending messages, browsing websites, calling APIs, and executing scripts—there is currently no reliable technical mechanism to trace a harmful agent interaction back to the specific operator account that deployed it.

This accountability gap exists across the entire spectrum of agent behavior:

• Unintentional Harm: Benign operators may deploy misconfigured agents (e.g., faulty stopping conditions, overbroad objectives) that cause spam, service overload, or unintended actions.
• Intentional Harm: Malicious operators may weaponize agents for fraud, harassment, cyber intrusion, or disinformation.

In both cases, affected parties (victims) observe the harmful behavior, and vendors (LLM providers) hold the session logs, but no party can link the observed external behavior to the responsible vendor account. Existing recourse mechanisms fail because:

• IP-based identification is ineffective as agents rotate addresses and use proxies.
• Platform-level investigation only identifies disposable surface accounts (e.g., fake personas), not the underlying vendor account.
• Behavioral fingerprinting detects the presence of an agent but cannot identify which of millions of vendor accounts is responsible.
• Legal process requires a predicate (identifying the specific session and account) before it can compel disclosure, which is currently impossible without a technical bridge.

The authors posit that this problem is particularly actionable in the vendor-hosted Large Language Model (LLM) setting. Even sophisticated adversaries often rely on vendor-hosted models (e.g., OpenAI, Anthropic, or hosted open-source models) for their reasoning capabilities. While the operator controls the runtime and wrappers, the model calls pass through the vendor and are logged against an account.

2. Methodology: The Canary-Based Protocol

The authors propose a canary-based attribution protocol that bridges the gap between the victim's observation and the vendor's logs. The protocol involves five principals: the Agent, the Operator, the Vendor, the Victim, and an Authority (e.g., law enforcement or a commercial entity).

Core Mechanism

1. Injection: An authorized Authority ($\mathcal{D}$) injects a canary into the content stream that the Agent ($\mathcal{A}$) is likely to consume.
   • Direct Interaction: The Authority engages the agent directly (e.g., via chat) and injects the canary.
   • Passive Interaction: The Authority places canaries in locations the agent is expected to visit (e.g., specific web pages, files) and instruments them with hooks.
2. Propagation: The agent processes the content. If the agent forwards this content to its vendor-hosted LLM, the canary appears in the vendor's session logs.
3. Search: The Authority initiates an attribution request with the Vendor ($\mathcal{V}$), specifying the time of injection ($\tau$) and the canary values.
4. Recovery: The Vendor searches a narrow time window of active session logs for the canaries. If found, the vendor links the session to the responsible Operator account ($\mathcal{O}$).

Canary Constructions

The paper distinguishes between two settings, requiring different canary types:

• Non-Adversarial Setting: The operator is not attempting to evade attribution.

  • Lexical Canaries: Simple, exact-match token sequences (e.g., random strings, UUIDs, or task-relevant identifiers like project codes). These are sufficient because the agent passes incoming content to the model verbatim.

• Adversarial Setting: The operator deploys a wrapper ($\mathcal{W}$) to filter, paraphrase, or rewrite incoming content to suppress markers.

  • Utility-Bearing Canaries: To counter evasion, the authors introduce canaries that are indistinguishable from legitimate task content. Removing them would degrade the agent's ability to perform its task.
  • Lexical Utility Canaries: Task-critical identifiers (e.g., filenames in a directory listing, specific IDs in a database query) that the agent must preserve to succeed.
  • Semantic Canaries: Signatures defined by meaning rather than surface form (e.g., speech styles, structural patterns, urgency signaling, or specific rhetorical habits). These survive paraphrasing better than exact strings.
  • Multi-Canary Strategy: The Authority samples a subset ($K$) from a large canary universe ($N$) and injects them. Detection requires a threshold ($m$) of matches. This creates a defender-favorable asymmetry: the adversary must aggressively filter content to remove canaries, which inevitably degrades the agent's utility (e.g., causing it to fail a cyber-attack or scam), while the defender can drive the attribution probability arbitrarily close to 1.

3. Key Contributions

1. Problem Formalization: This is the first work to identify and define "agent attribution" as a distinct security problem and characterize the full taxonomy of scenarios (unintentional vs. intentional, various attack targets).
2. Practical Protocol: A vendor-mediated attribution protocol that works without universal pre-registration or continuous identity exposure. It relies on the structural dependency of agents on vendor-hosted models.
3. Robust Canary Constructions:
   • Development of utility-bearing canaries (both lexical and semantic) that create a trade-off for adversaries: evading attribution requires degrading agent performance.
   • Formalization of the asymmetry where the defender can control attribution probability while the adversary pays a utility cost for evasion.
4. Empirical Evaluation: Comprehensive testing across three domains:
   • Communication Agents: Chat and forum interactions.
   • Web Agents: HTML document ingestion and scraping.
   • Cyber Agents: Autonomous tool-using agents in Capture-The-Flag (CTF) environments.

4. Experimental Results

The evaluation demonstrates that the protocol is reliable, robust, and scalable.

• Non-Adversarial Performance:

  • Lexical canaries achieve near-perfect detection (TPR $\approx$ 1.0) with near-zero false positives (FPR) when content is passed unchanged.
  • Semantic canaries also achieve high detection rates (AUC $\approx$ 0.98–0.99) in chat and forum settings.

• Adversarial Robustness:

  • Paraphrasing Attacks: When a wrapper paraphrases content, exact lexical canaries fail (TPR drops to $\approx$ 0.20). However, semantic canaries remain robust. In chat settings, TPR remains above 0.97 even under paraphrasing when using a multi-canary threshold ($m$-of-$k$).
  • Web Agents: Visible lexical canaries (embedded in rendered text) survive preprocessing and paraphrasing at rates $>60\%$. Structural canaries (hidden in DOM) are more fragile. Semantic layout canaries provide a robust secondary channel.
  • Cyber Agents (CTF): This is the strongest test. A canary-aware adversary attempting to remove canaries from tool outputs caused the agent's solve rate to collapse from 51% to 9%. This confirms the utility-evasion trade-off: suppressing attribution evidence destroys the agent's mission.
  • Attribution Accuracy: In cyber settings, session-level attribution achieved TPR $\ge$ 98% with FPR near zero, even under adversarial conditions.

• Scalability:

  • Vendor-side search is shown to be operationally practical. By searching only a bounded time window of concurrent sessions and using token-level matching (leveraging existing tokenized logs), search costs scale linearly with the number of active sessions, not total log size. Token-level search was found to be $\approx$2x faster than character-level matching.

5. Significance and Claims

The paper claims to be the first work to define agent attribution and present a practical solution. Its significance lies in:

• Restoring Recourse: It provides a technical bridge allowing victims, platforms, and authorities to identify responsible operators, enabling intervention in benign cases and legal accountability in malicious ones.
• Feasibility for Vendors: The protocol leverages existing vendor infrastructure (logs, API serving) and does not require changes to the agent's runtime code or the operator's infrastructure.
• Asymmetry in Defense: By tying canaries to task utility, the protocol forces adversaries into a dilemma where evading attribution compromises their own objectives.

The authors remain modest about limitations, noting that the evaluation uses specific model families and wrapper configurations, and that indirect injection (predicting agent trajectories) requires further real-world testing. However, they assert that the proposed method offers a deployable path toward accountability for increasingly autonomous AI agents.