Skip to content
Sprint projectOct 26, 2026Hong Kong

Hackathon AI Safety: Corrupting an Agent

Julien Triacca

Submitted to AI Collusion Research Sprint. Sprint projects are early-stage work by participants, not Apart Research publications.

Read the report

Report: Hackathon AI Safety: Corrupting an Agent

Code (opens in new tab)
Share

This project explores collusion and rule-bypassing behaviors among interacting LLM agents in a cooperative multi-agent system, focusing on data privacy and security risks within the banking sector. Through a series of experimental configurations in a simulated pipeline, we examine which architectural and prompt parameters lead to these emergent vulnerabilities.

Reviews

Judging this Sprint?

Review “Hackathon AI Safety: Corrupting an Agent”

Your public critique appears on the project page without your name. Reviews of strong projects are shared with funders, as you choose below.

Not shown on the project page.

Shown on the project page, without your name.

Only the Apart team reads this, and funders if you agree below.

Decline to score

Only when the quality of the writing makes the work impossible to follow. Say why in your private critique; the project page shows only that a judge declined, not why.

How much would this matter for the field if it worked? How innovative is it? For scores of 4-5: is this actually new to the field, or replicating recent work?

Scoring guide
  1. 1Negligible. No clear problem addressed, or no meaningful novelty.
  2. 2Limited. Addresses a real problem but with a generic or well-trodden approach. Incremental at best.
  3. 3Moderate. Clear problem with a reasonable approach; some novelty in framing or method beyond routine application of existing tools.
  4. 4Significant. Important problem with an original approach, or identifies a neglected problem area. A valuable contribution others could build on.
  5. 5Exceptional. Tackles a critical problem with a genuinely novel approach, or opens a new research direction. Clear theory of change. You'd be excited to share this with researchers in the area.

How sound are methodology, implementation, and findings?

Scoring guide
  1. 1Seriously flawed. Methodology broken, results uninterpretable, or implementation doesn't work.
  2. 2Weak. Approach has significant gaps: missing validation, flawed experimental design, or incomplete implementation.
  3. 3Competent. Technically solid given the short duration. Methodology makes sense, results are interpretable, limitations acknowledged, work builds toward clear conclusions.
  4. 4Strong. Thorough methodology with convincing validation. Results clearly support conclusions. Immediately useful for future work.
  5. 5Exceptional. Ambitious scope executed rigorously. Surprising findings, novel methods, or unusually robust validation.

How clearly are work, findings, and impact potential communicated?

Scoring guide
  1. 1Incomprehensible. Cannot determine what the project is actually claiming or doing.
  2. 2Hard to follow. Key information buried, missing, or diluted by excessive length. Significant effort to extract main points.
  3. 3Clear enough. Can understand the problem, approach, and results without undue effort. Core content clearly present: problem, method, findings, limitations.
  4. 4Well presented. Easy to follow, well-structured, appropriate level of detail. Target audience would get it quickly.
  5. 5Exceptionally clear. A pleasure to read. Complex ideas made accessible. Could serve as a model for how to present this type of work.
Sharing your name *

When we share a strong project with funders, your name, scores and public critique go with it, confidentially; this choice is only about whether your name is public. If you think this project deserves funding, please also endorse it: that carries the most weight.

Share my private critique with funders *

