TrigGuard
TRIGGUARD ARCHITECTURE
Open Console

EXECUTION AUTHORIZATION

Execution authorization stack

TrigGuard is execution authorization infrastructure for agents and automation: SDKs reach a runtime authorization gateway; connector-bound deployments add an execution proxy so PERMIT / DENY / SILENCE runs before side effects. Receipts are signed; verification is independent.

Model governance decides whether a model may be deployed. Execution authorization decides whether a specific action may run.

That is the category line TrigGuard implements at the tool boundary.

Start evaluating View architecture

No PERMIT, no execution.

Every action must be authorized before it runs.

Pre-execution authorization for AI systems.

Deterministic decisions.

Verifiable outcomes.

Protocol path: /protocol/architecture · AI execution governance · pre-execution authorization · deterministic authorization · policy enforcement engine · fail-closed AI systems · Execution authorization · Products · Docs

FIVE SECOND MODEL

The adoption primitive

One hook, one decision axis, one receipt - the minimum path from agent intent to provable authorization.

  1. Propose Agent proposes an action with context
  2. Authorize guard() TrigGuard evaluates via POST /execute
  3. Decide PERMIT · DENY · SILENCE before side effects
  4. Execute Action runs only on PERMIT
  5. Prove Ed25519-signed receipt, verified offline

No PERMIT, no execution.

AI control stack

TrigGuard is a cloud-neutral pre-execution authorization layer. In the six-layer operating model, it sits after execution infrastructure and before observability and compliance.

NO PERMITNO EXECUTION

INTEGRITY

Core architectural properties

Deterministic

Every request produces exactly one outcome based on active policy. No probabilistic guessing.

Fail-closed

If authorization cannot be confirmed, execution is blocked by default. Safety first.

Verifiable

Every decision is cryptographically signed (Ed25519) and can be verified offline at any time.

DATA FLOW

The path of a decision

Authorization runs on the hot path before side effects. The gateway evaluates policy, signs the outcome, and only then may execution proceed.

Automation system
Request + context
TrigGuard authority Evaluate · Decide · Sign
Decision + receipt
Execution surface

DEPLOYMENT

Integration paths

SDK / middleware

Deep integration into Node.js or Python application code.

Sidecar proxy

Infrastructure-level proxy for outbound tool and API calls.

Execution gateway

Centralized REST API for all agentic authorization requests.

TRUST

Independent verification

Because every receipt is signed with an Ed25519 private key, you can verify authorization without ever calling TrigGuard's API again.

# Verify a receipt offline
trigguard verify ./receipt.json --public-key ./authority.pub

FAQ

Architectural details

What is the added latency?
Decisions typically take < 15ms. The majority of this is signature generation. Policy evaluation is performed in-memory against a compiled representation.
What happens if TrigGuard is offline?
TrigGuard is designed for high-availability. However, the system is strictly fail-closed. If the authorization layer is unreachable, the request is denied.
Can I host my own Arbiter?
Yes. Enterprise customers can deploy the Arbiter as a native sidecar or containerized service within their own VPC for maximum security and performance.