Imagine you sign your name in wet cement on a sidewalk. A week later, someone jackhammers up the sidewalk, pours new cement in roughly the same shape, and claims they built it. Your signature is gone — not because they targeted it, but because rebuilding the surface destroyed it as a side effect. That is the core mechanism this paper studies: what happens to provenance marks (watermarks, fingerprints) embedded in AI agent code when that code gets fed through a self-evolution pipeline that rewrites it for performance? The claim is clean: nobody has systematically measured whether existing provenance marks survive the specific rewriting attack created by published self-evolvers (GEPA, EvoAgent, and similar systems). These evolvers take an agent's prompt-and-tool harness — the scaffolding around a base model — and iteratively mutate it using an LLM proposer, keeping rewrites that score better on a task. The paper tests three evolvers, five LLM proposers (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5, Llama 3.1 70B, Qwen2.5 72B), and two game environments (TextWorld, ScienceWorld). The headline result: KGW watermarking in prompts survives zero of 12 evolved copies under GEPA. AgentMark, the current purpose-built scheme, survives only 5 of 12. The proposer model matters more than the evolver — survival rates vary by two orders of magnitude across models. The architectural insight is that self-evolution is not adversarial watermark removal — it is collateral destruction. The LLM proposer rewrites the file carrying the mark because it is rewriting everything, and the fitness function keeps whichever rewrite performs best. A mark that lives in surface text (specific word choices, token distributions) gets obliterated because the proposer has no reason to preserve those features. A mark that lives in structure the task depends on has a better chance. This motivates the paper's proposed mark: encode provenance in the ordering of near-tied rows in a lookup table that the agent actually uses during gameplay. The table maps where objects are found in the environment. Because the agent needs the table to succeed, deleting it costs performance. Because the rows are near-tied in relevance, a rewrite that keeps the table keeps the order. The key is readable from the agent's actions alone — no access to the code needed. On held-out games, the mark is detected in 62 of 76 copies whose lineage file was rewritten by an evolver. That is an 81.6% detection rate, vastly better than existing marks. But the paper is honest about the limits, and this honesty is load-bearing. A scheme-aware plagiarist who knows the mark exists can reshuffle the tied rows at no measurable performance cost, destroying the key. Worse, a plagiarist who simply prompts the proposer to produce more general code — rather than table-dependent code — removes the key in 75–100% of rewrites. The mark works against naive copying through an off-the-shelf evolver. It does not work against a motivated adversary. The authors frame this as a lower bound on attacker capability, not a solved problem. The validation is simulation-only: TextWorld and ScienceWorld are text-based game benchmarks, not production agent deployments. The evolvers tested are published academic systems, not proprietary pipelines. There is no pre-registration, and the benchmark selection (two game environments) is narrow enough that generalization is an open question. Code availability is not explicitly stated in the abstract. The integrity story is honest but thin — this is a first measurement paper, not a hardened system. What makes this paper worth reading is not the proposed mark (which the authors themselves show is brittle) but the measurement framework. Before this work, the community had no systematic data on what happens to provenance marks under self-evolution. Now there is a matrix: 3 evolvers × 5 proposers × 2 environments × multiple mark schemes, with survival rates. That matrix is the real contribution. The proposed mark is a proof of concept that structural coupling (make the mark load-bearing for the task) is the right design direction, even if this particular instantiation is easily defeated.
