GATE v1.4 Roadmap

GATE v1.3 closed three assumptions in v1.2.8:

1. that your agent estate is fully enrolled,
2. that retrieved content is usable,
3. and that your model is stable.

The conformance runner turned 9 of the 19 checks into automatable queries. Those were the right things to do first.

v1.4 builds on them. Here is what is coming.

A new control: output validation

GATE currently governs what agents do at the tool boundary and what they retrieve at the memory boundary. It does not govern what they say at the output boundary - the final response delivered to a user or downstream system.

For most deployments today that gap is acceptable. For regulated deployments in healthcare, legal, financial advice, and HR decision support it is not. These environments have obligations around what can be delivered, to whom, and under what review conditions, that are as real as their obligations around what an agent can execute.

C20 Agent-to-human output validation closes this gap. It sits in Layer 3 alongside C13 (intent telemetry) and C19 (drift monitoring). The control covers output classification at delivery time - sensitivity tier, regulated content category, confidence scoring on the final response - mandatory human review gates for configured categories, and output redaction obligations. An output_classification_event is emitted per final response, giving the same evidence coverage at the output boundary that tool envelopes give at the tool boundary.

This brings the control count to 20. It also completes the boundary model: identity at instantiation, policy at execution, observation throughout, and classification at delivery.

Formalising break-glass

The C09 break-glass override has always required a signed record and dual approval. What it has not had is a machine-verifiable format. The record currently lives as a narrative document linked to a ledger event by convention, not by schema.

v1.4 adds break_glass_record.schema.json to gate-contracts. The invariant halt ledger event will reference a valid break_glass_record_id when an override was authorised. The gate-conformance runner will be able to verify that every invariant halt either has an associated valid break-glass record or was not overridden - a distinction that currently requires manual audit.

This is a tightening, not a new control. C09 stays as C09. The semantics do not change. What changes is that the paper trail becomes a verifiable data structure rather than an attached document.

Standards: OWASP AISVS and MITRE ATLAS

The GATE standard mappings currently cover NIST AI RMF, ISO/IEC 42001, EU AI Act, DORA, and HIPAA. v1.4 adds two more.

OWASP AISVS (AI Security Verification Standard) is the most directly implementable standard for the GATE audience. Its verification requirements map naturally to the conformance check model. The v1.4 work produces a full mapping in gate-conformance/mappings/owasp-aisvs.yaml and an honest assessment of where GATE leaves AISVS requirements unaddressed - model evaluation, training data quality, and AI supply chain security are real gaps that the mapping will document rather than paper over.

MITRE ATLAS is to AI systems what ATT&CK is to traditional infrastructure. C16 (Continuous Adversarial Validation) currently specifies a CI harness without reference to a technique taxonomy. The v1.4 work maps C16’s required test scenarios to ATLAS tactics and techniques, giving implementation teams a concrete threat model to work from rather than a list of categories. The mapping will also make explicit which ATLAS techniques sit outside GATE’s scope - model-level attacks and training data poisoning are not control-plane problems.

A Rust library

The Python library is the reference implementation. It is the right tool for teams prototyping gateways and building compliance tooling. It is not the right tool for teams building high-throughput Tool Gateways in Rust where allocation patterns matter and Python interop adds latency.

gate-rust provides canonical JSON serialisation and SHA-256 hashing, tool envelope builders, hash-chained ledger event construction, 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. A shared test vector file enforces this at CI time. A single failing vector means the implementations are incompatible and both are wrong until one of them is fixed.

This is a foundational layer, not a full port of the Python library. The gate-python library covers replay recording, schema validation, and higher- level orchestration that makes more sense in Python. gate-rust covers the primitives that need to be fast and allocation-conscious.

A fuzzing suite

The conformance runner marks 10 checks PARTIAL. Some of those checks can only be closed by executing test scenarios that a query tool cannot perform: schema boundary fuzzing, invariant boundary verification, protocol mutation testing on the tool gateway surface.

gate-fuzz formalises this as a first-class deliverable. It contains Hypothesis-based property tests that derive test cases directly from the signed invariant bundle - so a passing test suite is evidence of your bundle correctness, not just test harness correctness - and an HTTP-level protocol fuzzer that sends mutation variants to a running Tool Gateway and flags any response that is not a schema rejection or a policy denial.

The README maps each test in gate-fuzz to the PARTIAL check it closes in the conformance runner. The goal is that running gate-fuzz alongside the runner converts the maximum number of PARTIAL results to verifiable PASS results, leaving only the checks that require genuine human judgement - controlled drills, process inspections, runbook sign-offs - in PARTIAL status.

A knowledge bundle in Open Knowledge Format

Google Cloud published Open Knowledge Format (OKF) v0.1 in June 2026. The spec is deliberately minimal: a directory of markdown files with YAML frontmatter, where each file represents a concept, files link to each other with normal markdown links, and the only required field is type. No SDK, no proprietary runtime, no new service.

GATE has a knowledge problem OKF is designed for. The control catalog is structured knowledge. The ABOM is structured knowledge. The threat model is structured knowledge. All of it currently lives as YAML, PDF, and HTML. None of it is navigable by an agent building a GATE-conformant system without fetching multiple documents from multiple sources and assembling the picture.

gate-knowledge publishes the GATE conceptual layer as an OKF bundle: one markdown file per control, one per threat model component, one per adoption path phase, plus ABOM templates a team can fork and populate for their own deployment. Each control document links to the controls it depends on, the controls it extends, and the controls it must be kept distinct from.

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 gate-knowledge understands the dependency surface of a control before implementing it, without reading a 130-page PDF.

gate-knowledge is not a replacement for gate-contracts (schemas) or gate-conformance (checks). It is the layer that makes the framework comprehensible to an agent working from files.

Timeline

v1.4 is in planning now. The framework paper update comes first, then the repos in dependency order. When it ships, the conformance runner will be updated alongside it - Check17 and Check18 gain a path to full automation when a bundle store URI is configured, and Check20 joins the check suite.

If you are building agentic AI infrastructure and any of the above addresses a gap you have hit in practice, the issues and discussions at github.com/deterministic-agents are the right place to say so before the spec is locked.

Andrew Stevens is Co-Founder of Sakura Sky. GATE is published at deterministicagents.ai. The strategic companion to this framework is the Trustworthy Agentic AI Blueprint, co-authored with Sakura Sky.