​

Known Limitations

​

Evidence blob content

• Verdict rationale, classification and chain-of-thought are not yet in the blob. The v1 record carries the attack prompt, agent response, binary verdict, numeric jury score, and provenance (schema). 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. Until they ship, the rationale/classification/CoT remain in the platform’s private evaluation store rather than in the public blob.
• No per-blob TEE attestation receipt yet. Enclave integrity is currently enforced by the platform: the enclave runs a measured, pinned build (PCR values pinned in the frontend configuration) and publishes its signing key through the Sentinel contract’s EnclavePubkeySet/EnclavePubkeyUpdated events. The evidence blob itself does not yet embed a self-contained Nitro attestation document — that is the Milestone 2 teeAttestation field.

​

Anchoring

• Anchoring composes existing on-chain artifacts rather than a dedicated module. Each blob is anchored via the Walrus system Blob object, the recorded register/certify transaction digests, and the Sentinel contract’s PromptConsumed / AgentDefeated events. There is not yet a custom Move module emitting an explicit EvidenceAnchored { attack_id, blob_id } event; resolving attack → blob today goes through the platform indexer (surfaced in the explorer and profiles) or the attacker’s owned Blob object. The dedicated module is on the Milestone 2 roadmap.

​

Storage and retrieval

• Cold reads can be slow. A blob that has not been read recently may take tens of seconds to come back from the storage nodes via a public aggregator. The evidence explorer surfaces this as a “still retrieving — retry” state rather than a failure.
• Aggregators are third-party infrastructure. The public aggregator endpoints used for reads are operated by the Walrus ecosystem, not Red Sentinel. Anyone can run their own aggregator or use the Walrus SDK against the network directly; the blob id is the only permanent handle.
• Storage is epoch-limited. Records are reserved for 5 Walrus epochs. Walrus blob ids are content-derived, so re-registering identical bytes yields the same id if longer retention is ever needed.

​

Trust model

• Record content is server-authoritative at link time. The platform builds the canonical record and verifies the stored blob field-by-field before linking the blob id to an attack. A client cannot forge success/score in a linked record — but a fully trustless reader would still rely on the read-back guarantee plus on-chain verdict events rather than re-running the model inside the enclave. Per-blob attestation (Milestone 2) is what makes the blob self-evident.
• Prompts and responses are public by design. Evidence blobs are readable by anyone with the blob id (and are listed in the public explorer feed). Attackers should treat their prompts as published artifacts.