An AI Auditor Without Exploit Context Is a Security Guard Who's Never Seen a Break-In

TL;DR

• An AI auditor without exploit context is a security guard who has never seen a break-in. It can describe doors and locks but cannot tell you which ones look wrong.
• Generic LLMs operate on principle alone. Domain-tuned auditors load real exploits as calibration anchors and recognize known shapes in new code.
• The set of canonical exploits is small and well-known. DAO ($60M, 2016 reentrancy), Cream ($130M, 2021 re-entry), Curve ($62M, 2023 Vyper bug) are the reentrancy anchor set. Mango ($114M), Inverse ($15.6M), Bonq ($120M) are the oracle manipulation anchor set.
• Loading these into your AI's context is not retrieval-augmented marketing fluff. It is the difference between flagging "uses external call" and flagging "uses external call to a token that can re-enter, before state update, in a function that holds user funds."
• The cost is tokens. The payoff is precision. This is what separates Krait's 100 percent precision across 50 blind Code4rena contests from generic LLM scanners that produce 50 false positives per audit.

Why this matters

If you have used a generic AI auditor on real code, you know the failure mode. The agent reads a contract, writes a list of generic warnings ("centralization risk in admin functions", "potential reentrancy in withdraw"), and you spend an hour confirming that nothing it said was actually exploitable.

That is not because LLMs cannot reason about Solidity. They can. The problem is they have no sense of which patterns matter in production. They cannot distinguish between a contract that follows safe patterns and one that looks safe but is actually broken in the same way Cream Finance was broken.

Domain knowledge is not optional for security work. A human auditor learns it by reading post-mortems for years. An AI auditor needs the same input, in compressed form, in its prompt.

The mechanism

An LLM doing security review is essentially doing classification at the token level. Given a function, it asks: does this look like a vulnerability? Without prior examples, the model classifies on principle. It thinks "this function makes an external call before updating state, that pattern is theoretically risky."

The problem with reasoning from principle alone is that almost every Solidity function looks theoretically risky if you stretch the principles. External calls happen everywhere. State updates happen everywhere. Without a sense of which combinations actually got drained, the model produces noise.

Calibration anchors fix this. By loading the canonical exploits into the prompt as worked examples, the model now reasons by analogy:

• "This function reminds me of the DAO call. They both call user-supplied addresses before updating an internal balance."
• "This pricing path uses spot reserves directly. That is the exact shape of the Mango attack."
• "This loop accumulates state without bounds. Sherlock-style auditors would flag this because it is similar to several documented gas-griefing patterns."

The model has not memorized vulnerability patterns in some abstract sense. It is performing analogical reasoning between the code in front of it and the exploits it has been shown. Analogy is much more reliable than principle when the input space is messy.

The reentrancy anchor set

For reentrancy, three exploits cover most of the surface area. Loading their post-mortems and code snippets into the AI's context is what teaches it to recognize re-entry in production code.

The DAO ($60M, 2016). The original. A call.value() to a user-controlled contract before the internal balance was decremented. The user contract called back into the DAO and drained more ETH than it had a right to. Every modern reentrancy detection pattern descends from understanding this attack.

Cream Finance ($130M, October 2021). A more sophisticated variant. The attacker manipulated the price oracle via a flash loan, then exploited a re-entry in a yield strategy that did not protect against cross-function reentrancy. The interesting feature: Cream had reentrancy guards on individual functions, but the attack crossed function boundaries within the same transaction.

Curve Finance ($62M, July 2023). Not a Solidity bug. A Vyper compiler issue where reentrancy guards in versions 0.2.15 through 0.3.0 silently failed to enforce. Multiple stable pools were drained simultaneously. The lesson: reentrancy is not just about what you write, it is about whether the compiler does what you think.

An AI auditor with these three in context can recognize:

• The textbook pattern (state update after external call)
• Cross-function reentrancy that single-function guards miss
• Tooling-level assumptions that need verification

Without them, the AI flags every external call as reentrancy-suspicious. With them, it flags the right ones and ignores the rest.

The oracle manipulation anchor set

Oracle attacks have a similar three-exploit canonical set.

Mango Markets ($114M, October 2022). An attacker pumped the spot price of MNGO using their own capital, used the inflated price to borrow against the position, then walked away with the loans. The vulnerability was using a single spot price as an oracle without any time-weighted protection or sanity bound.

Inverse Finance ($15.6M, 2022). A flash-loan-driven oracle manipulation against the yvCrv3Crypto LP token price. Inverse used spot prices from the underlying Curve pool, which were trivially manipulable when the attacker controlled enough capital for one block.