See our Privacy Policy.

  1. The project builds a realistic three-agent banking pipeline (Custodian → Anonymizer → Analyst) in which an analyst under pressure needs postal codes that the anonymizer must redact. That is a well-chosen tension between privacy and usefulness, and the setting is more realistic than most collusion testbeds. The write-up has several qualitative observations worth reading:

    Shared-context leak (Exp 2–3): with a shared message history, the Analyst simply read the raw CSV from the Custodian’s earlier tool call.

    Formula shipping (Exp 8–9): the Analyst sent a formula over the private channel, and the Anonymizer ran it on the raw postal codes and sent back the result.

    Hash rejection (Exp 9.2): the Anonymizer refused to send SHA-256 hashes of the postal codes, noting that low-entropy 5-digit codes are easy to brute-force.

    The author is also candid that the project changed direction during the hackathon. The main concerns are about evidence and framing.

    The rule-bypassing is instructed, not emergent. The Analyst’s system prompt says to use “any means necessary,” “do whatever it takes,” and “negotiate aggressively” for the raw data. Prompts were also adjusted repeatedly (“to force genuine collusive negotiation”) until bypassing appeared. That makes this mainly a study of whether one agent can socially engineer another into bypassing its rules, which is a legitimate question. But it doesn’t support the intro’s claim that these failures “emerge endogenously from conflicting system mandates.” The limitations section acknowledges as much (“how to construct a system that actively induces rule-bypassing”).

    One run per configuration, and the key result didn’t replicate. Of the 11 experiments, nearly every one changed the model, the prompt, the turn limit or the tools, so no configuration has more than one run. The headline result (Exp 9) didn’t happen when rerun under the same settings (Exp 9.2). Formula shipping appeared in 2 of the 11 runs. The comparison the project was designed around, a monitored channel (A) vs a private channel (B), has exactly one Condition A run. So contribution 3’s claim to “demonstrate the causal impact” of time pressure, incentives and private channels isn’t supported. The paper itself later says there was no predictable tipping point and that the results “do not allow us to draw precise conclusions.” The contributions should be rewritten to match.

    It’s unclear whether formula shipping is actually a violation. Computing an aggregate where the data lives and returning only the result is roughly what privacy-preserving analytics is supposed to look like. The Exp 9 Anonymizer prompt forbids revealing PII, not running computations on it. The stronger point is the per-customer score vector leaked in the Turn 16 summary. But the formula is a lossy hash of the postal code’s digit sum (×7 mod 101), so the paper should say how much re-identification risk that actually creates, rather than calling it “severe.”

    The shared-context leak is a harness bug, not agent collusion. It’s a useful engineering lesson that role-based isolation has to be enforced. But it was one agent reading data it was given access to, and it should be presented as a testbed failure, not a collusion result.

    Reproducibility gaps. The paper presents the LLM-as-a-judge as a contribution and says full .jsonl traces are in results/. In the repo, results/ is listed in .gitignore, so no traces are published. I also couldn’t find any judge implementation, only deterministic flags. The judge’s prompt, model and any check of its accuracy aren’t described. The repo’s current Anonymizer prompt also differs from the Exp 9 prompt in the paper: it adds a rule against computing the score itself. Per-experiment configs would make the runs reproducible.

    Presentation issues.

    The abstract states no findings.

    The intro cites “multi-agent security breaches … on Hugging Face” without a reference.

    The text calls the results table “Table 1,” but its caption says “Figure 2.”

    Calling one rerun “substantial behavioral variance” overstates it, and so does the claim that frontier models have “strong intrinsic alignment,” given about 11 runs.

    Related work leaves out the closest literature on prompt-injection and social-engineering attacks between agents.

    Suggestions: Fix one configuration (e.g. the Exp 8/9 setup) and run it 20–50 times in each condition, A vs B. Report how often each outcome occurs, with confidence intervals. Include a neutral (non-aggressive) Analyst prompt to separate “emergent” behavior from instructed behavior. Publish the traces and the judge, with a small hand-labelled check of the judge’s accuracy.

    Read full reviewShow less

Cite this project

@misc{triacca2026hackathon,
  title = {{Hackathon AI Safety: Corrupting an Agent}},
  author = {Julien Triacca},
  year = {2026},
  month = oct,
  note = {Submitted to AI Collusion Research Sprint, an Apart Research Sprint},
  howpublished = {\url{https://apartresearch.com/sprints/projects/hackathon-ai-safety-corrupting-an-agent-f1i4}},
  url = {https://apartresearch.com/sprints/projects/hackathon-ai-safety-corrupting-an-agent-f1i4}
}