GATE: The Governed Agent Trust Environment
Highlights:
- 20 Controls in 4 Layers: Identity and integrity, runtime enforcement, observability and forensics, and orchestration and ecosystem.
- Deterministic Perimeter: A control plane that wraps the probabilistic model, with policy-as-code, hash-chained ledger, and signed action evidence at every tool boundary.
- Four Governed Boundaries: Identity at instantiation, policy at execution, observation throughout, and, new in v1.4, classification at delivery through C20 output validation.
- Tier-Aware Governance: Controls adjust pass criteria to deployment autonomy, treating sandbox and high-privilege deployments differently against the same evidence stream. C20 fails closed at the high-privilege tier.
- Open and Implementable: JSON Schema contracts, OPA/Rego policy bundles, Python and Rust reference libraries, 20 conformance checks, and a CLI runner that automates 9 of them out of the box and 11 when bundle stores are configured. CC BY 4.0 for the specification, MIT for the code.
- Standards and Regulatory Alignment: Informative mappings to NIST AI RMF, NIST SSDF, ISO/IEC 42001, OWASP AISVS and MITRE ATLAS, alongside EU AI Act Articles 12, 14, 15 and 72 and Cyber Resilience Act Annex I. GATE conformance does not imply conformance with any of them.
Overview
The Architectural Problem: Production agentic AI requires governance at the tool boundary, where actions actually have consequences. Prompt guardrails and alignment work at the model layer; they cannot answer whether every action was authorised, whether the system can be stopped within five seconds, or whether an auditor can reproduce exactly what happened. GATE specifies the control plane that closes those questions.
Layer 1: Identity and Integrity: Every agent instance gets a unique, short-lived cryptographic identity bound to its runtime artefacts: the container image, the policy bundle, the prompt configuration. No shared service accounts. No long-lived API keys. v1.3 adds C17 Agent Discovery and Shadow AI Detection, continuously enrolling or terminating ungoverned workloads.
Layer 2: Runtime Enforcement: A Tool Gateway authenticates the agent, validates requests against a schema, evaluates policy-as-code, checks invariants, enforces budgets, and emits evidence before anything executes. No bypass paths. v1.3 adds C18 Data Quality Gates at the memory retrieval boundary, enforcing freshness, confidence, and provenance thresholds before retrieved content reaches the model; v1.4 chains that provenance back to a registered source or an approved external feed through two normative URI schemes.
Layer 3: Observability and Forensics: Every governed action produces a policy decision record, a hash-chained ledger event in WORM storage, and a replay trace step. Given a run ID, an operator can reproduce exactly what happened without relying on the model producing the same output twice. v1.3 adds C19 Model Behaviour Monitoring, distinct from adversarial validation, for gradual drift detection. v1.4 adds C20 Agent-to-Human Output Validation, classifying every final response at the delivery boundary for sensitivity tier, regulated categories, and confidence, with redaction, human review, and hold obligations attached.
Layer 4: Orchestration and Ecosystem: Multi-agent messages are signed, versioned, and nonce-protected to prevent replay and spoofing. The orchestration control plane enforces backpressure, safe rollout, and rollback. Continuous adversarial validation runs in CI to gate deployments against attack scenarios, and the v1.4 MITRE ATLAS mapping ties the required C16 test scenarios to named adversarial techniques.
From Evidence to Attestation: The hash-chained ledger plus the conformance runner produce regulator-ready evidence as a side effect of operating the system, rather than as a year-end exercise. The same evidence stream supports internal SRE, external audit, and supervisory authority engagement. v1.4 closes the last gap in that trail by making the C09 break-glass override a signed record with schema-enforced dual approval, scope binding, and expiry, referenced by identifier from the invariant-halt ledger event.
What v1.4 Ships Alongside the Paper: Seven open repositories move together. gate-contracts, gate-policies and gate-python go to v1.2.0; gate-conformance goes to v1.3.0 with the twentieth check and the new standards mappings; and three repositories arrive at v1.0.0 - gate-rust (a high-throughput companion crate, hash-compatible with gate-python by contract), gate-fuzz (a differential property suite that enforces byte equivalence between the two implementations), and gate-knowledge (the conceptual layer as an Open Knowledge Format bundle for agent consumption). The framework paper source is public.
Who This Framework Is For
- AI Engineers and Architects building agents that need to operate in production with auditable governance.
- CISOs and Security Architects establishing zero-trust models for non-human identities and tool boundaries.
- GRC and Compliance Counsel mapping runtime evidence to regimes such as the EU AI Act and Cyber Resilience Act, and to control standards such as NIST AI RMF, NIST SSDF, ISO/IEC 42001 and OWASP AISVS. The mappings are informative: GATE conformance does not imply conformance with any of them.
- CTOs and AI Leaders establishing the technical substrate for scalable autonomy.
About the Author
GATE is an open framework authored by Andrew Stevens, CTO and CISO at Sakura Sky, published under CC BY 4.0 (specification) and MIT (reference implementations). The canonical framework home is deterministicagents.ai; the implementation repositories live at github.com/deterministic-agents. This page on the Sakura Sky white papers surface mirrors the framework for discovery.
For the launch context, see “GATE: The Missing Infrastructure Layer for Agentic AI”. For the v1.4 release notes, see “GATE v1.4: Output Validation, a Rust Companion, and the Conceptual Layer as OKF”. For the v1.3 release notes, see “GATE v1.3: New Controls for Shadow Agents, Data Quality, and Model Drift”. For the conformance runner walkthrough, see “The GATE Conformance Runner: What You Can Automate and What You Cannot”.