Security

Aegis's trust model, credential handling, and why enforcement can't be bypassed.

Aegis · v14 pre-deploy review

Independent AI security review

Before v14 went on-chain, we ran it through an adversarial cross-review — two independent Claude reviewers plus Codex, each told to assume the agent's signing key is fully attacker-controlled and to try to move funds outside policy. It ran in three rounds. Every issue it found is fixed and closed.

3
review rounds
3×
reviewers per round (Claude ×2 + Codex)
5
issues found — all closed
137
automated tests passing
ScopeThe reviewed contracts are source-verified on all four networks (Base, Base Sepolia, Sepolia, Arc). This is a rigorous pre-deploy engineering gate — it is not a substitute for a professional third-party security-firm audit, which is planned before mainnet real-value use.

How the review ran

Round 01Find
Independent reviewers swept the enforcement path — signature checks, calldata decoding, spend limits, the destination allowlist — hunting for any way to exceed policy. Surfaced C1, C2, C3 and H1.
Claude ×2 · Codex — adversarial
Round 02Re-review the fixes
The fixes were themselves put back under adversarial review. This round caught that the first C3 fix was still bypassable, and surfaced the low-severity F1. Fixes revised.
Claude ×2 · Codex — verify fixes
Round 03Confirm
A fresh pass over the revised fixes confirmed each finding closed with a concrete rationale, and a regression test was added to lock the C3 fix against future changes.
Claude · Codex — confirm closed

Findings — all closed

C1

Destination allowlist was fail-open

CriticalClosed

Swaps, native sends, LP mints and Permit2 pulls could route funds to any address — the recipient was never decoded, so “funds can only reach approved wallets” silently didn't hold for those paths.

FixRe-architected fail-closed: any value-out whose true destination can't be resolved is denied when a recipient allowlist is set.

C3

Batched approval could grant a standing allowance to an attacker

CriticalClosed

A “paired” approval inside a batch could hand a persistent token allowance to an attacker-chosen contract — drained later, or stockpiled across days to beat the daily cap.

FixRecord the approval at the moment it's granted and revoke it unconditionally after the batch — no re-derivation an attacker can influence. Locked with a regression test.

C2

Permit2 trades metered amount but not destination

HighClosed

Signature-pull (Permit2) trades capped how much could move but not where it went, so under a recipient allowlist funds could still reach an unlisted address.

FixFails closed under a non-empty recipient allowlist until the destination can be bound.

H1

Universal Router command mask under-metered spend

HighClosed

A too-narrow command mask (0x1f) folded high command IDs onto swap decoders, letting a crafted router call slip through recognized-but-unmetered.

FixCorrected the mask to 0x3f; any unmodeled command now fails closed.

F1

Legacy short-payload path defaulted open

LowClosed

A backward-compatibility decode path defaulted to “allow” for undersized payloads — not reachable by any live flow, but the wrong default for a security check.

FixHardened to fail closed, matching the rest of the enforcement path.

The part we're proudest of

The review caught the flaw in our own fix.

The first fix for C3 looked right and passed every test. In Round 2, an adversarial reviewer found that an attacker could still slip through it — by changing on-chain state between the moment the account approves and the moment it revokes (a time-of-check / time-of-use gap).

We rewrote the fix to remove the gap entirely and added a regression test that reproduces the exact attack. A single review pass would have shipped the first version. Reviewing the fix as adversarially as the original is what closed it.

What this is. An independent, adversarial AI cross-review (Claude + Codex) run as a mandatory gate before deploying v14. Findings, severities, exploit scenarios and fixes are recorded with file-and-line detail in the project's review log.

What this isn't. A professional third-party security-firm audit. AI cross-review catches a real and valuable class of issues — as the C3 story shows — but we treat a firm audit as a separate, planned step before any mainnet real-value (e.g. estate) use, and we won't describe the system as “audited” until then.