Skip to main content

How It Works

This page walks through the analysis pipeline end to end. For positioning, benchmarks, and what to expect in the report, read What is AuditAgent.

What the agent receives​

Before each scan you select two things.

The codebase. A repository, a branch, and the contract files you want analyzed. See Which ecosystems we support for the supported languages. Up to 100 contracts and 20,000 BLoC per scan.

Documentation. READMEs from the repo, public URLs, PDF/MD/MDX uploads, and free-form notes. The agent reads all of it and folds it into its working context.

The richer the context, the better the output. Documentation is how the agent disambiguates intent. A function called transfer could be ERC-20, ERC-721, or a custom escrow withdrawal. Tell the agent which one it is and you get fewer false positives.

What runs during a scan​

Multiple large language models analyze your contracts in coordination.

Full-Depth Scan. Up to 5 hours of deep analysis on frontier models from multiple providers. The pipeline includes three complementary components.

  • Multi-agent analysis. Specialised agents working in coordination.
  • Adversarial pass. Re-reads your code as an attacker.
  • Live research. Known exploits and protocol patterns, looked up during the scan.

These components help investigate harder findings. See Difficulty Benchmark for detection results.

Persistent Memory in the pipeline​

If you have initialised Persistent Memory for a project, every scan after that runs against the accumulated context: architecture, invariants, hypotheses, and contradictions from prior scans. Subsequent scans propose updates to the memory, which you review before they persist. Without memory, every scan starts from a blank slate.

What the agent does not see​

  • Files outside your selected scope are not considered by the agent in full depth. Unselected code is still used to some capacity as context for our analysis, but the agent specifically focuses on your selected contracts and has less context on the rest.
  • Production state, balances, or on-chain context, unless you describe it in documentation.
  • External dependencies that we cannot install during the scan.

This matters when you are triaging false positives. If a finding looks wrong, the first question to ask is whether the agent actually understood what the function does in your protocol. If it did not, add better documentation and rescan.

What you get back​

The scan produces findings, a code summary and architecture diagram, generated invariants, a 0 to 100 security score set by the most severe open finding, and an email with the security report PDF attached. See What you get back for the full breakdown.