The Regulatory Stack, Part 1: AISVS Has 14 Categories. GATE Has 16 Controls. Here Is the Map.

AISVS tells you what to verify. The AI Act tells you that you must. Neither tells you how to enforce. This is the engineering map.

Disclosure: The author is a lifetime member of the OWASP Foundation. This article reflects an independent reading of public OWASP material and does not represent the views of the Foundation.

Disclosure: Sakura Sky implements the Governed Agent Trust Environment (GATE) in client engagements. GATE is an open framework, published under CC BY 4.0 at deterministicagents.ai, and is vendor-neutral. The framework was authored by Andrew Stevens; readers should weight the GATE references in this article accordingly.

The verification gap

The current regulatory stack for AI security is missing its middle layer.

The EU AI Act tells you that high-risk systems must implement a risk management system, cybersecurity controls, and post-market monitoring (European Parliament and Council, 2024, Articles 9, 15, and 72). The NIST AI Risk Management Framework’s Generative AI Profile gives you a taxonomy of risks and a set of governance functions (NIST, 2024). Both tell you, in effect, that you must verify.

OWASP’s Artificial Intelligence Security Verification Standard (AISVS) tells you what to verify. Fourteen control categories, three verification levels, modelled directly on the long-established ASVS programme (OWASP Foundation, n.d.).

Neither tier tells you how to enforce any of it at runtime. That is the engineering work, and it is where most agentic-AI deployments fall apart.

A crash is not an exploit. A policy document is not a control. A NIST mapping is not an enforcement boundary. The reason agentic systems are difficult to govern is that the model itself is probabilistic and the actions it takes are real. You cannot verify a stochastic system by running a checklist over it. You verify it by wrapping it in a deterministic shell and proving that the shell holds under adversarial conditions.

That shell needs an architecture. This article is the map between the AISVS categories that name the verification work and the architectural primitives that actually do it.

AISVS in brief

AISVS is currently an Incubator project at version 0.1, in Phase 2 of a five-phase roadmap toward a 1.0 publication (OWASP Foundation, n.d.). That is the honest engineering status. The fourteen categories are stable enough to design against; the requirement-level wording inside each category is still moving.

The categories, in the order OWASP publishes them, are:

• C01 Training Data Governance and Bias Management
• C03 Model Lifecycle Management and Change Control
• C04 Infrastructure, Configuration and Deployment Security
• C05 Access Control and Identity
• C02 User Input Validation
• C06 Supply Chain Security for Models, Frameworks and Data
• C07 Model Behaviour, Output Control and Safety Assurance
• C08 Memory, Embeddings and Vector Database Security
• C09 Autonomous Orchestration and Agentic Action Security
• C10 MCP Security. C11 Adversarial Robustness and Attack Resistance
• C12 Privacy Protection and Personal Data Management
• C13 Monitoring, Logging and Anomaly Detection
• C14 Human Oversight and Trust.

Three of those categories are doing most of the load-bearing work for any team running agentic systems:

1. C08 (memory and vector databases),
2. C09 (autonomous orchestration),
3. and C10 (MCP).

The rest matter, but those three are where current production failures cluster.

GATE in brief

GATE is an open control-plane framework that defines sixteen controls across four layers:

1. Identity and Integrity (C01–C04),
2. Runtime Enforcement (C05–C09),
3. Observability and Forensics (C10–C13), and
4. Orchestration and Ecosystem (C14–C16).

It is published under CC BY 4.0 at deterministicagents.ai with reference implementations in JSON Schema, OPA/Rego, and Python (Stevens, n.d.a; Stevens, n.d.b).

GATE’s core invariant is one sentence:

Agent runtimes never call tools or memory directly. All side effects traverse deterministic enforcement points that authenticate, authorise, constrain, and record every action.

That is the architectural difference between an agent that can be governed and one that cannot. Most production agentic deployments today fail this invariant by default. The model holds the credentials, calls the tools, and writes to memory directly. There is no intercept point. There is therefore nothing to verify.

GATE is currently at version 1.2.8 with stable v1.0.0 contract, policy, and reference-library releases (Stevens, n.d.a). It maps explicitly to NIST AI RMF and ISO/IEC 42001 in its control catalog (Stevens, n.d.c).

The map

The AISVS categories tell you what verification work needs doing. The GATE controls tell you what enforcement primitives that work runs on. Below is the mapping.

Two things to read out of this table:

1. The first is that AISVS C09 (Autonomous Orchestration) and C10 (MCP) collapse onto GATE’s Tool Gateway as their primary enforcement point. If your agentic system does not have a deterministic Tool Gateway between the model and its actions, no AISVS verification at level 2 or above is realistically achievable for those categories. You cannot verify what you cannot intercept.
2. The second is that AISVS C13 (Monitoring, Logging and Anomaly Detection) maps onto GATE’s observability primitives at C10–C13: the audit ledger, the replay trace, and the evidence pipeline. Verification at that category level requires more than logs. It requires a hash-chained, tamper-evident, deterministically replayable evidence chain. Most organisations have logs. Very few have evidence. The two are not the same artefact.

What the open verification chain looks like

GATE makes the AISVS C13 verification work concrete by specifying a chain of hashes that runs through every agent action. From the gate-contracts canonical schema (Stevens, n.d.c):

