Velaris GroupStrix
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
    FULLY VERIFIED
  2. 1
    REQUIRE_APPROVAL · billing.issue_refund
    HIGH-risk refund ($4,200) exceeds agent autonomy; human approval required
    FULLY VERIFIED
  3. 2
    ALLOW · billing.issue_refund
    approved by cfo@acme (separation of duties: human approver ≠ requesting agent)
    FULLY VERIFIED
  4. 3
    ALLOW · billing.issue_refund
    approved refund executed; signed evidence + MC-1 receipt minted for the tool call
    FULLY 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

FULLY 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": "0a7cd0bed8a07fda8e5c5ae72bc170b60780a7a0c0817373957b4f8e355d2b7d",
  "proofChainHash": "83fa230c1adec18962e74dd9e2612869a034545c9f4c8e73acfbbe5d76cade5d",
  "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
4060919ddb2d2c968547ed04c48e920d0debec0880e5fd694ee3eea84f6dec59

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
0a7cd0bed8a07fda8e5c5ae72bc170b60780a7a0c0817373957b4f8e355d2b7d
Proof-chain hash
83fa230c1adec18962e74dd9e2612869a034545c9f4c8e73acfbbe5d76cade5d
Signing key id
strix-demo-ephemeral-2026-06
Schema version
1
FULLY 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.
FULLY 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, or signature verification was not completed.

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.