Proof: Receipts, Traces, and Security Properties
Short answer: SovereignClaw turns “trust us” into verifiable evidence - every permitted action emits a signed Authority Receipt in an append-only Merkle ledger, and every denied action leaves a trace. This page shows illustrative examples of that evidence.
Evidence is not a feature bolted onto SovereignClaw - it is a byproduct of how execution works. Because the runtime gates every action at the execution boundary, the only way for an operation to touch a system of record is through an adapter that has been handed a cryptographically bound gate artifact. That binding is what makes the resulting receipt meaningful: it ties a concrete outcome back to a specific intent, policy version, adapter identity, and approval state. The examples below are illustrative - they show the shape of the evidence, not captured production data.
Sample Authority Receipt
When an action is permitted, the runtime emits a signed Authority Receipt and anchors it in an append-only Merkle ledger (Security Property S8). The receipt records the intent (IR hash), the policy version that decided it, the decision and rationale, the risk tier, the approval state, the adapter identity, the tenant scope, a correlation ID, the execution outcome, a classical Ed25519 signature, a post-quantum SLH-DSA-SHA2-256f (FIPS 205) signature, and the Merkle root under which it is anchored. See how these flow into a AI agent audit trails and receipts.
Illustrative example: field values, hashes, and signatures are synthetic and shown to convey structure, not real captured data.
{
"receipt_id": "rcpt_01J9X4M2K7Q8ZB3N6V0F2A7C5D",
"ir_hash": "sha256:9f2c1a7e4b6d83f05c1e9a2d7b48fc36
e1d0a9b3c7f25e84a6d1b09c3f7e2a51",
"policy_version": "bundle-2026.06.01@v7",
"decision": "allow",
"rationale": "Tier T0 read on tenant-scoped record; policy match rule R-014.",
"risk_tier": "T0_OBSERVE",
"approval": "not_required",
"adapter_id": "adapter:records.read@2",
"tenant": "tenant:acme-health/prod",
"correlation_id": "corr_7a3f2c9e-1b04-4d8a-9f21-6c0e5b9a4d12",
"outcome": "completed",
"signature": "ed25519:3045022100c4f7...a91b02201d8e6f...0c2a (truncated)",
"pq_signature": "slh-dsa-sha2-256f:8c1e04...e27b (truncated)",
"merkle_root": "sha256:b71e0c4f8a2d96e3...5c1f0a9d (illustrative)"
}Denied-Execution Trace
A denial is not a blocked action that almost ran. When policy returns Deny or a required quorum is missing, the adapter is never reachable - there is no execution path to interrupt. The trace below shows a T3 sovereign operation (op DELETE, target INFRA, impact UNBOUNDED) that the kernel mechanically refuses because the default policy denies T3. Signatures cannot override a deny. The model can propose it; the runtime simply offers it nowhere to go.
Illustrative example - synthetic terminal output shown to convey the refusal path.
$ sovclaw execute "delete production database" [NEURAL] Rust provider intake... [IR] op: DELETE · target: INFRA · impact: UNBOUNDED [GATE] Canonicalized → SovereignIR frozen (SHA-256) [GATE] Tier: T3_SOVEREIGN [GATE] Facts recalculated: model-supplied facts overridden [GATE] Policy eval: decision = DENY (default policy, T3 refused) [GATE] Deny dominance: signatures cannot override a deny [GATE] MECHANICAL REFUSAL ✗ // Adapter unreachable. No execution path exists. // No Authority Receipt issued - only a denial trace. // The model complied. The kernel did not.
Sample Policy Decision
Policy evaluation is deterministic and produces one of four outcomes. The risk tier - T0 observe, T1 standard, T2 elevated, T3 sovereign - drives which outcome is reachable, and any Deny is final (Security Property S4, deny dominance). This is the core of AI agent policy enforcement.
Illustrative example - representative mapping of outcomes to tiers.
OUTCOME MEANING TYPICALLY TRIGGERED BY allow action runs; receipt emitted T0 observe / T1 standard escalate risk raised; re-evaluated at higher tier fact mismatch / elevated impact approval threshold quorum required (default 1/2) T2 elevated deny no execution path; final (S4) T3 sovereign / quorum unmet
The Nine Security Properties
SovereignClaw enforces nine formal security properties (S1–S9) across every execution path, covered by automated tests in a 33-crate Rust workspace. The October 7, 2026 release run passed 1,345 workspace tests with zero failures. Read the full nine formal security properties and the seven-stage execution path they govern.
- S1 - Adapter Reachability. No operation reaches the adapter without a valid gate artifact bound to IR hash, policy bundle, adapter identity, and nonce.
- S2 - Frozen Input. Inputs are canonicalized and byte-frozen before risk computation; identical intents produce identical hashes.
- S3 - Fact Recalculation. Tier-driving facts are recomputed from operation semantics; model-supplied facts are never trusted, and mismatches escalate risk.
- S4 - Deny Dominance. Any Deny is final. No component may downgrade a restrictive decision.
- S5 - Nonce Uniqueness. Every execution requires a unique nonce. Replays are rejected before any side effect.
- S6 - Adapter Binding. Artifacts are cryptographically bound to a specific adapter identity; a token for one adapter is invalid on any other.
- S7 - Multi-Party Approval. T2 requires verified threshold signatures from distinct operators (default quorum 1 of 2); insufficient quorum is a denial. T3 is refused by default policy.
- S8 - Tamper Evidence. Every permitted execution emits a signed Authority Receipt in an append-only hash chain with Merkle anchors, verified against operator-pinned public keys.
- S9 - Skill Publication Binding. Artifacts and receipts carry the published skill digest, tenant scope, and correlation IDs.
Test & Architecture Evidence
The properties above are not aspirational. They are backed by a Rust kernel and a test suite that exercises the gate, fact recalculation, the policy engine, and the receipt ledger.
- 1,345 workspace tests passed with zero failures in the October 7, 2026 release run.
- 33 Rust crates in the workspace.
- 9 formal security properties (S1–S9).
- No execution without a signed Gate artifact.
- Dual-signed receipts: Ed25519 plus SLH-DSA-SHA2-256f (FIPS 205).
- The DetGate execution-gating method is patent pending with the USPTO.
Independent Verification
An Authority Receipt is only useful if someone other than the issuer can check it. SovereignClaw receipts are designed to be externally verifiable without access to any private key. A third party, such as an auditor, a regulator, or a counterparty, can confirm a receipt by re-deriving and matching the evidence, for example with sovclaw receipt verify --keyring:
- Re-derive the SHA-256 IR hash from the canonical SovereignIR (RFC 8785 canonical JSON) and confirm it matches the "ir_hash" field.
- Verify both the Ed25519 and the SLH-DSA-SHA2-256f signatures against operator-pinned public keys. Keys embedded in a receipt are never trusted, and verification fails closed if either signature is missing or downgraded.
- Confirm Merkle inclusion of the receipt leaf under the published Merkle root.
Because policy bundles are versioned and cryptographically hashed, the receipt also pins exactly which policy decided the action. This is the basis of the research record behind the platform.