Compliance
Architecture

Zero-egress means that no data submitted to the Sentinel audit engine ever leaves the computational boundary of your Cloudflare Worker. Model manifests, training metadata, inference parameters — all are processed in-process and immediately discarded after verdict generation.

Sentinel's WASM module is loaded directly into the Worker V8 isolate. Input data is passed via in-memory pointer (not serialized over a socket). The module executes, writes the verdict hash to D1, and the raw input is garbage-collected within the same event-loop tick.

GDPR Article 46 transfer restrictions, the EU AI Act's downstream provider obligations, and sector-specific data localization requirements (DORA, MDR) all require proof that sensitive AI inputs do not cross data-processing boundaries. Sentinel's architecture makes this certifiable by design — not just by policy.

Cloudflare publishes network egress logs per Worker endpoint. Sentinel generates zero outbound bytes on the audit path. You can validate this in your Cloudflare Dashboard > Workers > Sentinel > Analytics > Egress.

A deterministic audit engine produces the exact same verdict for the exact same input — always. This is mathematically guaranteed by the Rust-to-WASM compilation model: there are no stochastic operations, no probabilistic classifiers, and no runtime model weights that could shift between calls.

LLM-based compliance tools use transformer inference, which is inherently probabilistic. The same prompt submitted twice may produce different verdicts. This makes them inadmissible for legal evidence because opposing counsel can trivially demonstrate inconsistency. Sentinel's output is reproducible by any third party with access to the same WASM binary and input.

Each compliance check runs against a pinned version of Sentinel's EU AI Act rule tree. The version number is embedded in every D1 audit record. If the EU passes an Amendment, we release a new WASM minor version — and all prior audit records remain verifiable against the rule set that was in effect at the time of audit.

The WASM binary itself has a SHA-256 content hash that is published to our transparency log. Any modification to the audit logic changes the binary hash, making tampering trivially detectable. Enterprise customers receive a signed attestation document containing this hash for their compliance registers.

Cloudflare D1 is a serverless SQLite database with read replication at the edge. Sentinel writes audit records to the primary D1 instance using a synchronous, sequential write path. Each write is confirmed before the API response is returned, ensuring that no audit record is ever 'lost in transit'.

Sentinel's D1 schema has no UPDATE or DELETE operations on the audit_logs table. All insertions are INSERT-only. The Worker's D1 binding is configured with execute privileges only — no DDL or destructive DML statements are possible from application code. This is enforced at the binding level, not just application policy.

All `created_at` timestamps are generated by D1's server clock at write time (DEFAULT CURRENT_TIMESTAMP). Application code cannot inject or override timestamps. This means the temporal evidence chain is controlled entirely by Cloudflare's infrastructure-level clock, which is synchronized to GPS-calibrated NTP and auditable by Cloudflare's own infrastructure logs.

D1 provides point-in-time recovery (PITR) at the Cloudflare infrastructure level with 30-day retention. Enterprise customers on the Scale-Up plan receive access to Sentinel's own D1 export endpoint, allowing them to maintain a secondary backup of all audit records in their own S3-compatible storage.