ToolRequest.request_hash
  → PolicyDecision.inputs.request_hash
  → LedgerEvent.references.tool_request_hash
  → ReplayTrace step.request_hash

Every contract event carries correlation IDs (run_id, trace_id, agent_instance_id, tenant_id), bundle hashes (policy_bundle_hash, tool_schema_hash, prompt_bundle_hash), and payload hashes (request_hash, response_hash) computed over RFC 8785 canonical JSON. Any break in the chain is detectable during conformance verification.

This is what AISVS C13 looks like at Level 2 or Level 3 verification, expressed as a working architecture rather than a control description. It is also why C13 carries the load for several of the other categories. An evidence chain that cannot be tampered with retroactively is the property that makes verification of C01, C03, C09 and C14 meaningful at audit time.

Where Sentinel fits

A verification standard and a control-plane framework get you the architecture. They do not, on their own, run.

This is where Sakura Sentinel sits. Sentinel is the AI and data security governance framework Sakura runs on top of an Enclave-built cloud foundation: static analysis on code and dependencies, data fingerprinting for lineage and integrity, AI/ML model drift detection, agentic AI runtime governance with policy-as-code enforcement, and immutable audit trails. It is the operational layer where the AISVS categories become a continuously-running verification cycle rather than an audit artefact.

Concretely: Sentinel’s runtime governance for agentic AI implements the GATE C05/C09 enforcement boundary as a deployable policy-as-code surface against your live agents, with the audit ledger feeding back into the AISVS C13 verification work. The data fingerprinting closes the C01/C12 loop, and the drift detection closes the C03 loop. Sentinel is not a substitute for AISVS verification. It is what AISVS verification looks like once it is wired into a delivery pipeline as enforced controls rather than as a checklist.

The caveats

Three things worth saying out loud.

1. AISVS is at v0.1, Incubator status. The mapping above reflects the current public categories. When AISVS reaches 1.0, the requirement-level wording inside each category will move and parts of this map will need revisiting. That is a feature of working with an in-flight standard, not an excuse to wait.
2. GATE is at v1.2.8, with stable v1.0.0 reference implementations. Adoption beyond Sakura’s own engagements is still small. The framework is sound, the contracts are stable, but the broad ecosystem of conformant tooling is not yet there. If your production timeline depends on a third party’s GATE implementation, plan for in-house build.
3. Mapping AISVS to any control-plane framework, including GATE, is a design exercise, not a compliance exercise. The categories overlap, the levels are not all binary, and a number of AISVS requirements (especially in C07 and C11) require capability that no current framework, including GATE, fully discharges. The map points the work at the right primitives. It does not absolve the work.

The Sakura position

The verification gap between regulators saying “you must verify” and engineers shipping agentic systems is the defining technical problem of the next two years. AISVS is the most credible attempt to fill the middle layer. GATE is the most direct path from those categories to a working enforcement architecture.

What to do about it, in order:

1. Run an AISVS self-assessment against your current agentic systems. The fourteen categories are stable enough at v0.1 to give you a real signal on where the gaps are, and the verification levels give you a defensible target.
2. Audit your architecture against the GATE core invariant. Either every tool call traverses a deterministic enforcement point, or it does not. There is no third state. If your answer is “it does, mostly,” your answer is “it does not.”
3. Wire the evidence chain. The hash-chained ledger and replay trace are the parts that look like overengineering until your first incident or your first audit, after which they are the only artefacts that matter.

You cannot verify what you cannot intercept. The control catalog points the work. The Tool Gateway does it.

If you want a structured read on how AISVS, GATE, and your current architecture line up against each other, that is the kind of conversation we have most weeks. The strategic case and four-layer architecture are in the Trustworthy Agentic AI Blueprint; the engineering reference is the GATE framework paper at deterministicagents.ai. Either way, get in touch.

This article is part one of the Regulatory Stack series. The series builds on the prior reading of OWASP’s strategic plan: OWASP Just Drew a New Map. Read It Before Your Auditors Do.

References

European Parliament and Council, 2024. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L 2024/1689, 12 July. Available at: https://eur-lex.europa.eu/eli/reg/2024/1689/oj [Accessed 7 May 2026].

National Institute of Standards and Technology (NIST), 2024. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Gaithersburg, MD: U.S. Department of Commerce. Available at: https://doi.org/10.6028/NIST.AI.600-1 [Accessed 7 May 2026].

OWASP Foundation, n.d. OWASP Artificial Intelligence Security Verification Standard (AISVS), Version 0.1 (Incubator). Available at: https://owasp.org/www-project-artificial-intelligence-security-verification-standard-aisvs-docs/ [Accessed 7 May 2026]. Source repository available at: https://github.com/OWASP/AISVS [Accessed 7 May 2026].

Stevens, A., n.d.a. GATE — Governed Agent Trust Environment, v1.2.8 framework paper. Deterministic Agents. Available at: https://deterministicagents.ai [Accessed 7 May 2026]. Source repository available at: https://github.com/deterministic-agents/gate [Accessed 7 May 2026].

Stevens, A., n.d.b. gate-python — GATE Python reference library, v1.0.0. Available at: https://github.com/deterministic-agents/gate-python [Accessed 7 May 2026].

Stevens, A., n.d.c. gate-contracts — GATE JSON Schema contracts, v1.0.0. Available at: https://github.com/deterministic-agents/gate-contracts [Accessed 7 May 2026].