// What is execution authorization
Decisions bound to actions
Execution authorization is the process of evaluating whether an automated action should execute before it occurs. Unlike logging and monitoring, which happen after execution, authorization is a pre-execution control that determines whether the action is allowed at all. Every high-risk surface gets an explicit decision: PERMIT, DENY, or SILENCE, with evidence you can verify. See Decision model and Protocol spec.
// Why automation needs authorization
Agents and CI don’t “mean well” by default
Automated systems can perform irreversible actions across CI/CD deployments, infrastructure changes, database migrations, payment execution, AI agent actions, and data exports. Speed without deterministic authorization is indistinguishable from incident risk. Authorization sits at the same choke point as the action—before commit. Architecture · Gate.
// How TrigGuard works
Execution request → decision
Execution request
→ POST /execute
→ Signal aggregation
→ TGSafetyEngine evaluation
→ Decision: PERMIT · DENY · SILENCE
// Execution flow
Deterministic decision pipeline
The same request context under the same policy yields the same outcome, making behavior auditable and replay-safe. Callers describe intent; the engine evaluates deterministically; permitted paths are bound to verifiable receipts. Protocol · Runtime · API.
// Execution receipts
Prove what was authorized
Every decision produces a verifiable receipt that can be validated later for integrity, authenticity, and policy context. Receipts bind policy, request context, and outcome—Receipts, Verify, Verification docs, TG-RECEIPT-SCHEMA.
// Platform components
Gate, Verify, Control, SDK
Gate — execution authorization engine
Verify — cryptographic verification of receipts
Control — governance and policy enforcement
SDK — developer integration layer
// Example execution flow
Terraform deployment request
terraform apply
→ POST /execute
→ evaluation
→ PERMIT or DENY
→ execution receipt generated