Execution timeline
One action moving through the system—from request to verifiable receipt.
Control plane vs data plane
Governance and configuration above; real-time authorization on the hot path.
// SYSTEM BOUNDARY
Execution Authorization Boundary
Managed service or private deployment—same fail-closed contract: no PERMIT, no execution.
TrigGuard enforces the boundary between callers and irreversible surfaces. No evaluated request → no execution. No verified PERMIT → execution does not proceed.
Request → Gate → Verification → Receipt
Requests hit the gate first: policy evaluation, deterministic outcome, signed receipt on PERMIT—no bypass path.
Execution Lifecycle
Linear sequence of events from agent intent to signed proof. Each step is a gate; no bypass.
EXECUTION PROPERTIES
Execution systems integrating TrigGuard must enforce authorization before commit. No action is performed without a valid authorization decision.
INTEGRATION SURFACES
How systems connect to the authorization boundary.
REST_API
For cloud-native agent frameworks.
NATIVE_SDK
Low-latency Go/Rust bindings for core systems.
SIDE_CAR
Proxy-based enforcement for legacy environments.
Architecture Diagram
The protocol creates a trust boundary between automation systems requesting execution and the surfaces where irreversible actions occur.
{ action, context, metadata }
▼
{ decision, timestamp, signature }
▼
▼
Figure: TrigGuard deterministic execution flow and signed decision pipeline.
Execution Flow
Every authorization request follows a deterministic path through the system. The same inputs always produce the same decision.
POST /execute with action type, context, and metadata.
PERMIT, DENY, or SILENCE. Same inputs always produce the same output.
/.well-known/trigguard-keys.json.
PERMIT, automation system proceeds with execution. Receipt serves as audit proof.
[ SYSTEM_FAILURE_MODES · SEVERITY: HIGH ]
WHAT FAILS WITHOUT TRIGGUARD
Uncontrolled execution paths, no binding authorization at the gate.
-
AI agent executes payment without authorization
No binding decision — money moves anyway.
-
CI pipeline deploys unintended change
No commit control — production state is altered without validation.
-
Data export occurs without policy validation
No execution boundary — sensitive data leaves the system.
Core Components
The protocol is composed of discrete components with clear responsibilities and interfaces.
Authorization API
REST endpoint accepting execution requests. Validates input schema, authenticates callers, routes to policy engine. Single entry point for all authorization decisions.
Policy Engine
Evaluates requests against configured rules: action/surface bindings, context constraints, time windows. Stateless, deterministic evaluation—no learned overrides.
Decision Engine
Deterministic decision logic. Given policy evaluation results, produces consistent authorization decision. No randomness, no external state dependency.
TrigGuard operates at the point of irreversible execution, not just policy evaluation.
Receipt Generator
Packages authorization decision into structured receipt. Signs with Ed25519 private key. Includes timestamp, context hash, decision, and cryptographic signature.
Key Discovery Service
Serves public verification keys at /.well-known/trigguard-keys.json. Supports key rotation with validity periods. Enables offline verification.
Verification Layer
Client-side library for receipt verification. Fetches public keys, validates signatures, checks expiration. Works offline after initial key fetch.
Cryptographic Trust
TrigGuard uses cryptographic primitives to create verifiable, tamper-evident authorization records that work without network connectivity.
Signed Receipts
Every authorization decision produces a signed receipt. The receipt contains the decision, timestamp, action context hash, and an Ed25519 signature. Receipts cannot be forged or modified without detection. They serve as cryptographic proof that a specific authorization decision was made at a specific time.
Ed25519 Signatures
The protocol uses Ed25519 elliptic curve signatures. 256-bit security level. Fast signing and verification. Small key and signature sizes. Deterministic signature generation prevents timing attacks. Public keys are 32 bytes, signatures are 64 bytes.
Key Discovery
Public verification keys are served at a well-known URL: /.well-known/trigguard-keys.json. Keys include validity periods for rotation support. Clients cache keys and verify receipts locally. The discovery endpoint follows RFC 8615 conventions.
Offline Verification
Once a client has fetched the public key, receipts can be verified without network access. This enables air-gapped audit, local policy enforcement, and verification in disconnected environments. No callback to TrigGuard is required to validate a receipt.
Deterministic Execution Proof
The combination of deterministic decision logic and cryptographic signing creates verifiable proof of authorization. Given the same inputs, the system always produces the same decision. The signed receipt proves this decision was made by a TrigGuard-controlled private key.
Deployment Model
TrigGuard supports multiple deployment configurations depending on security requirements and infrastructure constraints.
TrigGuard Cloud
Hosted authorization service. API access via api.trigguardai.com. Managed key infrastructure, automatic rotation, high availability. Fastest path to integration.
CI/CD Integration
GitHub Actions, GitLab CI, Jenkins, CircleCI. Authorization checks integrated directly into deployment pipelines. Blocks or gates execution based on policy decisions.
API Gateway Layer
Deploy as middleware in API gateway. Intercepts requests to protected endpoints. Returns authorization decision before request reaches backend services.
Self-Hosted Runtime
On-premises deployment for enterprises requiring full control. Private key management, custom policy engine, air-gapped operation. Contact for enterprise discussion.
// SECURITY_GOVERNANCE
TG-01 protocol provides the immutable decision record required for Section CC7.2 (System Operations).
Metadata-only processing. No PII ingestion. Zero-retention authorization models available for local sidecars.
Non-repudiable execution. Protection against prompt-injection escalation and model-drift.
TrigGuard is designed to be the primary control point for AI-system assurance workflows. Every PERMIT / DENY / SILENCE decision is exportable to external SIEM/SOAR platforms.
// TECHNICAL_FAQ
Production behavior, failure mode, and verification. No marketing—SLA-level answers.
- FAQ-01 How does TrigGuard hit its latency targets?
- RESPONSE: Two scoped numbers: kernel hot path <5ms p99 and end-to-end evaluation <15ms p99 on the finite-state path under normal load. A lightweight, compiled policy engine and localized caching of cryptographic keys avoid model-inference round-trips on the critical path.
- FAQ-02 What happens if the TrigGuard service is unreachable?
- RESPONSE: The system is Fail-Closed by default. If the authorization boundary cannot verify a signed permit, the execution is killed. For high-availability environments, we provide local sidecar deployments to ensure line-rate authorization even during network partitions.
- FAQ-03 Does TrigGuard read my application data?
- RESPONSE: No. TrigGuard operates on Action Metadata and Intent Schemas. We do not ingest your raw database contents or full chat histories. We only evaluate the specific parameters of the irreversible action being requested (e.g., destination, amount, system-level impact).
- FAQ-04 How is the ‘Signed Receipt’ verified offline?
- RESPONSE: Every decision is signed using Ed25519 asymmetric cryptography. Your execution surface can verify the authenticity of a permit using our public keys (available via
/.well-known/trigguard-keys.json) without ever making an outbound call to our servers.