How an engagement runs
We agree scope before anyone starts reading code. Surfaces, then joins, then a retest. A report-shaped PDF does not come first.
The four steps
Step 1. Scope the surfaces and write the brief (threat model + invariants).
We read the code, the model pipeline, and the glue before we quote. What you get back is a written brief: principals, what each may do, which invariants must hold, and what is out. You sign it before review starts.
Step 2. Review each surface, then the joins between them.
Each bench works its surface against that document. Contracts and circuits on one side. Artifacts, tools, and loops on the other. Then the same people review the hops: model output to a signature, retrieval to a parameter, a heuristic to a constraint. Findings go to you as they confirm, not when the PDF is ready.
Step 3. Show exploit paths and the assumption that produced them.
A finding names the path we took, or the path that failed, and the belief that made it possible. If we could not get a path to land, we say so. You should be able to reproduce the work from the report alone.
Step 4. Retest fixes. Publish what the client clears.
You land the fixes. We retest them against the same brief and record fixed, partial, or open. Retest is in the engagement, not a second SKU. Publication is the default when you clear it. You can withhold. We will not invent a client to fill the archive.
What we produce
- A written brief before review begins: threat model, principals, invariants, and an explicit out-of-scope list.
- Findings with severity, an exploit path or the failed path, the assumption that produced them, and a recommended fix.
- A retest record for each finding you address: fixed, partially fixed, or open, with the evidence.
- A public report if you clear it, in the format the sample shows. If you do not, a private one in the same format.
- A written update every working day, and the people who found the bugs on the call that explains them.
In scope
On-chain code, circuits, clients, model artifacts, agent tools, the glue, and the assumptions that bind them. Both benches sign one scope document. If something can sign, spend, deploy, or change a constraint, it is a principal. Human, contract, or model.
Out of scope
We do not rubber-stamp simple token contracts. We do not issue governance opinions for chatbots. We do not sell a scanner login. We do not staff incident response, run bounty marketplaces, or attest to SOC 2 or ISO 27001.
Every report carries its own out-of-scope list. If a wallet exists and we did not review it, the report says so on the first page.
What an audit does not prove
An audit is not a proof of safety. It is a record of what a specific team attacked, under a specific brief, in a specific window, and what they found. Code you change after the retest is not covered. Assumptions the brief did not state are not covered. A clean report means we did not find a way in with the time and access we had. It does not mean none exists.
Counsel may quote this section. We would rather a board hear it from the method page than from an incident.
Comms during the review
You talk to the people doing the work. Findings are shared as they are confirmed, in a channel you control, with a written update every working day. Critical findings are raised the same day, before the report exists. We do not hide behind a ticket portal in v1.
We do not promise a one-week turnaround. A join review is paced by the number of hops, not by a launch date. If the timeline does not fit, we say so on the scoping call.
Continuous review
After a first engagement, the brief already exists. Continuous review is a retainer that keeps it current: delta reviews when the contract, the model, or the tool surface changes, office hours with the bench that knows your system, and retests on demand. It is a named program with people in it, not a monitoring appliance and not a scanner subscription.
After the report
Publication is default-when-cleared. You decide what ships publicly; we do not surprise you. Reports that go public land on the reports index with the domains they touched and a client line you approve, or the word Confidential.
If we missed a class of bug, we say so. In the report addendum, and on the style page when the rule is general enough to keep.
Request a scoping call
Surfaces, stack, and when you ship. We reply within two business days with a scoping call or a decline.