How the governance layer is being built

The groundwork post on governance and human-in-the-loop covers the controls; this is the who's-building-it view, as of June 2026. The disclosure at the close is part of how to read it.

Governance is the layer where regulation, not vendors, is the prime mover. The standards and the law are well ahead of the tooling, which is unusual, and it shapes everything about how this layer is being built: people are implementing to a regulatory target before a mature product market exists.

The standards and regulation come first

• ISO/IEC 42001 is the AI management-system standard, the governance spine, with NIST's AI Risk Management Framework alongside it.
• The EU AI Act is the forcing function: Article 12 requires high-risk systems to keep automatic logs (the logging capability), Article 26 puts the at-least-six-months retention duty on deployers, and Article 9 frames risk management as a continuous duty.
• The AWS Agentic AI Security Scoping Matrix tiers agent risk by level of agency; CSA MAESTRO is the multi-agent threat lens; OIDC/CIBA (Client-Initiated Backchannel Authentication) supplies the separate-channel authentication step in an out-of-band approval flow; the application still has to decide which action needs approval, bind the approval to the exact action, show independent transaction facts, and enforce the hard stop.

Who is building what, by control

Hard-stop on irreversible actions (GV-01). Microsoft's open-source Agent Governance Toolkit enforces approval gates; Okta (Auth0's async approval) carries the out-of-band human-approval flow.

Immutable audit trail (GV-02). I found relevant components, provenance work from Google/DeepMind [research] and data-governance logging in Databricks' Unity Catalog [shipping product], but no mapped implementation that demonstrates the full GV-02 mechanism: append-only, tamper-evident, agent-event integrity, held outside the agent's own trust boundary. This is where the EU AI Act Article 12 obligation lands hardest, so expect movement.

Policy-as-code (GV-04). Microsoft's Agent Governance Toolkit is an open-source runtime policy engine that, by Microsoft's own account, maps all ten OWASP agentic risks to deterministic, sub-millisecond enforcement (that figure is Microsoft's claim, not independently evaluated here, and the test conditions are worth checking against the primary source). An open-source engine in the request path is a notable shift for a layer that has lived mostly in documents. Keep the topology in mind, though: sub-millisecond enforcement implies localized policy or regex evaluation in-process, not secondary model lookups or network hops.

Multi-agent authority (GV-03). I found no mapped implementation that defines per-agent decision rights, conflict resolution, or stop conditions [no mapped implementation]. DASF catalogs the multi-agent risk, but cataloging a risk is not enforcing authority over it.

Where there is no product yet

This layer has the most "framework-level" controls of any: tiering by autonomy (GV-05) rests on ISO 42001 and the AWS matrix rather than a product; velocity caps on irreversible actions (GV-06), transactional high-impact actions (GV-08), human-deception protection (GV-07), and named-business-owner accountability (GV-09) are largely standards, process, and, in two cases, this project's own theses. Governance is the layer you most have to operate, not buy.

Where implementation activity is concentrated

Two different mechanisms are worth keeping apart here. Microsoft's open-source governance toolkit moves policy into enforceable, in-path code (a runtime engine). Databricks' DASF v3.0 is a risk-and-control framework, a catalog and mapping, not an in-path engine. Same broad direction, governance expressed as something executable and evidenced rather than only documented, but they are not the same kind of artifact. Whom that shift advantages commercially is not something this map judges.

Consolidating or fragmenting?

Consolidating around the standards and the law, fragmented in tooling. ISO/IEC 42001 and the EU AI Act are the prominent reference points in the mapped corpus, though the former is voluntary and the latter's applicability varies by system and jurisdiction. But the controls that turn that spine into enforced behavior are mostly early open-source or not-yet-built. The stable reference points are ISO/IEC 42001 and the EU AI Act; the tooling around them is a fast-moving, partly-open market.

The handoff

Governance tooling, open and proprietary, can express and enforce policy. The seam is whether a runtime detection from a different vendor can actually trip that enforcement before an irreversible action commits. Policy engines on one side, detectors on the other, and the integration between them unowned. That is the runtime-to-governance handoff, seen from the governance side.

See the governance groundwork post for the controls and validation steps, and see the governance-related controls at apeiris.ai.

Sources

• ISO/IEC 42001 · EU AI Act Article 12 and Article 9 · AWS Agentic AI Security Scoping Matrix · CSA MAESTRO
• Microsoft, Agent Governance Toolkit · Databricks, AI Security Framework (DASF) v3.0 · Google DeepMind, AI Control Roadmap · OIDC CIBA
• CSA + Strata Identity, Securing Autonomous AI Agents (2026 survey)

---

How to read this. Snapshot dated 21 June 2026. A product appears here because it maps to a control, not as a recommendation or independently validated efficacy; vendor figures are their own claims; status tags mark what kind of thing each entry is. The full neutrality statement and method are in the capstone.