TrigGuard Protocol Version v1.0

How to integrate pre-execution governance: API contract, surfaces, receipts, verification, and CI patterns, deterministic enforcement, not advisory tooling. Start from the protocol overview, map components on products, read execution authorization for vocabulary, and use AI execution governance as the category hub linking policy enforcement engine, deterministic authorization, and pre-execution authorization.

Discovery, key material, and offline verification paths are public. Request access for the execution authorization gateway (private beta, not yet publicly deployed).

Verify a receipt offline (browser or CLI, no callback)

Installation#

TrigGuard exposes two surfaces. The Protocol Verification authority is live today, public, and requires no API key. The Execution Gateway (which produces signed PERMIT/DENY/SILENCE receipts) is in private beta; request access to join.

This page is the docs index. Canonical onboarding lives at /docs/quickstart; SDK package boundaries live at /products/sdk.

Execution Gateway (private beta)

A hosted gateway that produces signed PERMIT / DENY / SILENCE receipts for irreversible actions is on the roadmap. The reference protocol shape (POST /execute with a Bearer token, signed receipt response) is documented in TG-EXECUTION-AUTH-01 (DRAFT). The endpoint is not currently served by any TrigGuard deployment.

To be notified when the gateway ships, submit a contact request via /contact (which posts to /api/request-access). Verification, discovery, and the conformance public key at /.well-known/trigguard are live today.

→ Full quickstart: verify a receipt today, request to be notified about the gateway

How TrigGuard Works#

Architecture depth is canonical on /architecture, and normative decision semantics are canonical on /protocol. This docs index links into those owners rather than duplicating full flow explanation.

Open architecture flow → · Open decision model →

Quickstart#

Quickstart is owned by /docs/quickstart. This index keeps only routing.

Open the quickstart ->

Protocol Reference#

SPEC (DRAFT)

TG-EXECUTION-AUTH-01

Reference shape for the hosted execution authorization gateway: POST /execute, PERMIT/DENY/SILENCE, fail-closed semantics. Private beta.

SPEC

TG-RECEIPT-SCHEMA

Receipt schema specification. Field definitions, signature format, expiry semantics.

SPEC

TG-KEY-DISCOVERY

Key discovery protocol. /.well-known/trigguard-keys.json, key rotation, verification.

MODEL

Decision vs enforcement

Two-layer contract: decisions (PERMIT/DENY/SILENCE) vs enforcement (EXECUTED/BLOCKED). Invariants and schemas.

REFERENCE

API Reference

Complete API documentation. Endpoints, parameters, responses, error codes.

REFERENCE

Authorization Surfaces

Surface taxonomy. deploy.*, infra.*, data.*, secrets.* naming conventions.

REFERENCE

Receipt Verification

Offline verification. Ed25519 signature validation against canonical payload, key discovery integration.

Runtime integration#

CI/CD

GitHub Actions

Enforce evaluation in GitHub workflows, deploys and promotions do not proceed until PERMIT.

INFRASTRUCTURE

Terraform

Pre-apply authorization for infrastructure changes. External data source integration.

API

REST API

Direct API integration. curl examples, client libraries, webhook patterns.

CLI

Command Line

CLI integration patterns. Shell scripts, local development, testing.

Trust & Verification#

TrigGuard is a deterministic authorization boundary, not a copilot, not after-the-fact telemetry. No probabilistic scoring, no learning loop in the decision path. Every request yields PERMIT, DENY, or SILENCE on the decision layer; enforcement (EXECUTED / BLOCKED) is recorded separately by the runtime.

Security Reporting

If you discover a vulnerability in TrigGuard infrastructure, protocol interfaces, or verification flows, please report it responsibly to security@trigguardai.com. See our Security Policy for scope and response expectations.

CRYPTOGRAPHY

Receipt Signatures (Ed25519)#

Receipts are signed with Ed25519 over a canonicalized JSON payload. Public keys are published at well-known endpoints; signatures are immutable and offline-verifiable.

VERIFICATION

Offline Verification#

Receipts can be verified without network access. Fetch public keys once, verify forever.

KEY DISCOVERY

Key Transparency#

TrigGuard publishes signing keys through a well-known discovery endpoint. Clients fetch the current key set from /.well-known/trigguard-keys.json. Keys are rotated regularly and previous keys remain available to verify historical execution receipts. All receipts include a key identifier (kid) referencing the signing key used.

SECURITY

Security Policy#

Responsible disclosure, vulnerability reporting, key management principles.

Documentation FAQ#

SURFACES

Protocol Verification vs Execution Gateway

Offline verification is the trust path today: Ed25519 over canonical receipt JSON using published keys from /.well-known/trigguard-keys.json, plus discovery via capabilities. No callback to TrigGuard is required. The Execution Gateway (private beta) is the hosted evaluation path that issues PERMIT/DENY/SILENCE for irreversible actions; shape is in TG-EXECUTION-AUTH-01 (DRAFT).

ACCESS

API keys for verification?

No API key is required to verify receipts offline. Use published keys from /.well-known/trigguard-keys.json with the CLI or /verify.

QUICKSTART

Canonical quickstart URL

Follow /docs/quickstart end-to-end against the live authority.

SEMANTICS

SILENCE vs DENY

DENY is an explicit refusal. SILENCE withholds authorization without leaking sensitive policy signals; execution cannot proceed without a PERMIT.