Cryptographic verification is offline against published keys; discovery endpoints are public. The execution authorization gateway is in private beta and not yet publicly deployed. The overview below links canonical specs; it does not replace the authoritative protocol source.
TG-01 protocol playground - generate signed receipts, tamper the JSON, and offline-verify in the browser (fixture key, same canonical bytes as trigguard verify-receipt).
PROTOCOL PRIMITIVES
POST /execute
Single entry point for pre-execution evaluation. Request fields: surface, action, context, idempotency_key. Irreversible work proceeds only after an explicit PERMIT and signed receipt.
/.well-known/trigguard/keys.json
Public keys for offline verification. No callback to TrigGuard required after issuance.
Ed25519
Issuer-signed receipts use Ed25519 over canonicalized JSON. Tamper-evident, offline-verifiable, immutable.
Offline Verification
Verify receipts against published keys locally. Third parties can validate enforcement without trusting our uptime.
FORMAL PROTOCOL STANDARDS
Protocol Specification
TLS carries the channel; identity stays at your IdP. TrigGuard's job is execution governance, binding outcomes and signed proof. Formal specs for audit and procurement.
I. Abstract
The TrigGuard protocol (TGP) defines a cryptographic boundary between callers (automation, agents, CI) and irreversible execution. TGP operates before commit: every state-changing path must receive an explicit authorization decision and signed receipt. There is no silent default-allow, if evaluation fails or is incomplete, execution does not proceed. For how this fits the broader category, see AI execution governance.
Visual category map: execution governance architecture on the pillar. Agent-oriented stack diagram: AI agent safety (single deep diagram, not duplicated here).
II. Core Architecture: The Gate Model
The protocol follows a Request-Attestation-Receipt loop:
- Intercept: All
POST /executerequests enter the single authoritative evaluation layer. - Validation: Declared context is hashed and evaluated against deterministic policy, same conditions, same outcome.
- Signing: On PERMIT (only), the protocol issues an Ed25519-signed receipt over the canonicalized payload. DENY and SILENCE still yield a deterministic, attributable outcome.
- Execution: Downstream systems must not commit without a valid PERMIT receipt binding that request.
TrigGuard operates at the point of irreversible execution, not just policy evaluation.
Technical Properties
Low latency (scoped)
Kernel hot path <5ms p99; end-to-end evaluation <15ms p99, no scoring layers, no hidden models in the decision path. Measured: kernel p99 0.018 ms, sequential pipeline p99 1.28 ms (raw artifacts at /benchmarks).
Cryptographically enforced
Ed25519-signed receipts over canonicalized payloads. Tamper-evident, immutable, verifiable offline against the issuer's published public key.
Zero standing trust at verify
Integrate at the same choke point you use for deploy/pay/export. Enforce before commit, verify without callback.
III. Payload Specification
Every authorized action must contain the following header structure:
{
"tg_receipt_id": "uuid-v4",
"tg_signature": "base64_encoded_hash",
"tg_timestamp": "unix_epoch",
"tg_policy_ver": "1.0.4"
}Protocol Flow
Request → authoritative evaluation → deterministic outcome → signed receipt (on PERMIT) → caller executes only if PERMIT.
01, EXECUTION API (PRIVATE BETA)
POST /execute
Status. The hosted Execution Authorization Gateway is in private beta and is not yet publicly deployed. Requests to api.trigguardai.com/execute will fail until access is granted. The shape and semantics below are the reference contract for the hosted gateway. The verification and discovery surfaces at https://trigguardai.com are live today; see the API reference and openapi.yaml. Request access to the beta.
The future gateway will accept a pre-execution evaluation request for an irreversible action and return PERMIT, DENY, or SILENCE; downstream execution proceeds only on PERMIT with a valid receipt.
# Request shape (reference; endpoint not yet deployed)
POST https://api.trigguardai.com/execute
Authorization: Bearer $TRIGGUARD_API_KEY
Content-Type: application/json
{
"surface": "deploy.release",
"action": "promote-to-production",
"context": {
"commit": "a1b2c3d4",
"branch": "main",
"environment": "production",
"actor": "ci-bot"
},
"idempotency_key": "deploy-2026-03-13-001"
}# Reference response: PERMIT
HTTP/1.1 200 OK
{
"decision": "PERMIT",
"receipt_id": "tg_rcpt_a0b1c2d3e4f50607",
"timestamp": "2026-03-13T14:22:00.000Z",
"expires_at": "2026-03-13T14:32:00.000Z",
"payload_hash": "sha256:9f86d0...hex",
"signature": "rsa-sha256:base64...",
"key_id": "tgk_example_key_id"
}# Reference response: DENY
HTTP/1.1 403 Forbidden
{
"decision": "DENY",
"reason": "policy_denied",
"policy_id": "policy_example_001",
"message": "Production deploys denied outside business hours",
"receipt_id": "tg_rcpt_b1c2d3e4f5060708",
"signature": "rsa-sha256:base64..."
}02, DECISION TYPES
Three Possible Outcomes
Every request produces exactly one of three deterministic outcomes. No probabilistic reasoning. No ambiguity.
PERMIT
Action is authorized. Receipt is valid for the specified TTL. Proceed with execution.
DENY
Action is denied. Reason and policy ID included. Do not proceed.
SILENCE
SILENCE means no authorization was issued. Without authorization, execution cannot proceed. (Evaluation may be indeterminate in cause, still explicit non-permission.)
- PERMIT → execution proceeds
- DENY → system blocks execution
- SILENCE → no authorization → execution cannot proceed
LAYERS
Receipts record decisions. Runtimes record enforcement.
Do not mix vocabulary on a single axis. Decision (receipt-safe, auditor-facing): PERMIT, DENY, SILENCE. Enforcement (runtime telemetry, operator records): EXECUTED, BLOCKED. The word BLOCK is not a decision label, BLOCKED is what the system did after receiving a decision.
Rule: Decisions DENY. Systems BLOCK. A signed receipt always records what TrigGuard decided, not whether the caller later attempted execution.
# Correct two-field representation
{
"decision": "DENY",
"enforcement": "BLOCKED"
}Invariant: any outcome other than PERMIT maps to enforcement = BLOCKED in a conformant integration. PERMIT may yield EXECUTED or BLOCKED only if downstream execution fails or an operator aborts.
03, KEY DISCOVERY (LIVE)
GET /.well-known/trigguard-keys.json
The conformance signing key is published at a well-known endpoint as a JWK Set. The same key is also returned inline as public_key (PEM) by GET /.well-known/trigguard; both surfaces are kept in sync.
# Live key set (Ed25519 conformance key, single entry today)
GET https://trigguardai.com/.well-known/trigguard-keys.json
# Response
{
"keys": [
{
"kty": "OKP",
"crv": "Ed25519",
"use": "sig",
"alg": "EdDSA",
"kid": "tgk_example_key_id",
"x": ""
}
],
"discovery": "https://trigguardai.com/.well-known/trigguard"
} The same key is also returned inline as public_key (PEM) by GET /.well-known/trigguard. Multi-key sets, additional signature algorithms, and key-rotation lifecycle apply to the future Execution Authorization Gateway. Ed25519 will continue to be accepted indefinitely under the additive-only versioning rule.
04, RECEIPT FORMAT
Signed Receipt Structure
Every decision produces a cryptographically signed receipt. Receipts are self-contained and verifiable offline.
Receipts are issuer-signed attestations, not multi-validator final-truth claims. They are immutable once signed: validator judgments live in separate validation artifacts that reference the receipt, never inside it. See Receipts for the full protocol artifact specification.
05, OFFLINE VERIFICATION
Verify Without Network Access
Once you have the public keys, verification requires no network call to TrigGuard. Cache keys, verify locally.
# Verification pseudocode
def verify_receipt(receipt, public_keys):
key = find_key(public_keys, receipt.key_id)
if not key:
return False
payload = canonical_json({
"receipt_id": receipt.receipt_id,
"decision": receipt.decision,
"timestamp": receipt.timestamp,
"execution_surface": receipt.execution_surface,
"context_hash": receipt.context_hash
})
# Optional: confirm the canonical-payload anchor before signature verify.
if receipt.payload_hash:
if sha256_hex(payload) != receipt.payload_hash:
return False
return rsa_sha256_verify(
key.public_key,
payload,
base64_decode(receipt.signature)
)PROTOCOL STABILITY
What's frozen, what evolves
TrigGuard treats the receipt artifact and the execution-surface taxonomy as long-lived infrastructure protocol, closer to a wire format than a feature surface. The following commitments are binding under TrigGuard protocol governance:
Frozen taxonomy
The canonical 13 execution surfaces are bounded and named at the infrastructure level. New surfaces require an explicit governance amendment, not a per-integrator addition.
Additive-only schema
The receipt schema evolves under an additive-only rule. Renaming, removing, or re-meaning existing fields requires a hard-freeze amendment with a published migration window.
Long-term verifiability
Receipts are immutable, offline-verifiable artifacts. Ed25519 signatures will be accepted indefinitely; the canonical payload-hash anchor lets a verifier re-bind to the exact bytes that were signed years after issuance.
Governance is the spec
Authoritative protocol commitments live in published governance documents (SURFACE_TAXONOMY_DECISION.md, RECEIPT_SCHEMA_LOCK_IN.md, SURFACE_RUNTIME_MIGRATION_PLAN.md). Site documentation mirrors them; on conflict, governance and code win.
Source-of-truth order: actual code → deployed behavior → infrastructure config → governance documents → site documentation. This order is enforced in engineering review.
PROTOCOL MAP
How the protocol is organized on this site
Canonical paths for crawlers and engineers, each page links back into products and docs so nothing sits orphaned.
Also see Products, Docs, and /protocol/spec ↔ /docs/api for cross-links.
06, FORMAL SPECIFICATIONS
Protocol Standards
Complete protocol specifications in RFC-style documentation. Cite these in compliance reviews, security audits, and vendor assessments.