Cerberus — SAFR pre-execution governance runtime for AI-agent payments

1. What this page is / is not

• It is a static, read-only evidence page. It was built from the repository's committed evidence package (artifacts/judge-evidence/) and the submission documents (docs/submission/EVIDENCE.md, docs/submission/FINAL_FREEZE.md). The recordings, screenshots, the SHA-256 manifest and the evidence summary served here are byte-for-byte copies of the files in the repository.
• It is not the runtime. Cerberus runs on the operator's machine by design: its trusted services (control plane and isolated executor) bind 127.0.0.1 and are loopback-scoped, and no public-internet deployment is claimed.
• Nothing here is live or interactive. No button on this page proposes, approves, settles or anchors anything. The only outbound links are to GitHub and to the public Base Sepolia block explorer.
• No keys or secrets are involved. This site contains no wallet, signer, token, credential or environment file. The evidence package lists credential variable names and lengths only, never values.

2. The hardened-path run — 22 August 2026, Base Sepolia

Captured on the finalist build with the payment signer, the execution-authorization signer and the audit-anchor signer held by three separate processes with three separate least-privilege database logins. The agent process holds none of them. The seeded mandate allows at most 1 USDC per transaction and 3 USDC per rolling 24 hours.

The four scenarios

Identities

Why the ambiguous outcome is the strongest evidence, not the weakest

A merchant's HTTP response is not financial truth. When the response to a signed execution never resolved, Cerberus did not treat “the merchant said it failed” as proof that money did not move — it kept the mandate capacity held and refused to retry. The keyless reconciler (it holds no private key) deferred 17 times rather than guess.

The proof of non-payment is read from the chain, not from the merchant. Calling USDC.authorizationState(payer, nonce) for the reservation's own EIP-3009 authorization returns false, and that authorization's validBefore has elapsed. The money did not move, and cannot move under that authorization. That is positive non-payment evidence.

Reservation

res_bcaf9720-4b9a-4710-946c-cb9d00d04a36

Payer

0x35820e5cC60F961515EF987C94D4328a82Df38Fc

EIP-3009 nonce

0x8dbcbebfc0c876c91a6b64f0e716f5b52f09257901583d7692b38d06dc9739dc

validBefore

1787359784 = 2026-08-22T00:49:44Z (elapsed)

authorizationState

0x00…00 → false; never consumed on chain

Terminal state

FAILED, settlement_tx NULL, reconciliation attempts 17, “EIP-3009 authorization expired unused; safe to retry”

3. Recordings & screenshots

Seven screen recordings (WebM) and five screenshots, copied unchanged from artifacts/judge-evidence/11_videos/ and 10_screenshots/. Videos do not preload; tap to play. If your browser cannot play WebM inline, use the “open file” link under each recording.

Screen recordings — phases 0 to 7

Screenshots

4. How it works

1. The agent proposes. The AI agent's orchestrator produces a structured proposed payment. The agent process holds no payment key, no authorization signer and no anchor signer (Phase 2 of the run checks this).
2. A deterministic disposition engine evaluates it against a versioned mandate — spend caps, counterparty allowlist, time windows, velocity — as a pure, rule-based library call inside the orchestrator, before any x402 request object exists. No LLM is in the decision path.
3. The result is ALLOW, DENY or ESCALATE. DENY means the x402 client is never constructed. ESCALATE holds the action until a human reviewer approves or denies it from a separate process; the agent cannot approve itself.
4. An isolated executor acts only on a one-use, 60-second signed authorization. The executor is the only process that holds the payment key. It accepts a short-lived, single-use Execution Authorization bound to the exact proposal, mandate version, chain, token, atomic amount, payee and resource, and consumes it one-shot.
5. Settlement is proven by reading the chain; audit records are hash-anchored by a separate trusted worker. A payment is marked SETTLED only on exact successful on-chain inclusion of the USDC transfer — never on the merchant's HTTP response — and a keyless reconciler handles ambiguous outcomes. Terminal audit records are canonically hashed and anchored to Base Sepolia by a separate anchor worker, which makes them tamper-evident.

