Deterministic Execution Control for Enterprise AI Agents
Enterprise AI is moving from conversational recommendation toward autonomous workflow. Agents now invoke tools, query sensitive databases, modify infrastructure, execute financial transactions, and trigger automated security responses. Gatekeeper places a deterministic authority boundary between those probabilistic proposals and the enterprise systems they can affect.
Probabilistic machine-learning systems are strong at reasoning, pattern synthesis, and task decomposition. Those capabilities do not create invariant execution authority. Gatekeeper evaluates versioned policy, identity, requested authority, human approvals, and operational context before an action crosses the commit boundary.
| Outcome | Authority verdict | Operational response |
|---|---|---|
| GREEN | Authorized | Execution may proceed within bounded parameters. A Safety Receipt is produced. |
| YELLOW | Human review required | Execution pauses and a review interval is inserted before commit. |
| RED | Denied | Execution is blocked and the fail-closed decision is recorded. |
Traditional security controls were designed around software with predictable code paths. Instruction-tuned language models operate in probabilistic proposal space. When those models can call consequential tools, four recurrent risks become architectural rather than merely conversational.
Gatekeeper separates the probabilistic reasoning engine, which proposes actions, from the deterministic authority that decides whether the exact proposed transition can execute. The architecture is built around three primitives.
| Gatekeeper is | Gatekeeper is not |
|---|---|
| A non-AI Policy Decision Point; a pre-execution authorization gate; a versioned rules-as-code evaluation engine; a decision-to-execution evidence recorder; a cross-system verification authority. | An LLM or prompt scanner; an AI gateway or provider router; a Policy Enforcement Point; a replacement for SIEM, SOAR, identity systems, secure browsers, or existing enterprise platforms. |
The calling agent or application sends a structured canonical action envelope containing requesting identity, action type, target resource, relevant thresholds, and security context.
Gatekeeper evaluates the request against active, versioned policy. A forbidden action, missing credential, or absent required approval produces RED or YELLOW. An authorized action produces GREEN and can be bound to short-lived, single-use capability material.
The connected system returns the execution result or resulting state delta. The completed action can be compared with the authorized scope, and the finalized Safety Receipt is sealed into ProofVault.
Policies are immutable, versioned rule packs in the decision path. GREEN, YELLOW, and RED are the external product verdict vocabulary. Internal harness or integration tokens may differ, but any published mapping must remain explicit and reconcilable against the underlying test record.
YELLOW is not a weaker GREEN. It re-inserts human review before execution. RED is not a warning after the fact. It is a denial before system change.
Each governed authorization request produces a structured Safety Receipt. The record is designed to preserve the relationship among the exact proposed action, active policy, requesting identity, resulting verdict, and execution outcome.
| Receipt element | Recorded content |
|---|---|
| Canonical action digest | SHA-256 digest of the exact proposed action parameters. |
| Policy provenance | Policy version, rule-pack hash, and the rule references applied. |
| Identity and context | Authenticated agent, user, tenant, and approver identifiers where applicable. |
| Deterministic verdict | Issued outcome with explicit reason codes. |
| Execution match | Evidence of whether the resulting state matched the authorized intent. |
| Chain linkage | Cryptographic linkage to the prior governed record. |
Gatekeeper can be integrated as a centralized API decision service, a sidecar near agent workloads, a pre-execution step in an orchestration playbook, or an authorization surface connected to an AI gateway or agent framework. The integration pattern can change without moving final authority back inside the model.
| Scenario | Proposed action | Typical governed outcome |
|---|---|---|
| Sensitive data access | Bulk export exceeds an approved data threshold without required approval. | YELLOW, hold and escalate. |
| Account changes | Agent proposes a privileged role change requiring multi-party consent. | YELLOW, hold until approval. |
| Infrastructure modification | Agent proposes an explicitly forbidden open-internet firewall rule. | RED, block before change. |
| Production deployment | Release is attempted without a required security gate. | RED, block deployment. |
| Financial action | Transfer exceeds a dual-control threshold. | YELLOW, hold for dual authorization. |
| Automated remediation | Security automation targets a tier-zero asset requiring human signoff. | YELLOW, hold before isolation. |
These are representative policy configurations, not claims about specific deployed customer environments.
AI gateways and provider routers manage model access, routing, quotas, and latency. Identity systems establish who or what is authenticated. SIEM and orchestration platforms collect events and coordinate procedures. Gatekeeper consumes relevant signals from those systems and answers the narrower execution question: is this exact action authorized in this context now?
| Dimension | Common control pattern | Gatekeeper pattern |
|---|---|---|
| Decision basis | Probabilistic risk scoring, prompt patterns, or semantic similarity. | Deterministic, versioned rules as code. |
| Execution timing | Post-hoc logging or prompt/response filtering. | Authorization at the proposal-to-commit boundary. |
| Human escalation | Alert queued after or beside workflow activity. | Synchronous YELLOW hold before commit. |
| Evidence | Application logs and event traces. | Cryptographically linked Safety Receipts with policy and action provenance. |
| Post-commit verification | Often outside the authorization decision. | Resulting-state comparison against authorized scope. |
Oak & Sparrow separates benchmark evidence from field deployment. The figures below are the documented state of the Gatekeeper V2 reference-candidate record represented by External Release 1.0.
| Benchmark | Recorded result |
|---|---|
| Reference-candidate build | 357 unit tests across 511 tracked codebase files, with 17,565 deterministic attack and fuzz cases executed. |
| 1,000-request evaluation | 99.6 percent local artifact-sealing coverage, 996 sealed receipts, with continuous verified artifact-chain sequencing across the run. |
| Warrant reference E4 enforcement certification | 47 authorizing verdicts produced 47 authorized effects; 0 effects occurred across the remaining 953 non-authorizing and timeout cases; all 18 adversarial and bypass cases failed closed. |
Gatekeeper does not claim to guarantee legal compliance, provide nonrepudiation, operate as a blockchain, use zero-knowledge proofs, or replace an existing security platform.
As enterprise AI moves toward autonomous operation, security architecture must extend beyond probabilistic content filtering. Gatekeeper supplies a deterministic execution-control layer so models can propose actions while authority over commit remains governed, verifiable, and capable of failing closed.
The recommended evaluation starts with one consequential workflow: identify the proposal-to-commit boundary, define the policy authority that governs it, bind the exact action to that authority, and test both authorized and denied paths against reconstructable evidence.