Without the proof layer
6/6
6 of 6 models broke through on at least one attack.
We cast six frontier AIs — Fable 5, Kimi, Opus 4.8 and more — as the attacker, reproduced the attacks enterprise systems actually face, and measured what broke and what held.
We cast the AI as the attacker, gave it nothing but a low-privilege account, and threw five attack scenarios at the system. The goal is to reproduce the attacks enterprise systems are really exposed to. We withhold the methods and show only what each one targeted.
From low privilege, go after confidential customer data.
Erase or rewrite the traces of what was done.
After intrusion, go after decrypting encrypted data.
Slip an illicit transfer past detection.
Break the approval flow by impersonation.
The bar shows the number of scenarios where the attack succeeded (objective achieved) — equivalent to attack success rate (ASR).
The more capable the model, the more sophisticated the attack and the deeper it reached. The strongest model broke 5/5, and the vulnerable paths weren’t one vendor’s — they were common across the entire frontier: a structural risk. Both “pick the high-performer and you’re safe” and “safety-tuned means safe” are betrayed by the data. And — the attacker, not the defender, chooses which AI to attack with. So defense cannot depend on which model it is.
Refusal is not safety. Safety training may curb accidental misuse, but it’s no guarantee.
No choice of model protects you.
What protects you is a layer that stops things before they execute.
The classic defenses most companies already run, AI agents slipped past on their own. For each scenario, we put the conventional defense next to how the AI broke it.
What to look for — Just scan the right column, “How the AI breaks it,” top to bottom: one classic defense after another falls.
Classic defenses are breakable by AI.
And for social engineering, the very concept of a defense doesn’t exist.
The difference wasn’t the model; it was the presence of a proof layer (SECURE mode). Before a high-risk operation it demands proof of who, with what authority, on which data — and if there’s none, it stops the action before it’s ever sent (fail-closed). That is Lemma’s role.
AI agents will attack your API.
Add a layer that demands proof before execution, and it stops.
Every breach happened because the AI escalated keys or credentials. Lemma adds one proof layer on the server: before a high-risk operation it requires, as proof, who, with what authority, on which data, and stops anything out of scope before it executes (fail-closed). Into your existing servers and APIs, with no major rewrite.
Approvals and payments have, traditionally, had no defense mechanism at all as a domain. For transfers and approvals, Lemma requires a mathematical proof of authorization and stops anything out of scope before it executes.
Layer a proof gate over the attacks, and the outcome changes like this:
The default view is “With Lemma” — every model and every scenario, blocked before execution. Flip the toggle to “No proof,” and the same table fills with breaches (red). The only difference is Lemma.
We run these attack scenarios against your own systems (a security assessment) and propose where, on the server side, to place the proof gate. Start with a 30-minute discovery call. No disclosure of sensitive data required.
Book a Discovery Call → See the plans →To learn more about Lemma, see the Whitepaper.
We review your target systems and requirements. No disclosure of sensitive data required.
We drop Lemma’s proof gate into a staging environment in a minimal configuration.
Measure the no-proof vs. proof difference under attack scenarios. See the effect in numbers.
Based on the results, we finalize the integration scope and the path to production.
This is measurement, not assertion. The code is public, and anyone can re-run it in the same environment.
403