What is pre-execution authorization?
Pre-execution authorization binds policy to the commit point: deployment, transfer, purchase, write, external API call, or tool invocation. The decision must be available to the executor as a hard gate.
How it works
The executor requests authorization for a concrete action; evaluation returns before the runtime accepts the commit. Checks that run only after effect are observability, not a gate at the choke point.
// Runtime
Authorization vs monitoring
Monitoring observes reality after the fact. Authorization shapes which realities can occur. For agents and automation, runtime authorization is the only control that scales with execution frequency, see AI execution governance and execution authorization.
// Irreversibility
Irreversible decision gates
Gates belong where rollback is expensive or impossible: financial transfer, production promotion, data export, safety interlock bypass. TrigGuard models this as a deterministic decision with a receipt.
// Timing
Why "after the fact" is not authorization
Ticketing, SOX-style approvals, and quarterly audits can describe intent to allow a class of work. They rarely bind to the exact bytes, policy version, and evaluator version at the instant a commit lands. When a dispute or regulator asks whether this transfer was authorized, narratives added after execution are weak evidence. Pre-execution authorization means the decision exists before the executor accepts the operation, so the permit can be hashed with the request and verified later by Verify or your own tooling.
Runtime systems already separate "request accepted" from "side effect completed." Pre-execution authorization sits in that seam: after the caller has a concrete frame, before the surface mutates external state. That is the same placement described in runtime authorization for AI agents and the execution trace walkthrough.
// Model
Commit points, idempotency, and races
Pre-execution authorization is easiest to reason about when each commit has a stable identifier: caller, surface, action, material parameters, and an idempotency key for retries. Retries with the same key should converge on the same decision for the same policy snapshot, which is the operational meaning of deterministic authorization. Without that discipline, teams see "flaky" denials or duplicate commits that look like policy bugs but are actually ambiguous framing.
Where multiple workers compete, the gate must still be single-valued: two permits cannot imply conflicting commits for the same bounded operation. TrigGuard's contract pushes that clarity into the protocol layer so integrators do not reinvent semantics per service. See reference specification and protocol overview.
// Scenarios
Examples that fail without a pre-execution gate
CI/CD and infrastructure. A pipeline promotes an artifact or applies Terraform; the irreversible step is the API call that mutates production. Review in a pull request is not a substitute for authorization at apply time unless that review is bound to the exact plan hash being applied.
Data exports and messaging. Moving regulated rows to an external bucket or partner system is a commit, not a query. Export jobs need the same permit contract as interactive tools.
Agent workflows. Orchestrators chain tools; only the steps that touch execution surfaces need permits, but those steps must not proceed on a stale or hand-waved approval from an earlier turn. Fail-closed defaults reduce damage when context drifts between steps.
How this appears in TrigGuard architecture
Pre-execution authorization is the authorization boundary before commit: the layer stack places evaluation between automation callers and irreversible execution surfaces.
Protocol · TrigGuard architecture · Protocol architecture · Reference specification · Decision model · Verify · Pricing · Industries
Related TrigGuard concepts
Where this matters
Frequently asked questions
What problem does this solve?
Actions that become irreversible or externally visible without a decision bound to the exact request and policy version at commit time.
How is it different from AI governance tools?
Governance dashboards and offline reviews inform process; pre-execution authorization is a hard requirement on the execution path before the executor accepts work.
Why does authorization happen before execution?
Because rollback, dispute resolution, and regulatory proof all require that the permit existed prior to the commit, not as a narrative added afterward.
// Hub
Category pillar
Return to the cluster hub: AI execution governance.