ARCHITECTURE
Execution authorization between reasoning and action
How the system fits together: automation → authorization boundary → protected surfaces. Planes, handshake, trust, and components - not ops topology.
01 · HOW TRIGGUARD WORKS
How TrigGuard Works
TrigGuard enforces a non-bypassable authorization gate between automation systems and protected execution surfaces - before irreversible actions execute.
Authorization occurs before the protected execution or irreversible side effect.
AUTOMATION SYSTEMS
Agents and copilots that drive automation
Infrastructure-as-code and runbooks
Build, release, and deploy automation
n8n, Airflow, and custom stacks
EXECUTION AUTHORIZATION GATEWAY
- Authorizes execution intents
Protected surfaces only - not every HTTP read or model call
- Evaluates policy & context
Governance mapped to executable rules
- Signs decisions
Cryptographic receipts on the hot path
- Returns PERMIT, DENY, ESCALATE, or SILENCE
Four deterministic outcomes; only PERMIT authorizes
EXECUTION SURFACES
Financial, infrastructure, data & identity, and physical systems - see the Execution Surfaces model.
- FAIL-CLOSED BY DEFAULTNO PERMITNO EXECUTION
- CRYPTOGRAPHIC RECEIPTSEvery decision is signed, verifiable, tamper-evident.
- BUILT FOR CRITICAL SYSTEMSLow latency, high reliability, designed for the execution path.
- DETERMINISTIC RUNTIMEConsistent decisions across environments and deployments.
Canonical outcomes are PERMIT, DENY, ESCALATE, or SILENCE. PERMIT issues a receipt; DENY, ESCALATE, and SILENCE are fail-closed and do not authorize.
View protocol specification →
02 · EXECUTION HANDSHAKE
Intent → evaluation → decision → receipt → enforcement
- 1Intent
- 2Evaluate
- 3Decide
- 4Sign receipt
- 5Enforce (PERMIT only)
Only PERMIT unlocks the protected surface. DENY, ESCALATE, and SILENCE are fail-closed and do not authorize execution.
03 · CONTROL PLANE VS RUNTIME PATH
Control plane vs runtime path
Governance configures policy and keys. Callers and the optional proxy sit outside the PDP. Only the runtime gateway evaluates and signs decisions on the hot path.
CONTROL PLANE
Governance & configuration
Rules · governance · configuration
Decision logic and conditions
Who can do what, where, and how
Key management and signatures
Audit logs, metrics, and insights
RUNTIME PATH
Clients call the gateway · gateway authorizes · surfaces execute
Callers (clients layer). Produce intents; never evaluate policy locally.
Optional client interceptor. Still must call the gateway - not a second PDP.
Platform hot path. Sole policy decision point (POST /execute).
Irreversible effect targets. Execute only after PERMIT.
Boundary note. TrigGuard’s repository layers are clients → platform → core. SDK and execution proxy are clients; the runtime gateway is platform. Do not treat this marketing diagram as a formal control-/data-plane ADR - operational topology lives on Infrastructure.
1. Financial operations
Payment authorization, settlement control, and disbursement verification.
Treasury movement, payment release, and settlement flow.
Liquidity operations, cash management, and financial approvals.
Trade settlement, netting, and reconciliation authorization.
2. Infrastructure
Production state changes, rollouts, and configuration updates.
Compute, storage, network, and service lifecycle operations.
System updates, scaling, and critical infrastructure modifications.
Third-party integrations and outbound system interactions.
3. Data & identity
Irreversible data boundary crossings, extractions, and disclosures.
Sensitive record retrieval, bulk access, and data visibility changes.
User provisioning, deprovisioning, and role modifications.
Access grants, privilege escalation, and policy modifications.
4. Physical systems
Motion commands, end-effectors, and autonomous machine control.
OT commands, process setpoints, and plant-floor control actions.
Vehicle, drone, and mobile-platform actuation under policy.
Interlocks, emergency stops, and high-consequence physical effects.
Runtime environments
- AI agents
- Multi-agent systems
- Autonomous workflows
- Enterprise applications
- Cloud platforms
Industries
- Financial services
- Healthcare
- Energy
- Government
- Industrial systems
- Enterprise AI
TrigGuard ensures every execution is
05 · TRUST BOUNDARIES
Trust boundaries
TrigGuard controls
TrigGuard does not
- whether a protected action may execute
- intercept every HTTP read or model inference
- policy evaluation on the hot path
- generate model reasoning or choose objectives
- authorization outcome (PERMIT · DENY · ESCALATE · SILENCE)
- replace observability or application authentication
- signed receipts and verification evidence
- authorize by monitoring after the fact
Fail-closed: no PERMIT, no protected execution.
Observability never alters authorization semantics.
06 · COMPONENTS
Components
- Runtime gateway - platform PDP: evaluate, decide, sign (
POST /execute). - Policy engine - compiled policy evaluation on the hot path.
- Client SDKs & CLI - thin callers that propose intents; never evaluate policy locally.
- MCP - connects agents/tools to the authorization boundary.
- Execution proxy (optional) - client interceptor; still calls the gateway.
- Keys & receipts - signing material and cryptographic proof of decisions.
- Decision log - transparency / append-only evidence (observability, not PDP).
- Control plane - policy bundles, identities, keys, audit/config.
07 · DEPLOYMENT ARCHITECTURE
Deployment models
- SDK / Middleware - call
authorize()from application code before protected actions. - Sidecar / Proxy - intercept outbound tool and API calls that hit protected surfaces.
- Execution Gateway - central REST path for authorization requests.
Regions, scaling, networking, persistence, availability, and failure handling: Infrastructure.