Execution authorization
Execution authorization for governed AI
Monitoring explains what already happened. Execution authorization decides what may run — verify, verdict, fail-closed, and signed runtime proof before CRM, payments, or records change.
Agentic workflows trigger binding actions at machine speed. BiDigest inserts a deterministic authorization checkpoint between orchestration and systems of record — not a dashboard that notices problems after commit.
Per-LLM visibility, citation analysis, and IFQ mechanics live on the Visibility Engine — this hub is runtime enforcement and audit posture only. Open Visibility Engine.
Primary technical path
Technical architecture brief
Payload shapes, control-flow diagram, wire-field glossary, and integration FAQ — the mechanical brief for engineering and architecture reviewers.
Open architecture brief →From intent to commit: T₀ and T₁
T₀ is when an action is first presented—routing, payload shape, and early gates treat it as unverified intent. T₁ is the commit boundary: deterministic checks run again before anything binding happens, including org lifecycle (active vs suspended). If the organization is inactive, API authentication returns HTTP 403; on seal paths, telemetry can be shunted with breach codes such as ORG_SUSPENDED_AT_T1 where applicable—fail-closed, not a “best effort” filter.
Wall-clock time is route- and deployment-dependent. Governed egress sealing and staleness monitoring use different cron paths—do not promise one universal sub-50ms wall on every integration.
Three paths to start
For engineering and architecture reviewers: read the brief, run the browser simulator, then request a scoped assessment when you are ready to map domain, orchestration, and authority source. Deeper doctrine, roadmap tags, and operator handbooks are linked below—not required on first read.
- Step 1
1. Architecture brief (primary)
Payload shapes, control-flow diagram, wire-field glossary, and integration FAQ for verify → verdict → receipt_id.
- Step 2
2. Execution-boundary simulator
Client-side panels only. Payloads are not sent to BiDigest APIs or third-party models from this UI.
- Step 3
3. Scoped authorization assessment
Map your domain, orchestration path, and authority source before production verify traffic.
Optional depth: Trustee handbook (operators) · Shipped vs roadmap · Doctrine essays · Execution Control Systems category · Full glossary · Stakeholder objections · State of Admissibility 2026 (research) · Integration intake
Why this matters now
Governance under convergence
The question is shifting from "Do we have an AI policy?" to "Can we afford the gap between what we approved earlier and what we are about to commit?" Three pressures often land on the same systems and budgets—so routing around execution architecture gets expensive.
Liability & operational risk
Agentic and automated workflows raise expectations for attribution and replay after a bad outcome—not a slide deck alone.
Regulatory & audit clocks
Frameworks increasingly expect demonstrable controls and traceable decisions for material systems—scope varies by tier and jurisdiction.
Cryptographic transition
PQC roadmaps and long-lived evidence raise the cost of informal audit trails and mutable narratives.
Structural risk: time-of-check to time-of-use—approving intent at t1 and executing against the world at t4 without re-binding at the commit boundary is how stale authority becomes committed reality.
From
- Visibility and post-hoc logs as the whole story
- "We evaluated it upstream"
To
- Execution authorization and signed verification records at the commit boundary for state-changing actions
- Provable record of what crossed the boundary, when
Monitoring vs execution authorization
Post-hoc logs and model-output monitoring are necessary but not sufficient. When an agent proposes a payment, CRM write, or outbound send, you need a deterministic verify step, an explicit verdict, and a receipt_id before the binding action runs — or a fail-closed stop.
Runtime enforcement at the commit boundary
No silent failures. The commit boundary applies deterministic authorization checks before binding effects. Wall-clock latency is deployment-dependent; we do not claim the same millisecond budget on every integration path. The system fails closed and does not rely on vendor “safety” scores or a 24-hour inbox queue to catch bad payloads. Signed verification records give operators replayable proof for the lanes you configure.
Execution is decided at the commit boundary in milliseconds. Humans affirm oversight using ledger-linked review — they do not replace verify with an email queue for every payload.
Audit evidence operators can export
- Signed verification records (compact JWS) with receipt_id, input hash, and verdict for disputes and QBRs.
- Orchestration must not treat vendor “safety” scores as authorization — your policy and provisioned authority source gate the binding action.
Regulatory and board posture (high level)
EU AI Act, NIST AI RMF, and ISO/IEC 42001 programs ask for demonstrable controls and traceable decisions. Pair execution-boundary receipts with your own scope, sampling, and counsel — BiDigest supplies operational artifacts, not legal certification.
Additional resources (optional depth)
Request a scoped assessment
Map your domain, orchestration path, and authority source before production verify traffic.
Start scoped assessmentCore definitions (execution lane)
Eight terms for the execution-authorization story. Full glossary (Triple-Lock, mutation hashes on trustee paths, visibility-only terms) lives on the glossary page—not repeated here.
What is execution authorization in BiDigest?
A deterministic verify step before binding actions run: your orchestration calls the gateway, receives APPROVED, REVIEW_REQUIRED, or REJECTED, and logs a signed verification record with receipt_id — fail-closed when proof is missing.
What is T₀ (intent)?
T₀ is when an action is first presented: routing, payload shape, and early gates treat it as unverified intent until the commit lane proves otherwise.
What is T₁ (commit boundary)?
T₁ is the commit boundary: deterministic checks run again before anything binding happens. Resolution is deterministic at this layer — no generative step in the gateway.
What does fail-closed mean for operators?
Fail-closed means missing or denied authorization proof blocks the binding action — explicit refusal paths and structured signals instead of silent success.
How is execution governance different from monitoring outputs after the fact?
Monitoring explains what already happened downstream. Execution authorization focuses on eligibility before binding effects — refusing or pausing when verify does not return proof.
What is a violation at the execution boundary?
A violation is when governed logic refuses or diverts an action because deterministic rules are not satisfied — explicit errors or recorded denial receipts, not a disappointing chat answer.
What is HTTP 403 at the ingress boundary?
When authentication or lifecycle checks fail before downstream work, the request fails fast with HTTP 403 — refusal before binding effects where that path is configured.
Where do IFQ, shadow sources, and per-LLM visibility live?
On the Visibility Engine (/visibility) — citation share, per-LLM readouts, and visibility diagnostics. This governance hub focuses on verify → verdict → receipt at the execution boundary.
Full AI governance glossary (includes Triple-Lock and trustee operator detail).