5. Verified gates

Figures from docs/submission/FINAL_FREEZE.md and the README “Current finalist build” table. CI reproduced the gate independently on a clean Linux runner with no wallet secrets.

6. Integrity

The evidence package is covered by a SHA-256 manifest. Both integrity files are served here as exact copies of the repository files:

• SHA256SUMS.txt — the manifest for artifacts/judge-evidence/ (every file except itself and the volatile 03_services/dashboard.log, which the dashboard service was still appending to at packaging time).
• evidence-summary.json — the machine-readable summary of the run set (generated 2026-08-22T01:49:00Z; status: PASS; critical_missing: []).

Verify the package has not changed since capture, from a clone of the repository:

cd artifacts/judge-evidence && sha256sum -c 08_final/SHA256SUMS.txt

The recordings and screenshots served by this site are the files named in that manifest; their listed digests are reproduced here so a file downloaded from this page can be checked against the repository.

The architecture slide in section 4 is the README illustration, not part of the evidence package, and is therefore not in the manifest. This HTML page is a presentation layer and is not in the manifest either; the repository is the source of truth.

7. Limitations, stated plainly

• Inclusion, not finality. Settlement proof requires an exact successful on-chain transfer; it does not wait for a confirmation or finality threshold. A production deployment would wait for a configurable confirmation/finality depth before treating accounting state as irreversible. The audit verifier reports confirmation depth; the settlement path deliberately does not gate on it.
• Loopback-scoped services. The trusted services (control plane and executor) bind 127.0.0.1 by default behind bearer credentials and an allowlisted browser CORS policy. There is no mTLS, JWT or workload identity for service-to-service calls, and no public-internet deployment is claimed. A wider deployment would still need TLS, credential rotation, rate limiting, monitoring and perimeter controls.
• Same-host compromise. Process isolation is by operating-system boundary and database role. An attacker with root on the host defeats it, as they would defeat any single-machine deployment. This is stated, not defended against.
• Testnet prototype; one supervised run set. Base Sepolia, hackathon scope, not a production payment system. The hardened-path evidence is a supervised run set captured once, on one machine. It is real and independently checkable on chain; it is not an uptime or scale claim.
• One reviewer identity; no rate limit on escalations. One configured reviewer identity represents all human decisions, and the reviewer boundary has no rate limit, lockout, CSRF/origin check, session expiry or MFA. Dashboard Basic auth is a prototype operator boundary, not institutional SSO/MFA.
• Tamper-evident, not immutable. Audit records are tamper-evident through on-chain anchoring of their digests; they are not immutable. Anchoring requires the anchor worker to be running — if it is not, digests are still stored durably in Postgres and records report as pending, never as anchored.
• Stage-1 history is kept separately and labelled. Earlier Base Sepolia transactions from Stage 1 remain in the repository as history. They predate signer isolation, chain-proven settlement and the trusted audit finalizer, and none of them is presented on this page as hardened evidence.
• Deterministic fixtures in judged runs. Judged runs use the deterministic fixture planner rather than the LLM path so results are reproducible; the LLM path exists and is schema-validated identically, but it is not in the decision path either way.
• Not claimed, and must never be: “no bugs”, “completely secure” or “production-safe for real money”; MAS approved, MAS certified or SAFR compliant in any official or certification sense; irreversible blockchain finality.

8. Links

• GitHub repository — github.com/Harshyadav442277/Cerberus
• Evidence manifest — docs/submission/EVIDENCE.md
• Final freeze, gate results and release identity — docs/submission/FINAL_FREEZE.md
• Hosted Judge Console (finals presentation surface, Basic-auth gated; fixed scenarios, read-only chain checks, captured fallback) — cerberus-judge-console.vercel.app/judge · design and operator checklist in docs/submission/JUDGE_CONSOLE.md
• Evidence package — artifacts/judge-evidence/
• README, “Current finalist build” — README.md
• CI run on the release payload — actions/runs/32301340842
• Block explorer — AuditAnchor contract · executor (payer) · merchant payTo on base-sepolia.blockscout.com