Oak & Sparrow Gatekeeper
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.
1Executive overview
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. |
2The enterprise AI execution problem
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.
- Prompt injection and jailbreaks. Adversarial inputs can redirect reasoning toward unauthorized tool calls or attempts to bypass intended constraints.
- Hallucinated tool invocation. Plausible but incorrect API parameters can target the wrong resource, escalate privilege, or trigger unintended side effects.
- Cascading automation drift. Multi-agent loops can compound error before a human operator observes the deviation.
- Post-hoc audit failure. Ordinary application logs can show that an action was requested without proving which policy version, authority, approval, or exact execution state governed it.
3The Gatekeeper architectural principle
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.
- Pre-execution authorization. The exact canonical request is evaluated before the downstream API call, database write, infrastructure change, or other consequential effect.
- Rules as code with deontic structure. Policy is versioned and deterministic. Permission is an explicit grant backed by a named rule. Missing authority does not silently become permission.
- Least-data minimization. Decisioning can operate on structured metadata, identity, target resources, and policy provenance rather than requiring raw prompts, complete chat histories, or sensitive enterprise payloads.
4Scope boundaries
| 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. |
5Architecture and execution lifecycle
Stage 1: pre-execution request
The calling agent or application sends a structured canonical action envelope containing requesting identity, action type, target resource, relevant thresholds, and security context.
Stage 2: deterministic authorization
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.
Stage 3: post-execution validation and evidence
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.
6Deterministic policy and decisioning
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.
7Safety Receipts and ProofVault
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. |
8Deployment and integration models
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.
9Representative enterprise use cases
| 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.
10How Gatekeeper complements existing systems
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?
11Product differentiation
| 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. |
12Validation record and scope boundaries
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. |
Explicit non-claims
Gatekeeper does not claim to guarantee legal compliance, provide nonrepudiation, operate as a blockchain, use zero-knowledge proofs, or replace an existing security platform.
13Evaluation questions for enterprise leaders
- Where does final execution authority reside when an autonomous agent prepares to invoke a consequential tool or API?
- How does the current architecture prevent a prompt injection from translating directly into an unauthorized infrastructure change or database write?
- Does the current stack bind the exact proposed action, policy version, human approval, and resulting system state into one reconstructable record?
- How are fail-closed defaults enforced for high-consequence actions while routine authorized actions retain low-latency execution?
14Conclusion
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.