The Sentinel
Architecture

A zero-trust execution layer that sits between your AI agents and the data they process. Every access monitored. Every byte accounted for. Every destruction proven.

Core Components

Gateway

Sentinel Gateway

The single entry point for all data access. Built in Rust for zero-overhead interception. Handles TLS termination, policy lookup, and request routing in under 2ms.

Engine

Policy Engine

Real-time evaluation of sovereignty constraints. Policies are expressed as declarative rules — jurisdiction, retention period, access scope, destruction trigger. No ambiguity.

Destruction

Erasure Module

Cryptographic erasure via key destruction. The data isn't deleted — it becomes mathematically irretrievable. Multi-pass verification confirms no residual state.

Proof

DDC Issuer

Generates Destruction Certificates with ZK-SNARK proofs. Anchors to Bitcoin and Ethereum for immutable, publicly verifiable timestamps. No trusted third party.

Ledger

Internal Chain

Append-only ledger of all operations. Each block contains Merkle roots of DDCs, policy evaluations, and access logs. Tamper-evident by construction.

SDK

Agent SDK

Drop-in integration for any AI framework. Python, REST, Unix Domain Socket. Your agent code doesn't change — Sentinel wraps the execution boundary transparently.

Execution Flow

1. Request Ingress

Agent sends a data access request to the Sentinel Gateway. The request includes a policy reference and the target data identifier. TLS mutual authentication ensures both parties are verified.

2. Policy Evaluation

The Policy Engine evaluates the request against the declared sovereignty constraints. Jurisdiction checks, retention limits, access scope validation — all in under 1ms. Non-compliant requests are rejected with a cryptographic denial receipt.

3. Sovereign Execution

Data is decrypted into the execution boundary. The agent processes it under continuous monitoring. Memory access patterns are tracked. No data can escape the boundary without explicit policy approval.

4. Cryptographic Destruction

Upon completion, all encryption keys for the processed data are destroyed. The Erasure Module verifies via ZK-proof that no copy of the key material exists in any accessible state — memory, disk, cache, or swap.

5. DDC Issuance & Anchoring

A Destruction Certificate is generated containing the data hash, destruction timestamp, ZK-proof, and policy reference. The certificate is written to the internal ledger and anchored to Bitcoin/Ethereum within the next block cycle.

Integration Example

# Install the Ardyn SDK
pip install ardyn-sentinel

# Wrap your agent's execution
from ardyn import Sentinel

sentinel = Sentinel(api_key="sk_live_...")

# Define sovereignty policy
policy = sentinel.policy(
  jurisdiction="eu",
  retention="0s", # destroy immediately after processing
  compliance=["gdpr", "hipaa"]
)

# Execute with sovereign guarantees
with sentinel.session(policy) as session:
  result = my_agent.process(session.data)
  # Data destroyed here. DDC issued automatically.

# Verify destruction
ddc = session.ddc
print(f"Destroyed: {ddc.hash[:16]}... Proof: {ddc.zk_proof}")

Security Properties

Zero Knowledge

Destruction proofs reveal nothing about the original data. Verifiers can confirm destruction without ever seeing what was destroyed.

Tamper Evidence

Any modification to the ledger invalidates all subsequent Merkle proofs. Tampering is not just detectable — it's mathematically provable.

Forward Secrecy

Each session uses ephemeral keys. Compromising future keys cannot decrypt past sessions. Past destruction remains provably valid.

Byzantine Fault Tolerance

The system produces valid proofs even if components fail. No single point of failure can prevent destruction or proof generation.