​

Evidence Pipeline Architecture

​

End-to-end flow

 Attacker (browser)
   │  1. submit attack prompt
   ▼
 Backend API ──────────────────────────────┐
   │  2. route prompt to Sentinel agent    │
   ▼                                       │
 TEE Verification Env. (AWS Nitro Enclave) │  canonical record
   │  Sentinel agent executes the prompt   │  bytes are built
   │  LLM jury scores the response         │  server-side and
   │  3. verdict: success / score          │  handed to the
   ▼                                       │  storer (never
 Backend API                               │  the reverse)
   │  4. persist attack doc + verdict      │
   ▼                                       ▼
 Walrus  ◄──────────── 5. encode → register → write → certify ────────
   │
   │  6. read-back verification (field-by-field)
   ▼
 On-chain anchoring: blob id + register/certify tx digests
 linked to the attack record (see Blob Anchoring)

​

Step by step

1. Attack submission. The attacker submits a prompt against a Sentinel. The attack fee is paid on-chain and the attempt is recorded by the Sentinel smart contract (PromptConsumed event).
2. Enclave execution. The prompt is routed to the Sentinel agent running inside the AWS Nitro Enclave verification environment. The Sentinel agent produces its response, and an LLM jury inside the same trusted path evaluates it, producing the verdict (success flag and a 0–1 evaluation score). Attack outcomes settle on Sui through Move smart contracts (AgentDefeated, fee transfers), so the verdict that later lands in the evidence blob is the same verdict that released or accumulated the bounty.
3. Canonical record construction. When the attack completes, the backend builds the canonical evidence record — the exact JSON bytes described in Evidence Blob Schema — from the persisted attack document. Record content is server-authoritative: the bytes are handed out for storage, but they are never accepted back from a client (see step 6).
4. Walrus storage. The record (2–10 KB of UTF-8 JSON) is written to Walrus and reserved for 5 storage epochs. Two storage modes are supported:
   • Backend-signed — a backend-operated storage wallet encodes the blob and pays the register
     • certify transactions directly via the Walrus SDK (@mysten/walrus).
   • User-signed (the default for live attacks) — the attacker’s own wallet owns the record: the browser fetches the canonical bytes, encodes the blob locally, signs and pays the registerBlob transaction, writes the encoded slivers to the Walrus storage nodes, collects confirmations into a certificate, and signs the certifyBlob transaction. The attacker keeps custody of the Walrus Blob object.
5. Read-back verification. Before a blob id is linked to an attack, the backend reads the blob back from the Walrus storage nodes and compares it field by field against the canonical record. A blob that does not match — wrong values or extra fields — is refused. A client can therefore never link an attack to content it forged.
6. Anchoring. Once verified, the blob id (plus the Sui transaction digests of the register and certify transactions) is linked to the attack record. See On-Chain Blob Anchoring.

​

Trust model

• What the TEE guarantees: the Sentinel agent response and jury verdict are produced inside the enclave’s trusted execution path — the platform itself cannot quietly rewrite an answer mid-attack.
• What Walrus guarantees: once certified, the record’s bytes are immutable and permanently retrievable by blob id for the reserved epochs.
• What the read-back verification guarantees: the blob linked to an attack is byte-identical to the canonical record the platform built from the TEE-produced verdict.
• What is not yet in the blob: the jury’s free-text rationale, the attack classification, the full chain-of-thought trace, and a TEE attestation receipt are Milestone 2 schema extensions — see Known Limitations.

​

Operational parameters