Day 5 · Lesson 4 — Spec-Driven Production Development

Zero-Trust Development: The Safety Net

An agent optimises for its goal with whatever it can find, unless something stops it.

A single prompt to "create a button" once sent fifty colleagues false emails: in auto-approve mode the browser agent clicked it, hallucinated a URL, and connected to a deprecated email agent with no safeguards. That's the whole lesson in one story: without a guardrail, an agent fulfils its goal using whatever it can find, never asking whether it should.

Why guardrails aren't optional

The paradox: agents must be autonomous enough to solve real problems, but can't be allowed to go rogue. Because LLMs are probabilistic, not deterministic, constraints baked into a system prompt are brittle: contexts overflow, and agents get talked past their rules by prompt injection. Production-grade platforms need external, tamper-proof governance.¹ Four layers make up the net.

1 · Sandboxing — contain the blast radius

Execute agent tasks in ephemeral, low-privilege containers isolated from the network and sensitive files. If the agent is tricked into a destructive command, the damage is confined to a disposable instance that hits a hard kernel-level permission error, and the host stays untouched.¹ (Day 4's Pillar 1, one toggle away.)

2 · Human-in-the-loop — the fail-safe on high-stakes actions

Checkpoint gates for actions with a specific risk profile: deploying to prod, modifying schemas, initiating transactions. The agent's sanitized intent is presented to a human for sign-off, so final responsibility for architectural integrity stays in human hands.¹

3 · The Policy Server — the intelligent referee

The centerpiece: intercept every action before it hits an external system, in two layers:¹

STRUCTURAL GATING (traffic lights) — deterministic role/env rules, fast + binary
   e.g. a "viewer" role cannot call send_email       (defined in policies.yaml)

SEMANTIC GATING  (intelligent referee) — a second LLM inspects INTENT + content
   e.g. an admin MAY use send_email, but MUST NOT send unmasked PII
   (you can't regex every possible leak — so a model judges the intent)

The flow: structural check (YAML) → semantic check (ask Gemini) → execute, or return a "Policy Violation" the agent can self-correct against. Its deepest idea: separate execution logic from governance logic, a critical separation of concerns for enterprise software.

4 · Context hygiene — sterilize the inputs

The "context hallucination" risk: lacking data, an agent fills gaps with whatever strings are in context: hardcoded emails, private URLs. Middleware masks PII and injects placeholders ([[COMMENTER_EMAIL]] resolved at runtime), so the agent operates on sterilized data and never hardcodes real PII.¹

Plus the quality net: AI-generated test coverage (make the agent write a failing test before any fix, keep it in the codebase) and evaluation, because "tests catch deterministic regressions; evaluation catches behavioural drift." That single line ties Day 1, Day 4, and Day 5 together.

The governance layer — Day 5 lands on VERDICT

Through your three lenses

Check the reflex

Recall, don't re-read.

Go deeper (primary source)

Spec-Driven Production Grade Development (Day 5), "Zero-Trust Development", "Implementing Guardrails", "Policy Server", "Context Hygiene" pp.26–34; the deeper security treatment is Day 4.

---

Notes

1. Boonstra, Spec-Driven Production Grade Development (Day 5), pp.26–34 (the incident; guardrails; sandboxing; HITL; the hybrid Policy Server; AI test coverage; evaluation; context hygiene).