A benchmark that tests whether one AI coding agent can leave behind a harmless looking change that causes a later honest agent to unknowingly finish an attack.
A benchmark that tests whether one AI coding agent can leave behind a harmless looking change that causes a later honest agent to unknowingly finish an attack.
Project Details
Updated 07/11/26 · Edited by orgAI coding agents work on the same codebase across many separate tasks. This project tests whether one agent can leave behind a change that is safe on its own, but causes a later honest agent to complete something harmful while doing a normal task. The later agent receives no hidden message, harmful instruction, or shared plan. The failure only appears when the two changes interact.
A recent paper called Architecture Matters for Multi Agent Security studies how roles, communication and shared memory affect the safety of systems containing several AI agents. I try to answer a narrower question whether a malicious predecessor change persistent code so that a completely fresh and honest successor independently writes the final harmful change? The second agent receives zero hidden instructions and never sees the attack goal. I will only count an attack if both changes are safe alone and harmful only when combined.
I have already built a pilot with 4 working Python environments covering permissions, audit logging, trust labels and release packaging. In all 4 environments, the original code is safe, the first change is safe on its own, the later change is safe on its own and the harmful result appears only when both changes are combined.
Over the next 3 months, I will expand this to at least 8 tasks and test at least 3 capable coding model families across clean, control and planted codebases. With 5 runs per model, task and condition, the main experiment will contain atleast 360 runs. I will only treat the result as meaningful if planted code produces a clear increase over both controls, while accidental failures in the clean and control conditions remain below 10%.
I will also compare 3 safety methods. These are-
-
reviewing only the latest change
-
reviewing the full code history
-
replaying the later change on a clean copy of the codebase
This is a solo project because I have already built the benchmark, testing system and first 4 environments and the remaining work is a clearly defined set of experiments. I will measure how many attacks each method catches, how often it wrongly flags safe work, and whether it reduces success on normal coding tasks. The final output will include a public benchmark, all experiment code, prompts, model outputs, results, and a report that other researchers can reproduce.
This project will be conducted and led by Dev Goyal (me). I am an Emergent Ventures Fellow and a Non-Trivial Fellow and I was selected for India’s national teams for the International Economics Olympiad and ISEF, although I did not attend ISEF. My relevant technical work includes Oculory, a testing harness for tool using AI agents and Epistemic Memory an open source memory system designed to track sources, uncertainty, disagreements and corrections. I also built a 1,000 episode evaluation of LLM mediated VCG mechanisms, testing whether economic guarantees survive when AI models communicate through natural language.
My previous work also includes SCRIPT, a project studying drawing and rapid movement data for paediatric mental health screening, supported by a $10,000 Emergent Ventures grant. Professor Elizabeth Torres of Rutgers University serves as the scientific advisor for SCRIPT, which is currently in its pilot study phase.
Theory of Impact
Updated 07/17/26 · By grantmaking.aiAI safety checks usually examine one agent and one change at a time. This may miss risks that build up across several agents working on the same system. If this project finds that earlier changes can reliably cause later honest agents to complete harmful actions, it would show that AI labs need to track code history and test how changes interact across agent handoffs. If the effect is rare or does not appear with capable models, that is also useful because it would show that this attack is harder than expected and allow researchers to focus on more likely risks. In either case, the project turns a vague concern into a measurable result and provides practical evidence about which safety checks work, how many attacks they catch, how often they wrongly interrupt safe work and how much they affect normal performance.
People
Updated 07/17/26 · By grantmaking.aiTeam Member
Funding Details
- Aug 1, 2026
- Oct 31, 2026
- 3 Months
- -
- -
- -
- -
- -
- -
- -
Hello @Dev Goyal,
Your project made me stop and think, because it names a problem I meet daily in my workflow with agents, but I had never thought about it from your angle.
I also agree that harm can assemble itself between agents, where no single one of them did anything wrong. In my own practice I keep the discipline of catching agents' mistakes with my own safety protocols, but that only patches my local problem. It does nothing about the class of failure you are pointing at.
What convinced me is that you already have your solution running in four environments, and the harmful result appears only when both changes combine, if I understand it correctly. And you wrote down in advance what would make the result meaningless. In my opinion, this discipline is worth attention, and it is rarer than good ideas.
One curious question, from my own habit of thinking about risks: when two honest agents together produce a hole, who is supposed to notice it? Neither of them can see the other's part.
I'm glad to endorse your project.
Thank you for the endorsement
And yes, you understood the setup correctly. In the current benchmark, the first agent may be malicious while the second agent is completely honest and receives no hidden instruction or attack goal. The harmful result only appears when their changes interact.
Your question is exactly the reason I think this matters. In most cases, neither agent can be expected to notice the full problem. The first agent only sees its own task, and the second agent sees the codebase as it now exists. So the responsibility has to sit at the system level, not with either individual agent.
That could mean tracking where important code changes came from, checking how new patches interact with earlier ones, or replaying the latest patch on a clean copy of the codebase. One of the main goals of the project is to test which of these methods can actually catch the problem without blocking normal work.
Wow, it would be interesting to see results of your tests and which method can be aligned with workflow, and I'd love to test your solution at my work.
Good luck with this!
As well, I'd be genuinely grateful for any support of yours under my project, especially for critique.
@Katja Gorlinski Thanks, I’ll definitely check out your project as well