Bonq Protocol ($120M, February 2023). The attacker manipulated the Tellor oracle that Bonq used as a price feed by submitting a malicious value. The vulnerability was trusting a single oracle source without secondary validation or cross-checks.

The pattern across these three: protocols treated their price oracle as an authoritative source of truth instead of a manipulable input. An AI auditor that has read these three knows what spot-price-as-oracle smells like in new code.

What loading these looks like in practice

You do not paste the entire post-mortems into your prompt. You distill each exploit into a structured artifact the model can use as a reference:

- exploit: Cream Finance
  loss_usd: 130000000
  date: 2021-10-27
  primitive: cross-function reentrancy
  trigger: oracle manipulation via flash loan
  pattern: |
    Reentrancy guards on individual functions failed to protect against
    a cross-function callback. Attacker entered through function A,
    callback re-entered through function B, internal state was inconsistent
    between the two paths.
  smell_in_new_code: |
    Multiple state-mutating functions without a contract-wide nonReentrant
    modifier or shared lock. Especially when one path makes external calls
    and another updates the same storage slot.
  detection_check: |
    Find all storage variables touched by both function A and function B.
    Trace whether function A makes external calls before all writes are
    complete. If yes, can function B be called from within that external
    call's reentry?

Now your AI auditor, when scanning a new lending protocol, can use this template to check whether the new code has Cream-shaped weaknesses. It is not pattern matching on the word "reentrancy"; it is pattern matching on the structural shape of the original attack.

This is the technique that domain-tuned auditors use. Krait, the open-source AI auditor we maintain, achieves 100 percent precision across 50 blind Code4rena contests in part because every detection module is built on top of an exploit anchor like this. When Krait flags a finding, the model can point to which historical exploit the new code resembles. That makes the finding actionable instead of speculative.

Why generic LLMs cannot do this on their own

You might ask: are not large modern models trained on enough security content that they already know about Cream, Mango, and the rest? Yes and no.

The training data includes some post-mortems. But it also includes thousands of generic security articles, hundreds of CTF writeups, and a stew of half-correct community advice. When you prompt a generic LLM to audit code, it draws from this entire mixture. It cannot tell which sources are authoritative production references and which are theoretical CTF puzzles.

The result is reasoning that mixes up severity and applicability. The model says "this could be reentrancy" because it has seen the word in the wrong contexts. It does not weight DAO and Cream as canonical the way an experienced auditor does.

Loading the canonical exploits explicitly in the prompt re-weights the analysis. The model now treats Cream as a primary reference, not as one citation among thousands. The signal-to-noise ratio in its findings goes up dramatically.

Related questions

How many exploits should I load into my AI auditor? Enough to cover the bug class, not enough to blow your context window. For each major class (reentrancy, oracle manipulation, flash loan attacks, share inflation, governance hijack), four to six canonical exploits is usually sufficient. Past that, you get diminishing returns and start eating tokens that should be carrying actual contract code.

Which exploits should I prioritize for a DEX audit? Curve (compiler bug), Uniswap V2 share inflation patterns (first depositor attacks), and any documented sandwich-attack post-mortems. For a lending protocol, swap in Mango, Inverse, and Cream. For a stablecoin, add Iron Finance and the various Terra-adjacent depegs.

What format works best for the exploit anchors? Structured YAML or JSON works well because the model can pattern-match on field names. Free-form prose works too but is less reliable for retrieval. Avoid raw post-mortem dumps; they bloat the context and dilute the signal.

Does this approach generalize beyond Solidity? Yes. The same technique applies to Move, Cairo, Rust contracts, and any language where exploits are public and well-documented. The canonical anchor sets differ but the pattern of "load real attacks as analogical reference" is the same.

Where to see this in practice

The AI Auditor Builder pillar of Zealynx Academy walks through this exact methodology in step 6, where you build the exploit-context layer of your custom AI auditor. You start with raw exploit data, distill it into the structured anchor format above, and integrate it into your detection prompts. The result is an auditor that reasons by analogy to real production attacks rather than by abstract principle.

If you want to skip the building exercise and just use a pre-built auditor that already has these anchors loaded, Krait is open source and shipped with the canonical exploit sets baked in. The implementation is on GitHub and the design choices are documented in the AI Auditor Builder module on Academy.

The shorter version of this entire post: an AI auditor that does not know about Cream Finance is going to miss the next Cream Finance. Load the exploits.