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, an Ed25519 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 are synthetic and shown to convey structure, not real captured data.

{
  "receipt_id": "rcpt_01J9X4M2K7Q8ZB3N6V0F2A7C5D",
  "ir_hash": "sha3-256:9f2c1a7e4b6d83f05c1e9a2d7b48fc36
             e1d0a9b3c7f25e84a6d1b09c3f7e2a51",
  "policy_version": "bundle-2026.06.01@v7",
  "decision": "allow",
  "rationale": "Tier T1 read on tenant-scoped record; policy match rule R-014.",
  "risk_tier": "T1_STANDARD",
  "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)",
  "merkle_root": "sha3-256:b71e0c4f8a2d96e3...5c1f0a9d (leaf #418,902)"
}

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 zero of the required two-of-three threshold signatures are present. 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 (SHA3-256)
[GATE]    Tier: T3_SOVEREIGN
[GATE]    Independent fact inferencer: LLM facts overridden
[GATE]    Policy eval: decision = DENY (monotonic, final)
[GATE]    Threshold signatures required: 2-of-3
[GATE]    Signatures present: 0
[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, monotonic policy). 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   human or threshold quorum required       T2 elevated
deny       no execution path; final (monotonic)     T3 sovereign / quorum unmet

The Nine Security Properties

SovereignClaw enforces nine formal security properties (S1–S9) across every execution path. They are verified across 20 Rust crates with 829+ tests. Read the full nine formal security properties and the seven-stage execution path they govern.

S1 — Execution Boundary. 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 — Independent Fact Verification. Tier-driving facts are derived from operation semantics, never from the model; mismatches escalate risk.
S4 — Monotonic Policy. Any Deny is final. No component may downgrade a restrictive decision.
S5 — Nonce Uniqueness. Every execution requires a unique nonce; replay and TOCTOU races 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 — Threshold Authorization. T2 and T3 require threshold signatures from verified operators; insufficient quorum is a denial.
S8 — Receipt Verifiability. Every permitted execution emits a signed Authority Receipt in an append-only Merkle ledger, externally verifiable.
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, the inferencer, the policy engine, and the receipt ledger.

829+ tests passing across the kernel.
20 Rust crates in the production architecture.
9 formal security properties (S1–S9).
0 unsigned executions structurally possible.
4 patent applications pending (ExecLayer v4 Protocol).

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 — an auditor, a regulator, or a counterparty — can confirm a receipt by re-deriving and matching the evidence:

Re-derive the SHA3-256 IR hash from the canonical SovereignIR and confirm it matches the "ir_hash" field.
Verify the Ed25519 signature against the issuer’s published public key.
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.

References

Request Early Access

Frequently Asked Questions

Are the receipts and traces on this page real captured data?

No. Every sample on this page is an illustrative example with synthetic values, shown to convey the structure of the evidence. It is not a fabricated record of a real execution.

How can an Authority Receipt be verified without private keys?

A third party re-derives the SHA3-256 IR hash from the canonical SovereignIR, verifies the Ed25519 signature against the published public key, and confirms Merkle inclusion under the published root. None of these steps require a private key.

What happens to a denied action — is it logged as a receipt?

A denied action receives no execution path; the adapter is unreachable, so no Authority Receipt is issued. The denial leaves a trace instead. As the kernel puts it: the model complied, the kernel did not.

How thoroughly is the evidence path tested?

SovereignClaw enforces nine formal security properties (S1 through S9) verified across 20 Rust crates with 829+ tests, with zero unsigned executions structurally possible and four patent applications pending.