Sec3Proving Layer
AI models can review a program and suggest many plausible security issues. Each one is a hypothesis. Before your team can act on it, someone has to show it can happen on the real program, measure the damage, and confirm the flaw is really the cause. That work still falls on your senior engineers, and an AI-written exploit that passes its own test may prove nothing.
Sec3 Proving Layer automates that work. AI agents write the proof of concept from a plain-text hypothesis and the program’s source code; the hypothesis doesn’t need to come with an exploit. A sophisticated harness runs it on the real program, checks every step, and confirms the named flaw is the cause before returning a verdict you can act on.
The problem with AI proofs
A test can pass and still prove nothing. Here are four ways that happens:
The starting state was written in by hand and can't happen on the real program
Builds every starting state through the program's own instructions, from a fresh deployment. No hand-written account data stands in for state the program would create.
Dependencies such as the token program were mocked
Runs your compiled program alongside the real programs it calls, in a Solana runtime
The test checked the wrong value, or one that doesn't matter
Reads the impact from the actual post-attack state, and a separate review confirms it measures the impact the hypothesis describes.
The flaw was never shown to be the cause
Runs a cause check: the same PoC, unchanged, with only the named flaw neutralized. The impact must disappear while normal setup still succeeds.
Case study
The hypothesis. An audit of the Swig smart wallet (Accretion, July 2025) reported a Critical issue: a user with limited permissions could drain a token account. The audit described the attack in words and included no exploit code.
Building the starting states. The attack needs a wallet, a token account holding tokens, and a user whose spending limit is zero. None of it can be written in by hand. The wallet's address, permissions and internal records are created together by Swig's own setup instruction and must stay consistent with each other; a hand-written copy would not. The token account is moved and closed during the attack by the real Solana token program, which rejects anything that is not a genuine token account. So the starting state was built with six real transactions through Swig's own instructions and the real Solana token program.
The root cause. Swig lets a user run a batch of actions, then checks the token balance afterwards to enforce the spending limit. It read that balance without first confirming the account still belonged to the token program. An attacker could move the tokens out, close the account, recreate it under a program of their own, and fill it with fake data showing the original tokens. Swig read the fake balance and concluded nothing had been spent. The missing piece is one ownership check. Showing that the flaw is real took everything below.
The attack and the cause check
The attack ran on the audited code. For the cause check, only the missing ownership check was put back, for this test only, and the same attack ran again.
Case study · SwigEvidence review
Yes. All six setup transactions went through Swig's own instructions or the real token program. No account data was written by hand.
Yes. The compiled audited program ran alongside the real token program.
No. It was checked to do nothing except write the data it was given.
Yes. Both values were read from the accounts after the transaction, and a separate review confirmed they are the ones that matter for security.
Yes. The cause check used the same unchanged test. Putting the check back had to build, and all six setup transactions still had to go through, so it didn't simply break the wallet. The attack was then rejected at the restored check, and both readings stayed at their original values.
Verdict: Validated. The attacker needs a role on the wallet, a small program of their own, and the ability to sign for the account the attack closes and recreates. The full test package can be re-run by your team or your auditor.
