Reference · The Governance Layer (overlaid on every lesson)
The second axis the build dial can't see: runtime governance.
The Google series teaches a build dial (vibe → structured → agentic) that answers "is the output verified before it ships?" It is silent on a second question that decides whether an agent is safe in the real world: "while it runs, can we see it, stop it, and name who owns it?" That is governance, and it is a separate axis. This card is the canonical reference; lessons cite it.
A task or agent has a coordinate on both axes. They move independently, which is the whole point. Tests and evals (build) do nothing to stop a runaway agent at 3am; a kill-switch (governance) does nothing to make the output correct.
| Governance ↓ / Build → | Vibe | Structured | Agentic |
|---|---|---|---|
| L4 Autonomous 🖥 | target | ||
| L3 Controlled 🔒 | ok | production-ready | |
| L2 Observed 👁 | tested but un-governed | ||
| L1 Unseen 👻 | shadow agent | silent time-bomb |
The danger isn't only bottom-left. Agentic × Unseen (bottom-right) is a perfectly-tested agent nobody knows is running, arguably the most dangerous cell.
Move verification out of your head into artifacts: detailed prompts → tests (deterministic) → evals with rubrics (non-deterministic) → specs + CI gates. See Lesson 1 and test vs eval.
A runtime governance operating model from Niharika Srivastav & Sanjay Saxena ("not a checklist, a repeatable operating model"). "VERDICT doesn't prevent AI. It prevents AI from going unchecked."★
| — | Pillar | Problem it fixes | Control |
|---|---|---|---|
| V | Validation | Agents execute unapproved actions | Pre-execution validation gates |
| E | Evidence | No audit trail | Immutable timestamped action logs |
| R | Runtime Control | Governance only pre-deployment | Kill-switch + live policy enforcement |
| D | Decisions | No explainability | Decision logging with reasoning |
| I | Identity | No accountability | Agent identity registry + human owners |
| C | Cost & Compliance | Unchecked spend + regulation | Spend caps + regulatory guardrails |
| T | Transparency | Black-box operation | Real-time dashboards + reporting |
Why runtime, not just pre-deployment review? "Traditional governance was designed for humans, who operate slowly and within org charts. Agents act faster than review cycles, don't follow org charts, and don't ask permission." The Knight Capital incident took 45 minutes; a broad-permission agent does equivalent damage in seconds.
And the climb is sequential: EXPOSE (discover every agent, map risk) → BIND (give each an identity + owner + validation gates) → ENFORCE (deploy the runtime control layer + logging) → SELF-GOVERN (continuous monitoring, agents watching agents). You cannot BIND what you haven't EXPOSEd.
| Day / topic | Governance touchpoint | Pillars / phase |
|---|---|---|
| 1 · Spectrum & Harness | The harness's guardrails/hooks and observability are build-time seeds of governance; VERDICT extends them to runtime. The org lens = the maturity ladder. | VER · EXPOSE |
| 2 · Tools & MCP | Every tool call is what validation gates and spend caps govern. The confused-deputy problem is an Identity/accountability failure. | VIC · BIND |
| 3 · Sessions & Memory | Session events are the substrate for immutable logs and decision reasoning; memory governance = what an agent may persist. | EDC |
| 4 · Security & Evaluation | Densest overlap: Google's 7-pillar security ≈ VERDICT's 7 pillars; intent-drift / trust-decay is the case for runtime control + transparency. Evals are validation evidence. | all 7 · ENFORCE |
| 5 · Spec-Driven Production | Zero-trust agent dev = Identity + Validation; spec files are where governance policy is declared (BIND); the production target is ladder Level 3. | IVT · ENFORCE→SELF-GOVERN |
Day 4's whitepaper reaches the governance framework from the security side. The two are two vocabularies for one trust surface: Google leads with where controls live (infra→governance), VERDICT with what is enforced at runtime. Both assert the same thing: trust is continuously earned, not granted once ("Effective Trust" = "prevents AI from going unchecked").
| Google pillar | Focus | ≈ VERDICT |
|---|---|---|
| 1 Infrastructure & Networking | ephemeral sandbox, egress | R containment |
| 2 Data | CMEK/mTLS, tenant partitioning, least-priv | C + I scoped access |
| 3 Model | protect instructions, semantic attacks | V input validation |
| 4 Application & Runtime | LLM firewall, hooks, gateway | V + R gates & kill |
| 5 Identity & Access | SPIFFE, ABAC, JIT, confused deputy | I Identity |
| 6 Observability & SecOps | Red/Blue/Green, drift, circuit breaker | E + R |
| 7 Governance | audit trail, attestation, EU AI Act, logic reviews | T + D + C |
And the second axis: Day 4's evaluation framework (7 quality dimensions) is V Validation of value, the twin of security's Validation of safety. Source: Kartakis, Eidelman, Bakkali & Subasioglu, Day 4 pp.9–11.
★ Source: Niharika Srivastav & Sanjay Saxena, "7 Steps to Govern AI Agents" (Maven live session, 2026-05-24), captured from that session. Confidence on the source: medium (single session), treat the shape as the durable contribution, refine specifics as you find corroborating sources.