GATE v1.4 ships today. It adds one control, three standard mappings, and three repositories, taking the Governed Agent Trust Environment from 19 controls to 20 across the same four layers: Identity and Integrity, Runtime Enforcement, Observability and Forensics, and Orchestration and Ecosystem. It is the largest release since I first published the framework in April. Existing C01 through C19 implementations remain compatible.
The release lives at github.com/deterministic-agents/gate/releases/tag/v1.4 (Stevens, 2026), with the artifacts bundle, SHA256SUMS, a single-file markdown export of the paper, and the 141-page PDF. The paper source is now public at gate-framework-paper. The framework home is deterministicagents.ai and the components sit under open licences at github.com/deterministic-agents. For the architectural rationale, “GATE: The Missing Infrastructure Layer for Agentic AI” remains the canonical introduction, and the v1.4 roadmap post from June sets out what I said this release would contain.
C20 Agent-to-Human Output Validation
GATE governed what an agent could execute at the tool boundary and what it could retrieve at the memory boundary. It said nothing about what the agent delivered at the end. C20 closes that.
The control sits in Layer 3, Observability and Forensics, alongside C13 intent telemetry and C19 drift monitoring. It performs per-response classification at the delivery boundary. Each final response carries a sensitivity tier, any regulated content categories it touches, a confidence score, and the obligations that follow: redact_fields, hitl_review, hold_for_review. At the high_privilege tier the control fails closed: a response whose classification matches no explicit pass-through entry in the signed action matrix is held, not delivered, enforced by the bundle schema and a policy guardrail rule. An output classification event is emitted per response, which gives the delivery boundary the same evidence coverage that tool envelopes give the tool boundary.
That is the fourth boundary in the model: identity at instantiation, policy at execution, observation throughout, classification at delivery. For most deployments the output gap is tolerable. For healthcare, legal advice, financial guidance, and HR decision support, obligations about what may be delivered, to whom, and under what review conditions are as real as obligations about what may be executed.
Break-glass becomes a contract
C09 has always required a signed record and dual approval for an invariant-halt override. What it lacked was a machine-verifiable format, so the record lived as a narrative document tied to a ledger event by convention.
v1.4 adds break_glass_record.schema.json to gate-contracts, with dual approval, scope binding, and expiry enforced by the schema. The invariant-halt ledger event now carries a break_glass_record_id referencing a valid record whenever an override was authorised, so a conformance runner can verify that each halt either resolves to one or was never overridden. That distinction previously required manual audit. This is a tightening rather than a new control. C09 stays C09 and the semantics do not change.
Two other controls tighten alongside it. C17 gains an automated enrolment fast-path backed by a signed policy contract, so discovered workloads can be enrolled without a human in the path when the policy says they qualify. C18 provenance now chains back to a registered source or an approved external feed through two normative URI schemes, which removes the ambiguity in what counted as an acceptable provenance claim.
OWASP AISVS, MITRE ATLAS, and NIST SSDF
The paper’s standard mappings previously covered NIST AI RMF and ISO/IEC 42001, with EU AI Act alignment carried in the control text. v1.4 adds three more: OWASP AISVS, which reached 1.0 on 24 June and states testable security requirements across the AI system lifecycle (OWASP, 2026); MITRE ATLAS, the technique taxonomy for adversarial attacks on AI systems, whose tactics and techniques the mapping ties to the specific test scenarios C16 requires, so an adversarial validation harness has a threat model behind it rather than a list of categories (MITRE, 2026); and NIST SSDF, the secure development practice set issued under US Executive Order 14028 (Souppaya, Scarfone and Dodson, 2022), mapped as a deliberately narrow intersection: GATE touches SSDF at the artifact-integrity and tool-gateway surfaces (C03, C05) and marks everything else out of scope.
The mappings are pinned to upstream snapshots (AISVS v1.0, ATLAS content 2026.05) and machine-validated by a validator that ships in the repo: every referenced requirement and technique identifier must resolve against the pinned upstream with a matching title. Identifiers drift between revisions of a standard, and a mapping that has fallen out of date against its upstream is worse than no mapping, because it invites a reader to trust a claim nobody has rechecked.
The gaps are documented rather than papered over. Training data quality, model lifecycle management, and AI supply chain security sit outside GATE’s scope, and the AISVS mapping says so. The June roadmap named these gaps as model evaluation, training data quality, and AI supply chain security; AISVS 1.0 organises the model-evaluation territory under model lifecycle management, and the mapping follows the published chapter names. The ATLAS mapping lists the techniques the framework does not address: the model interior is not a control-plane problem, and mapping to ATLAS does not make it one.
These mappings are informative. Passing GATE conformance does not imply conformance with AISVS, coverage of ATLAS, or certification against ISO/IEC 42001 or any other standard. They exist so an implementation team can trace a control to the requirement a reviewer will ask about. That is the whole purpose.
gate-rust v1.0.0
The Python library is the reference implementation and the right tool for prototyping gateways and building compliance tooling. It is the wrong tool for a high-throughput Tool Gateway written in Rust, where allocation patterns matter and Python interop adds latency.
gate-rust covers the primitives that have to be fast: canonical JSON, envelope construction, the hash-chained ledger, and ES256 signing and verification. The hash compatibility guarantee is the primary contract. gate-rust and gate-python must produce identical hashes for identical inputs, enforced by shared test vectors and a CI digest lockstep in both repositories. A single failing vector means the implementations disagree and both are wrong until one is fixed.
gate-rust covers the fast primitives only. Replay recording, schema validation, and the higher-level orchestration stay in Python where they make more sense. Neither library is on a package registry yet. v1.4 defers crates.io publication, so gate-rust installs from a tagged git ref (cargo add gate-rust --git https://github.com/deterministic-agents/gate-rust --tag v1.0.0), and gate-python publication to PyPI is a v1.5 item. Minimum supported Rust version is 1.78.
gate-fuzz v1.0.0
The v1.4 release ships one of three gate-fuzz deliverables originally scoped for the release. What lands is the Python-to-Rust differential harness that enforces byte equivalence between the two implementations at canonical-JSON, signing, and schema-validation layers. The other two deliverables - the bundle-derived Hypothesis strategy generator and the HTTP-level protocol fuzzer against a running Tool Gateway - move to v1.5. Naming the deferred items in the same release where the differential harness ships keeps the roadmap honest against what practitioners find when they clone the repo.
gate-knowledge v1.0.0
Google Cloud published Open Knowledge Format v0.1 in June, an open specification for representing curated knowledge as a directory of markdown files with YAML frontmatter, where concepts link to each other with ordinary markdown links and the only required field is type (McVeety and Hormati, 2026). It defines a file layout and nothing else. There is no SDK to install and nothing to run as a service.
GATE has the problem OKF was designed for. The control catalogue, the threat model, and the ABOM are all structured knowledge, and until now they lived as YAML, PDF, and HTML. An agent building a GATE-conformant system had to fetch several documents from several sources and assemble the picture itself.
gate-knowledge publishes the conceptual layer as an OKF v0.1 bundle: 20 control documents, the threat model, the adoption path, an ABOM template a team can fork and populate, typed relationship links between concepts, and a custom validator. The relationship links are the point. C17 links to C04 because discovery feeds the commission lifecycle. C09 links to C05 because invariants evaluate after policy. C19 links to C16 because they address different failure modes at the same tier and must not be merged. An agent navigating the bundle can understand a control’s dependency surface before implementing it, without reading the full paper.
The bundle is the conceptual layer only. gate-contracts remains the normative schema source and gate-conformance remains the check source; nothing in gate-knowledge is authoritative over either.
Conformance runner v1.3.0
Check20 joins the suite for the new control. Check17 and Check18 move from PARTIAL to AUTOMATED when bundle stores are configured. A default configuration now returns 9 AUTOMATED and 11 PARTIAL results; a configured one returns 11 and 9. PARTIAL remains a statement about what the runner can see, not a failure: the report names the specific artefact each PARTIAL check still needs from the operator.
What is published in v1.4
gate-contracts v1.2.0 carries the normative JSON Schema definitions, extended with the C20 output classification event, the break-glass record, the auto-enrolment policy, and the approved feed registry.
gate-policies v1.2.0 carries the OPA/Rego policy and invariant bundles, adding C20 output classification with a fail-closed guardrail, C09 break-glass verification, the C17 auto-enrolment fast-path, and an explicit bundle manifest.
gate-python v1.2.0 remains the reference implementation, adding the C20 output module, break-glass verification, strict canonical-JSON hashing, and the cross-language test vectors gate-rust builds against.
gate-conformance v1.3.0 carries the twenty checks, the report template, the runbooks, the runner, and the three new machine-validated mappings.
gate-rust v1.0.0, gate-fuzz v1.0.0, and gate-knowledge v1.0.0 are the three new repositories, described above.
The framework paper source is public at gate-framework-paper, so the Quarto sources, control specifications, and diagram sources are now readable and forkable alongside the published PDF.
What v1.5 picks up
The June roadmap scoped gate-fuzz around PARTIAL closure: a README mapping each test to the conformance check it closes, and a suite that converts PARTIAL results into verifiable PASS results. That mapping arrives with the two deferred deliverables in v1.5, so the runner counts above stand until that mapping lands.
Alongside them, the paper’s known issues section names five more: streaming-aware C20 classification, where a response is classified before it is fully formed; a unified exception register, meaning one exception_record contract for the exception surface that C09 break-glass and the C17, C18, and C19 policies all consume; a multi-approver HITL record, so approvals that need more than one approver are carried by the HITL record itself rather than borrowed from the break-glass path; gate-python publication to PyPI; and a gate-rust conformance bridge so the crate can produce runner-compatible evidence directly.
That is what v1.5 is scoped around, written down now for the same reason the June roadmap was. If you are building agentic AI infrastructure, deploying agents in a regulated environment, or advising organisations on AI governance, the issues and discussions on each repository are open. A bug report from someone who tried to implement a control is worth more to me than a comment on the paper.
GATE is published at deterministicagents.ai under CC BY 4.0 for the documentation and MIT for the code. The strategic companion to this framework is the Trustworthy Agentic AI Blueprint, co-authored with Sakura Sky.
Disclosure: GATE is authored and maintained by me personally rather than by Sakura Sky, and there is no paid tier, hosted version, or commercial product built on it. Agent governance is also my day job at Sakura Sky, which is a commercial interest worth stating. The standard mappings described here are informative and were validated against pinned upstream snapshots rather than assessed by a third party.
References
McVeety, S. and Hormati, A. (2026) Introducing the Open Knowledge Format, Google Cloud Blog, 12 June. Available at: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing (Accessed: 18 August 2026).
MITRE (2026) MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. Available at: https://atlas.mitre.org/ (Accessed: 18 August 2026).
OWASP (2026) Artificial Intelligence Security Verification Standard (AISVS) 1.0, released 24 June. OWASP Foundation. Available at: https://owasp.org/www-project-artificial-intelligence-security-verification-standard-aisvs-docs/ (Accessed: 18 August 2026).
Souppaya, M., Scarfone, K. and Dodson, D. (2022) Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, NIST SP 800-218. National Institute of Standards and Technology. Available at: https://csrc.nist.gov/pubs/sp/800/218/final (Accessed: 18 August 2026).
Stevens, A. (2026) Governed Agent Trust Environment (GATE) v1.4. Available at: https://github.com/deterministic-agents/gate/releases/tag/v1.4 (Accessed: 18 August 2026).