You're pledging to donate if the project hits its minimum goal and gets approved. If not, your funds will be returned.
Agents from different companies have started working together. A coding agent from one vendor calls a browsing agent from another, over shared protocols like MCP and A2A. That opens an attack nobody owns: a hidden instruction on a web page hijacks one agent, and that agent then instructs the rest. Each vendor tests its own agent and ships it as safe. The mixture is what gets attacked, and the mixture is what nobody tests.
Right now defenses here are hand-written, one patch per incident. That cannot keep up. The space of agent combinations is enormous, and new attacks are increasingly found by automated search rather than by people. Any fixed defense falls behind the moment the ecosystem shifts.
My answer is a self-evolving defense. Inside a sandbox, an automated red team keeps producing new multi-agent attacks, and the defense layer rewrites its own rules to block them. Self-evolving systems have an obvious failure mode, which is that they learn to cheat their own metrics, so the whole design rests on one rule: no claim is accepted because a model says so. An attack counts only when it reproduces in a fresh environment. A self-modification is kept only when execution shows it blocks that attack and does not break normal tasks.
I'm a second-year PhD student at MIT EECS. I'm raising one semester of support to keep working on this full time.
Two things running and public by January.
The sandbox comes first. Three to eight agents from different vendors, frontier API models mixed with open-weight ones (Llama, Qwen, DeepSeek), working on ordinary tasks such as software engineering and customer support, over real MCP and A2A implementations rather than mock-ups. Runs are recorded so they replay exactly. My test of whether the sandbox is any good is reproducing the multi-agent failures already in the literature: agents colluding, prompt injection spreading agent to agent, errors cascading down a delegation chain. Each reproduction becomes a replayable case, and those cases are the starting attack library.
Then the loop where both sides evolve. The red team proposes attack setups and gets credit for ones that are actually new and that survive a change of models, not for piling up hits on the same weakness. The defense watches messages and tool calls, and it can intervene by rate limiting, quarantining an agent, or escalating to a person. When something gets through, the defense proposes a change to itself, which is the self-evolving part, and that change has to earn its place: it must block the attack under execution, leave the existing library still blocked, and not slow down honest work beyond a stated budget.
This covers one semester of my PhD at MIT, at MIT's published 2026-27 rates. To stay enrolled full time I need tuition, fees, and health insurance paid. The stipend is what lets me spend the semester on this research instead of other work.
Tuition (Fall 2026 term): $33,360
Student life fee: $210 Health insurance (MIT SHIP, fall term): $2,145
Stipend: $22,090.50 ($4,909/month x 4.5 months, MIT EECS's published rate for externally funded PhD students; the fall appointment runs Sept 1 to Jan 15)
Total: $57,805.50
Just me, within my advisor's group at MIT. I'm a second-year EECS PhD student working on multi-agent safety.
I have built this kind of verification pipeline before, for single-agent harnesses: reproduce a failure in a clean environment, minimize it to a small trigger, confirm the cause by ablation.
Most likely failure: the red team never finds genuinely new attacks, only variations of known ones.
Second: the defense overfits, blocking everything in the library and nothing outside it. That's what the held-out attack set is for. And if self-evolving defense really can't keep up with automated attack, that answer is worth having too.
N/A