TrigGuard
TRIGGUARD DOCS
Request a demo

TrigGuard Protocol Version v1.0

How to integrate pre-execution governance: API contract, surfaces, receipts, verification, and CI patterns—deterministic enforcement, not advisory tooling.

Run your first execution gate (30 seconds)

Quickstart View Protocol What is execution authorization?

// GETTING STARTED

Installation#

TrigGuard is two layers: a protocol library (types, canonical evaluation helpers, spec alignment) and an execution gateway (hosted evaluation, signed receipts, verification). The npm install line covers only the first; production systems gate irreversible work through the gateway.

Registry honesty: @trigguard/protocol is on npm. There is no trigguard or @trigguard/client package yet—do not document those until they ship.

Protocol library

Use for shared types, offline or test harness evaluation, and tooling that mirrors the spec. Exact exports are defined by the package.

npm

Install

npm install @trigguard/protocol
js

Minimal pattern

import { evaluate } from "@trigguard/protocol" const decision = await evaluate(signalFrame, policy) if (decision === "PERMIT") { await execute() }

Execution gateway

Production execution surfaces should call the TrigGuard execution gateway: POST /execute with your API credentials. Responses include a deterministic decision (PERMIT / DENY / SILENCE) and may include a signed receipt for evidence and audit.

Verify receipts offline or in your stack via Receipt verification and key discovery (TG-KEY-DISCOVERY).

POST https://api.trigguardai.com/execute Authorization: Bearer $TG_API_KEY Content-Type: application/json

→ Full Quick Start: curl example, API key, and enforcement flow

// ARCHITECTURE

How TrigGuard Works#

Evaluation runs before irreversible execution. Callers hit the evaluation layer first; APIs, payments, and surfaces run only after an explicit PERMIT.

  • Caller submits intent — Surface + arguments go to POST /execute.
  • TrigGuard evaluates policy — Deterministic rules return PERMIT, DENY, or SILENCE. Same conditions → same outcome.
  • Execution stays fail-closed by default — No PERMIT means no commit: no credential release, no side effects, until policy returns PERMIT.

TrigGuard operates at the point of irreversible execution, not just policy evaluation.

  • PERMIT → execution proceeds
  • DENY → system blocks execution
  • SILENCE → no authorization → execution cannot proceed

// QUICK START

Run Your First Execution Gate (30 seconds)#

01

Get API Key

Request access to receive your TG_API_KEY for authorization requests.

export TG_API_KEY="tg_live_..."
02

Call POST /execute

Require an evaluated PERMIT before any irreversible operation. If TrigGuard cannot verify, enforcement is fail-closed (BLOCKED).

curl https://api.trigguardai.com/execute \ -H "Authorization: Bearer $TG_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "surface": "payments.charge", "action": "transfer_funds", "context": { "amount": 5000, "currency": "USD" }, "idempotency_key": "tx_9921" }'

Response:

{ "decision": "PERMIT", "receipt": { "idempotency_key": "tx_9921", "decision": "PERMIT", "timestamp": "..." } }
03

Check decision, then run

Only if decision is PERMIT may the real action run. DENY refuses explicitly; SILENCE means no authorization was issued—without authorization, execution cannot proceed. Both yield enforcement BLOCKED. Store the receipt as evidence. With the SDK:

import trigguard as tg decision = tg.execute( surface="payments.charge", action="transfer_funds", context={"amount": 5000, "currency": "USD"}, idempotency_key="tx_9921", ) if decision.permit: run_payment()

// CORE CONCEPTS

Protocol Reference#

SPEC

TG-EXECUTION-AUTH-01

Execution authorization protocol: POST /execute, request shape, PERMIT/DENY/SILENCE, fail-closed semantics.

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, key discovery integration.

// INTEGRATION GUIDES

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.

// SECURITY MODEL

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

Ed25519 Signatures#

All receipts are signed with Ed25519. Keys are rotated regularly and published at well-known endpoints.

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.