Verification

Verify any decision.
Without trusting TrigGuard.

Every authorization decision produces a signed receipt. Auditors, regulators, customers, and operators can independently verify what happened, when it happened, and under which policy.

No dashboard required
No privileged access required
No trust required

{
  "decision": "DENY",
  "policyFingerprint": "payments.production",
  "reason": "SPEND_LIMIT",
  "timestamp": "2026-04-21T16:00:00.000Z",
  "receiptSignature": "…"
}

Valid
Signed
Unmodified

Why it matters

Proof you can verify anywhere

Receipts are self-contained evidence of policy outcomes. Verification runs locally in your infrastructure - during audits, incident review, or compliance workflows - without calling TrigGuard.

Auditors

Validate decisions with cryptographic proof, not screenshots.
Regulators

Confirm what policy was applied and when it was enforced.
Operators

Investigate incidents offline with receipts you already have.

Receipt Explorer

Try it in your browser

Paste a receipt, load an example, and verify the signature instantly. Same canonical logic as the CLI - no server-side verification API.

Open Receipt Explorer

How verification works

Four steps to independent proof

You hold the receipt. TrigGuard publishes the signing key. Your runtime checks the signature. The result is proof anyone can reproduce.

Receipt

Signed decision record

Public key

Published authority key

Verify signature

Local cryptographic check

Independent proof

Valid, signed, unmodified

Implementation

Protocol steps

For developers integrating verification into CI, runtime, or audit tooling.

01

Fetch keys

Load public keys from /.well-known/trigguard-keys.json and cache locally. Network access is only needed for key discovery.
02

Build canonical payload

Extract signed fields (decision, policyFingerprint, reason, timestamp) and serialize as UTF-8 JSON with lexicographically sorted keys.
03

Verify signature

Verify those UTF-8 bytes against receiptSignature using the authority public key - via WebCrypto, CLI, or SDK.
04

Check expiry

Confirm the receipt has not expired when expires_at is present.

Key discovery

Published signing keys

TrigGuard publishes signing keys at a well-known URL. Keys rotate quarterly; deprecated keys remain available for 90 days to verify historical receipts.

GET https://www.trigguardai.com/.well-known/trigguard-keys.json

Reference

Implementation reference

Import the SPKI public key, build the canonical UTF-8 payload, then call subtle.verify with Ed25519. The Receipt Explorer implements this path for copy-paste receipts.

// Pseudocode: import SPKI, verify Ed25519 over canonicalUtf8Bytes
await crypto.subtle.verify(
  { name: "Ed25519" },
  publicKey,
  signatureBuffer,
  canonicalUtf8Bytes
);

trigguard verify-receipt --receipt receipt.json

Exact flags follow the TrigGuard CLI; this page documents the trust model, not a pinned CLI version.

Use the official SDK or @noble/ed25519 with the same canonical JSON bytes as the browser and CLI.

import { verify } from "@noble/ed25519";
// canonicalUtf8Bytes from sorted-keys JSON; signature from receipt
const ok = await verify(signature, canonicalUtf8Bytes, publicKey);

Protocol details

Trust model

Network: Only required for key discovery (cacheable)
Verification: Performed locally in your infrastructure (offline)
Algorithm: Ed25519 (authority receipts)
Key format: PEM SPKI, raw hex, or raw base64

Proof you can verify anywhere

Auditors

Regulators

Operators

Try it in your browser

Four steps to independent proof

Protocol steps

Fetch keys

Build canonical payload

Verify signature

Check expiry

Published signing keys

Implementation reference

Trust model

Related protocol documentation