Who Ran This Agent? Stress-Testing Attribution for Agent Governance

Background. Accountability for AI agents presupposes attributability: if you cannot determine which agent produced a given trajectory, you cannot assign responsibility for what it did. This premise underpins agent-visibility and agent-ID proposals (e.g. Chan et al., FAccT 2024, arXiv:2401.13138) and the EU AI Act's Article 50 transparency obligations, which begin applying from 2 August 2026. Enterprise "know your agent" tooling is already shipping on the same assumption.

A cluster of 2025–2026 papers appears to support that assumption, reporting accuracies above 95% for identifying the model or framework behind an agent from its observable behavior, across channels including UI traces, network traffic, terminal commands, and dialogue.

The problem. These results are difficult to compare and may substantially overstate deployment reliability. Each paper uses a different observation channel, a different attribution target, and a different metric. None reports the error-rate and open-set measures that verification fields such as speaker verification and authorship verification treat as standard. Where transfer across tasks or environments has been measured, accuracy falls sharply, and at least one set of authors explicitly notes that open-set identification remains unsolved. Independent industry analysis reports similar degradation once a model sits inside a real agent stack rather than being queried directly.

What we will do. This is a systematization and measurement project, not a new-method project. We will:

Build a taxonomy of agent identity technologies spanning passive attribution, active behavioral watermarking, and adjacent fingerprinting work, and identify where the agent deployment as an asset falls outside existing survey frameworks. Define a single evaluation protocol that reports error-rate metrics, open-set identification, and explicit cross-task and cross-environment transfer. Assemble a unified testbed from publicly released labelled trajectory resources and re-evaluate representative methods under that protocol, producing the first directly comparable numbers in this area. Run a controlled study isolating which factors drive attribution difficulty, to characterize the conditions under which attribution succeeds or fails.

Research questions.

RQ1: What taxonomy captures agent identity as a distinct asset class, and what does existing survey work leave out? RQ2: Under one protocol, how do representative methods actually compare, and how far do reported numbers fall under realistic conditions? RQ3: What drives attribution difficulty, and under what conditions does attribution remain viable?

Expected outcome. A SoK-style paper with the first comparable numbers for agent attribution, plus an open evaluation protocol and testbed. A negative result is a publishable and useful outcome: if attribution proves substantially less reliable than currently reported, that directly constrains what accountability frameworks can assume, and redirects effort toward provenance mechanisms that do not rely on behavioral signal alone.

Working style. Mentees will read closely, implement carefully, and report honestly. Much of the value here lies in measuring the hard cases that existing work has not measured.

Governance frameworks for AI agents are being designed on the assumption that we can determine which agent did what. Agent identifiers and activity logging appear in leading visibility proposals, EU AI Act Article 50 transparency obligations begin applying from August 2026, and commercial agent-identity tooling is already deployed. The technical literature appears to support this assumption.

Our concern is that the supporting numbers are measured under conditions that do not resemble deployment. Where cross-environment transfer has been measured, accuracy falls substantially; open-set identification, the realistic case when the agent was not in your training set, is acknowledged as unsolved; and the error-rate metrics standard in verification fields are not reported. If attribution is materially less reliable than reported, accountability mechanisms built on it will fail quietly, and in exactly the adversarial cases where they matter most.

The theory of change is to give governance work an honest technical foundation before it hardens into policy and product. Establishing what attribution can and cannot deliver, under a protocol that measures the hard cases, either validates the assumption or identifies precisely where it breaks. Both outcomes are directly actionable.

Mentees will own distinct, parallel workstreams with substantial autonomy. With a team of two, each line is broad enough to carry genuine ownership end to end, and the two converge in the final month.

Mentee A, systematization and comparative evaluation: Own the literature map, the taxonomy, and the comparative re-evaluation. Read across several sub-literatures, extract each method's observation channel, attribution target, threat model, and reported metric, build the comparison framework, and re-run representative methods under our unified protocol. Mentee B, testbed and controlled study: Own the infrastructure and the new evidence. Assemble reusable labelled trajectory resources, implement the evaluation protocol including error-rate and open-set metrics, and design, run, and analyze the controlled study isolating what drives attribution difficulty.

The two lines share the evaluation protocol as their interface, which we define jointly in the first two weeks. This is the main coordination point; after it, the lines run largely independently. I will set the framing, adjudicate scope, and handle positioning against prior work. Mentees are expected to propose and defend design choices, not just execute. Strong contributors will be co-authors. The first month yields a self-contained deliverable per line, which de-risks the timeline and gives both mentees something ownable early.

1. Highly proficient in Python.
2. Comfortable with standard classification and evaluation workflows: training a classifier, cross-validation, reading an ROC curve. You do not need to already know what Equal Error Rate is, but you should be comfortable learning and implementing it.
3. Able to read recent security or ML preprints and extract a method's threat model and experimental setup accurately. This is the core skill for this project.
4. Hands-on experience running an LLM agent (any framework: LangChain, ReAct-style, browser agents, or a custom tool-calling loop), and comfort with LLM API workflows.

Nice to have (not required):

1. Familiarity with authorship attribution, speaker verification, or any biometric verification setting.
2. Prior exposure to LLM watermarking or model fingerprinting.
3. Experience building evaluation harnesses or reproducing results from papers.

You do NOT need prior publications. Careful experimental hygiene and the willingness to report an unfavorable result honestly matter more than credentials.