STX-011 · DEMONSTRATION

Adversarial Proof Demo

An AI agent refund_bot_v3 attempts two governed actions. Watch what the kernel allows, what it stops, and — the part that matters — re-verify every proof yourself. These records are signed at page-load with an ephemeral demo key (not the production key) and checked by the same verifier the operator console uses.

1 · The decision chain

Every governed action — allowed or denied — leaves an append-only, hash-linked signed evidence record. Authority does not transfer: the refund is stopped until a human approves it.

  1. 0
    DENY · customer.delete_all
    capability customer.delete_all is not granted to this agent; CRITICAL actions require owner-level human authority
    VERIFIED
  2. 1
    REQUIRE_APPROVAL · billing.issue_refund
    HIGH-risk refund ($4,200) exceeds agent autonomy; human approval required
    VERIFIED
  3. 2
    ALLOW · billing.issue_refund
    approved by cfo@acme (separation of duties: human approver ≠ requesting agent)
    VERIFIED
  4. 3
    ALLOW · billing.issue_refund
    approved refund executed; signed evidence + MC-1 receipt minted for the tool call
    VERIFIED

2 · The executed action, in full

The approved refund executed and produced this signed evidence record. Below is exactly what an operator (or auditor) sees in the Proof Explorer — canonical payload, decision, execution outcome, hash/chain status, trust layers, and an offline re-verify command.

demo-ev-0004

billing.issue_refund

VERIFIED

Verification Timeline

  1. Created
    2026-05-20T12:00:00.000Z
  2. Evaluated
    approved refund executed; signed evidence + MC-1 receipt minted for the tool call
  3. Decision
    allow
  4. Executed
    2026-05-20T12:00:00.000Z
  5. Evidence Created
    2026-05-20T12:00:00.000Z
  6. Signed
    2026-05-20T12:00:00.000Z
  7. Verified
    VERIFIED

Trust Layers

LayerStatus
HashPASS
ChainPASS
SignaturePASS
VerificationPASS

Canonical Payload

{
  "schemaVersion": "1",
  "evidenceId": "demo-ev-0004",
  "evidenceHash": "4d5af14bcd8c51074d143f39a4d63fecb53f6659e71a002ae469e1990ebcb82c",
  "proofChainHash": "",
  "capabilityId": "billing.issue_refund",
  "action": "allow",
  "actorId": "refund_bot_v3",
  "actorRole": "agent",
  "createdAt": "2026-05-20T12:00:00.000Z",
  "signingKeyId": "strix-demo-ephemeral-2026-06",
  "environment": "production",
  "tenantId": "acme-fintech-demo",
  "regulatoryContext": {
    "complianceMode": "eu_ai_act",
    "euAiActArticle12": true,
    "euAiActArticle14": true,
    "euAiActArticle28": true
  }
}
Signing-envelope SHA-256
d9d65433485792fa7462c6039701e5579d94bcceac98f3a7a04849f7795e50f7

This is the hash of the canonical signing bytes, shown for transparency. The record's evidenceHash is a field inside the payload, authenticated by the Ed25519 signature that covers it — it is not the SHA-256 of the canonical, so the two are not a direct equality check.

Decision

Decision
allow
Policy reason
approved refund executed; signed evidence + MC-1 receipt minted for the tool call
Risk level
high
Decision id
—
Source
ai

Execution Outcome

Outcome
success
Occurred at
2026-05-20T12:00:00.000Z
Actor
refund_bot_v3
Actor role
agent
Actor type
agent
Environment
production

Hash / Chain Status

Evidence hash
4d5af14bcd8c51074d143f39a4d63fecb53f6659e71a002ae469e1990ebcb82c
Proof-chain hash
—
Signing key id
strix-demo-ephemeral-2026-06
Schema version
1
VERIFIED

Independent Verification

Re-verify this record yourself — offline, with the public verifier and no Strix tooling. The command fetches the signed record, reconstructs the canonical payload, and checks the Ed25519 signature against the published JWKS.

$ npx @strixgov/verifier@latest demo-ev-0004

3 · The proof is checkable — and lying is detectable

A proof you cannot fail is not a proof. The Proof Explorer never collapses distinct outcomes into one green check. Here are the four states it surfaces honestly.

VERIFIED
Signature valid, canonical payload intact.
VERIFIED
INVALID — tamper rejected
We altered one signed field after signing. The signature no longer matches.
INVALID· signature invalid
INVALID
Failing Step
Signature Verification
Reason
Signature does not match the canonical payload — the record was not produced by (or was altered after) the holder of the Strix signing key.

The signature does not match the canonical payload reconstructed from the stored fields. This means at least one signed field was altered after signing, or the signature itself was replaced. Field-level attribution (which field changed) is a planned follow-on once the verifier exposes a field diff; today the honest, provable statement is that the record no longer verifies against its signature.

LEGACY_UNSIGNED
Predates Signed Evidence v1 — no signature to validate. Never shown as VERIFIED.
LEGACY UNSIGNED
UNVERIFIABLE
Signed by a key this verifier does not hold — cannot verify is not the same as invalid.
UNVERIFIABLE· signing key unknown

4 · Verify it yourself

Run the same walkthrough locally, or re-check any record offline with the public verifier — no Strix tooling required.

$ solo demo adversarial
$ npx @strixgov/verifier@latest demo-ev-0004

Re-verify this record yourself — offline, with the public verifier and no Strix tooling. The command fetches the signed record, reconstructs the canonical payload, and checks the Ed25519 signature against the published JWKS.

$ npx @strixgov/verifier@latest demo-ev-0004

This is a demonstration with an ephemeral key. To browse real, tenant-scoped governance evidence, open the Proof Explorer.