6,000 Attacks, Zero Credentials Extracted: Model Choice Is a Control Decision
Fernando Irarrazaval gave the internet an email-handling AI assistant and a public invitation: extract the credentials it was holding. More than 2,000 people tried. They sent over 6,000 adversarial emails, spent past 500 dollars of his API budget, and triggered enough fraud signals that Google suspended the email account the assistant was using. The credentials were never extracted. Not once.
The backend was Claude Opus 4.6.
Most writing about prompt injection, including several pieces we have published, treats injection as an open wound. Attackers craft a message, the agent obeys, data leaks. That framing is correct as a warning and incomplete as a description of the current state. This experiment is the rare data point that shows the defensive side holding under sustained, creative, crowd-sourced pressure. It deserves to be read carefully, because the obvious conclusion is the wrong one.
What the experiment actually measured
A practitioner built an agent, wired it to a real email account, loaded it with a secret, and let the public attack it for a period of time. The headline numbers are real: thousands of participants, thousands of injection attempts, zero successful extractions. Those are facts about one setup.
They are not facts about prompt injection in general. N here is attack volume, not a controlled trial. There was one model, one system prompt, one tool configuration, one secret. No control group ran the same 6,000 emails against a weaker model to measure the difference. The fraud-detection suspension from Google was an external variable that removed the email channel partway through, which helps the defender for reasons unrelated to the model. This is a notable red-team result from an independent practitioner, not a benchmark you can cite as “injection is solved.”
Read that way, the experiment still teaches something specific and useful.
The result that survives scrutiny
A frontier model, given a clear instruction to protect a secret, resisted thousands of attempts by motivated humans to talk it out of that secret. That is not nothing. It means the instruction-following and trust-hierarchy behavior trained into the model did real work. The same training-level intervention we described in The Agent Security Architecture Problem, where models learn to weight system instructions above injected external content, is visible here in the wild rather than in a lab.
The author is careful, and his caveats matter more than his headline. He states plainly that smaller or weaker models would likely be more vulnerable, and that giving an agent email access remains risky regardless of how well it defended itself. Both caveats point at the same conclusion, and it is not the celebratory one.
The lesson is about the model you chose
Run the counterfactual. Swap Opus 4.6 for a cheaper, smaller model and replay the same 6,000 emails. The author’s own judgment, and the broader evidence base, says the extraction count would no longer be zero. The architecture did not change. The system prompt did not change. The tools did not change. The only variable that moved is the model, and the security outcome moves with it.
That makes model selection a security control, sitting in the same category as authentication scope, rate limits, and action verification. Teams routinely treat model choice as a procurement decision driven by latency and price per token. The same model that costs more per request may also be the one that refuses to leak a credential under 6,000 attempts. When the cheaper model is the one that breaks, the savings were borrowed against an incident.
This reframes a debate that usually happens in finance, not security. The question “which model can we afford?” is the same question as “how much injection resistance are we buying?” Those are not separate budgets. A model downgrade is a control downgrade, and it should go through whatever review a control downgrade gets.
Why this does not mean you can relax
A strong model is a probabilistic defense, not a guarantee. Zero extractions across 6,000 attempts is a strong signal; it is not proof that attempt 6,001 fails. Frontier capability lowers the success rate of injection. It does not drive the rate to a verified zero, and it never removes the underlying risk that the agent had email access and a live secret at all.
The disciplined posture combines both layers. Pick the strongest model you can justify, because the data says it absorbs attacks that a weaker model would not. Then build as if it will eventually fail anyway, because at sufficient volume something will get through. As Roles Are Style, Not Structure argued, instructions shape behavior at the margins; they do not create hard boundaries. The model’s refusal is a margin. The architecture is the boundary.
Concretely, the controls that survive a model failure are the ones outside the model. Short-lived credentials so a leaked secret expires fast. Scoped tool access so the email integration cannot reset passwords or reach other systems. Action verification on a deterministic layer that does not ask the model whether an outbound message is safe. Anomaly detection that would have caught the traffic spike before Google did. The experiment got rescued partway through by an external fraud detector. Your production agent should not depend on someone else’s spam filter for containment.
The supply-chain angle holds
Prompt Injection as a Supply-Chain Weapon made the case that the dangerous injections are the ones you did not invite. This experiment was an invited attack: a known agent, a public bounty, an attacker pool that announced itself. The real exposure in most organizations is the email no one flagged, the document pulled into a RAG index, the tool output an agent trusts by default. A model that resists 6,000 hostile emails from people trying to win a challenge may behave differently against one carefully aimed payload buried in a legitimate-looking workflow. The crowd was loud. A real attacker is quiet.
So the encouraging result and the unsolved problem coexist. The model held against noise. The architecture still has to hold against the quiet, targeted attempt that no public challenge will ever simulate.
Do this now
Treat your model selection as a line item in your security review, not just your finance review. Before you downgrade a model to save on inference cost for any agent that touches credentials, email, or external systems, ask one question: have we measured what that downgrade does to injection resistance, or are we assuming the cheaper model is good enough? If you cannot answer with evidence, you are trading a control you never priced. Run your own scaled-down version of this red-team against the model you actually plan to ship, and make the result part of the deployment decision.
This analysis synthesizes What Happened After 2,000 People Tried to Hack My AI Assistant (Fernando Irarrazaval, independent, June 2026). It is a single-setup practitioner experiment, not a controlled benchmark, and we frame it as such.
Victorino Group helps enterprises treat model selection as a security control and build the containment that survives a model failure. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation