Velaris GroupStrix
Menu
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 — see the verifier re-derive the demonstration result. 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

This modeled flow emits hash-linked signed demonstration records. Authority does not transfer within the scenario: the simulated 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 modeled refund reaches its simulated adapter and produces a demonstration record. Inspect its canonical payload, decision, modeled outcome, and hash, chain, and signature checks. This does not establish a live processor refund or an independently observed consequence.

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
Signature algorithm
—
Algorithm source
—
FULLY VERIFIED

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 · Check the boundary, then check a production record

The demo key is ephemeral and its records are not published under public evidence IDs. A command using demo-ev-0004 cannot retrieve this record from the production verifier or JWKS. The checks above are re-derived for this page-load demonstration.

To independently verify a separate, published production record, run the online command below. Its signature verifies the record against a published key; it does not alone establish every external consequence or alternate-route coverage.

$ npx @strixgov/verifier@latest 5686

For production evidence and its explicit claim limits, inspect the CFX-009 proof page. Tenant-scoped records remain in the authenticated Proof Explorer.