release: v0.8.0

Author: onesimplecode

AGENTS.md

@@ -254,6 +254,57 @@ present field is not, and the two must not be handled by the same fallback
 path. See `examples/strict-output-schema/` for a before/after reference
 implementation and a live repro of the `bool("false")` bug.
 
+### Compartmentalized Multi-Agent Isolation (TR-SEC-013)
+
+When multiple agents share one backing service — a tool surface and the data
+behind it — isolate them at **two independent layers**, not one:
+
+1. **Tool-registry / authorization scope** — a distinct credential per agent,
+   with the server (not the agent) deciding which tools that credential may
+   invoke. This bounds what is *offered* to a given agent's own reasoning.
+2. **Data-layer scope** — a per-agent role on the underlying store (database
+   role, file-system mount, or equivalent), enforced independently of
+   whatever the authorization layer believes it has granted. This bounds
+   what is *reachable* even if layer 1 has a bug.
+
+Neither layer substitutes for the other. A tool-registry bug (a stray
+wildcard registration, a misrouted credential map) can hand an agent a tool
+it should never have gotten — the data-layer role is what still blocks the
+resulting call. A data layer with no tool-registry scope would still let a
+compromised or over-broad tool call reach everything a shared credential can
+see. Assign both layers by exposure: the agent with an external input path
+(internet, untrusted user messages) gets the narrowest grant at both layers;
+the most broadly-privileged agent gets no external egress at all. See
+`examples/compartmentalized-agents/` for a reference implementation,
+including a test that simulates a tool-registry bug and shows the data layer
+still holds the line.
+
+When reusing a prior isolation design (an existing threat model, a past ADR)
+for a new agent split, re-verify its *reasoning* still holds before carrying
+its conclusions forward — a control copied without re-checking why it existed
+can turn into process weight that closes no actual gap.
+
+### Ground-Truth Verification for Agent Security Claims (TR-TEST-007)
+
+An agent's own self-report is not verification evidence for a
+security-relevant property — isolation between agents, a permission
+boundary, memory or session scoping. Asking an agent in conversation ("do
+you have tool X," "do you remember Y") can produce a false pass: the
+question may be answered by the wrong backend, a stale cache, or the agent's
+own incorrect belief about its state, none of which is the property actually
+under test.
+
+Verify instead against the system's own ground truth — the target
+component's own list/read endpoint, a database row, a server log line —
+independent of what the agent under test reports. This is the
+security-property-specific form of the general "verify before referencing"
+discipline: the authoritative source for whether a boundary holds is the
+boundary's own enforcement point, never an agent's narration of it. See
+`examples/compartmentalized-agents/` for a reference implementation, where a
+`SelfReportingAgent`'s claim about its own tool access is shown to drift out
+of sync with the tool registry's actual state — the registry, not the
+agent's claim, is ground truth.
+
 ### Deterministic Checks Before Agent Judgment
 
 Use scripts, tests, linters, and schema validators before asking a model to

CHANGELOG.md

@@ -5,6 +5,45 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.8.0] - 2026-07-31
+
+### Added
+
+- `registry/tr-registry.yaml` — TR-SEC-013 (two-layer isolation for
+  multi-agent tool and data access) and TR-TEST-007 (agent security-property
+  claims verified against ground truth, not self-report), exported from the
+  private-repo agent-platform deployment (private ADR-013, ADR-014).
+  TR-SEC-013 graduates the "Compartmentalization worked example" item
+  roadmapped since the 2026-07-13 Zero-Trust-for-AI-Agents review (private
+  ADR-031), now backed by a running, hands-on-verified implementation rather
+  than a design-only ADR; TR-TEST-007 is new content, motivated by two real
+  false passes in the ADR-014 spike where an isolation/memory-scoping check
+  "passed" only because the question was answered by the wrong backend, not
+  the mechanism actually under test
+- `examples/compartmentalized-agents/` — reference implementation:
+  `ToolRegistry` (tool-registry scope) + `DataStore` (data-layer scope),
+  with a test that deliberately misconfigures the tool layer and proves the
+  data layer alone still blocks the resulting call (the defense-in-depth
+  evidence, not just that both layers exist); `SelfReportingAgent`, with a
+  test showing its self-report gives a false pass on a real isolation leak
+  that `ToolRegistry.list_tools()` (ground truth) catches
+- `docs/ai-engineering-operating-model.md` — "Rollout Sequencing" section
+  (the layering rule: foundational infrastructure ships first, every later
+  phase immediately usable on arrival), also graduated from the 2026-07-13
+  review, second exemplar from private ADR-013's phased rollout table
+- `templates/completion-checklist.md` — "Ground-truth verification for agent
+  security claims" checklist item
+- `AGENTS.md` — "Compartmentalized Multi-Agent Isolation" and "Ground-Truth
+  Verification for Agent Security Claims" sections
+- `docs/requirements-implementation-map.md` — rows for all three exports above
+- `README.md` — `examples/compartmentalized-agents/` added to the worked-traces
+  list and "Enforced workflow" section
+
+Reviewed by a fresh-context reviewer agent before release: 0 blocking
+findings, 2 advisory (the `README.md` gap above, and two added test cases
+for previously-untested `DataStore`/`ToolRegistry` default-permission edge
+cases) — both fixed prior to this release.
+
 ## [0.7.0] - 2026-07-26
 
 ### Added
@@ -265,7 +304,8 @@ Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 - `CONTRIBUTING.md`, `SECURITY.md`, issue/PR templates, `release-check` CI workflow
 - Roadmap and changelog for intentional release cadence
 
-[Unreleased]: https://github.com/onesimplecode/ai-engineering-standards/compare/v0.7.0...HEAD
+[Unreleased]: https://github.com/onesimplecode/ai-engineering-standards/compare/v0.8.0...HEAD
+[0.8.0]: https://github.com/onesimplecode/ai-engineering-standards/compare/v0.7.0...v0.8.0
 [0.7.0]: https://github.com/onesimplecode/ai-engineering-standards/compare/v0.6.0...v0.7.0
 [0.6.0]: https://github.com/onesimplecode/ai-engineering-standards/compare/v0.5.0...v0.6.0
 [0.5.0]: https://github.com/onesimplecode/ai-engineering-standards/compare/v0.4.0...v0.5.0

README.md

@@ -63,8 +63,9 @@ A step-by-step path for pulling these standards into your own repo, not just thi
 5. **Study the worked traces** — [`examples/worked-example/`](examples/worked-example/),
    [`examples/agent-permission-guard/`](examples/agent-permission-guard/),
    [`examples/spotlighting/`](examples/spotlighting/),
-   [`examples/provenance-trust-tags/`](examples/provenance-trust-tags/), and
-   [`examples/strict-output-schema/`](examples/strict-output-schema/) show
+   [`examples/provenance-trust-tags/`](examples/provenance-trust-tags/),
+   [`examples/strict-output-schema/`](examples/strict-output-schema/), and
+   [`examples/compartmentalized-agents/`](examples/compartmentalized-agents/) show
    a requirement moving end-to-end: TR-ID → ADR → maturity row → script → CI gate.
 6. **Reconcile with tools you already use** — [`docs/agent-skills-integration.md`](docs/agent-skills-integration.md)
    covers how this layers under AGENTS.md, agent-skills, and Cursor rules rather
@@ -100,6 +101,13 @@ from source type to trust level — and
 a live repro of the `bool("false") is True` fail-open coercion bug and the
 reject-never-coerce fix.
 
+See [`examples/compartmentalized-agents/`](examples/compartmentalized-agents/)
+for the two-layer multi-agent isolation trace (TR-SEC-013) — a simulated
+tool-registry misconfiguration that a per-agent data-layer role alone still
+blocks — and the ground-truth-vs-self-report trace (TR-TEST-007): an agent's
+own claim about its tool access shown giving a false pass that only the tool
+registry's actual state catches.
+
 ## Public Evidence Map
 
 - [`AGENTS.md`](AGENTS.md) — tool-neutral agent rules for data routing, loop contracts,

ROADMAP.md

@@ -92,13 +92,15 @@ See `CHANGELOG.md` for shipped versions.
       examples, `docs/agent-skills-integration.md`) consolidating onboarding
       guidance that was previously scattered across the README and `docs/`
 
-## v0.7 — Agentic security & operations patterns (current)
+## v0.7 — Agentic security & operations patterns
 
-From the 2026-07-13 Zero-Trust-for-AI-Agents review (private ADRs: private-repo
-ADR-030/031/032, private-repo ADR-018, and a private-repo deployment proposal). Two
-maturity classes — this repo exports packaged practice, not aspirations.
+Released 2026-07-26 (`v0.7.0`).
 
-**Export-ready (shipped + tested in the private monorepo, 2026-07-13):**
+From the 2026-07-13 Zero-Trust-for-AI-Agents review (private ADRs: private-repo
+ADR-030/031/032, private-repo ADR-018, and a private-repo deployment proposal).
+The review identified nine candidate exports; three were export-ready and
+shipped in this release, six were design-only and deferred — see v0.8 (two of
+the six, now with running evidence) and Backlog (the remaining four) below.
 
 - [x] **Spotlighting at the reasoning boundary** (private ADR-030,
       private ADR-018): untrusted retrieved/external content is wrapped in
@@ -121,9 +123,88 @@ maturity classes — this repo exports packaged practice, not aspirations.
       single-source-of-truth convention
       (TR-SEC-012, `examples/strict-output-schema/`)
 
-**Roadmapped — export after the private implementation proves them
-(design-stage as of 2026-07-13; promotion to export requires the same
-evidence TR-SEC-010 had — commits, tests, an operating track record):**
+## v0.8 — Verified isolation & ground-truth testing
+
+Released 2026-07-31 (`v0.8.0`).
+
+From a private-repo agent-platform deployment (private ADR-013, ADR-014;
+2026-07-25 to 2026-07-29) — the first case of a `compartmentalization`-shaped
+design (private ADR-031, v0.7's own roadmapped item above) actually built,
+running, and hands-on verified rather than design-only. Three exports, one of
+them genuinely new content rather than a graduation:
+
+- [x] **Compartmentalization worked example** (graduates from v0.7's
+      roadmapped item, private ADR-031 → private ADR-013/014). Two-layer
+      isolation for a multi-agent system sharing one backing service: a
+      tool-registry scope (what's *offered* to each agent's own reasoning —
+      distinct credentials per agent, server-side authorization) sitting
+      above a data-layer scope (what's *reachable* even if the authorization
+      layer has a bug — e.g. per-agent DB roles). The two are defense in
+      depth, not redundant: neither alone is the full mitigation, extending
+      TR-SEC-010's least-agency framing from single-agent tool grants to
+      multi-agent tool + data boundaries. Also carries the corrected version
+      of the private ADR-031 promotion-gate story: a human-approval step was
+      dropped after review found it protected an action that wasn't the
+      actual security-relevant moment — kept in the worked example's README
+      as a caution against copying a control's *conclusion* without
+      re-checking whether its *reasoning* still holds.
+      Shipped as a **new registry entry** (TR-SEC-013 — a new ID read better
+      than amending TR-SEC-010, since multi-agent tool+data isolation is a
+      distinct claim from single-agent tool-grant restriction, matching how
+      TR-SEC-011/012 were each given their own entry rather than folded into
+      an existing one): `registry/tr-registry.yaml`,
+      `examples/compartmentalized-agents/` (`isolation.py` + a test proving
+      the data layer blocks a deliberately misconfigured tool layer —
+      the actual defense-in-depth proof, not just that both layers exist),
+      `AGENTS.md` "Compartmentalized Multi-Agent Isolation" section,
+      `docs/requirements-implementation-map.md` row.
+- [x] **Ground-truth verification for agent security-property claims** — new
+      pattern, not previously roadmapped. A claim about an agent's own
+      behavior, obtained only by asking the agent (chat transcript) — "do you
+      have tool X," "do you remember Y" — is not verification evidence for a
+      security-relevant property (isolation, permission boundary, memory
+      scoping). Verify against the system's own ground truth instead (the
+      target API's own list/read endpoint, a DB row, a server log line),
+      independent of what the agent under test reports. Motivated by two real
+      false passes in the ADR-014 spike: an isolation check that "passed" only
+      because the test question was routed to the wrong backend entirely (not
+      the one actually under test), caught only by querying the real memory
+      store's API directly instead of trusting the chat reply. This is a
+      sharper, agent-specific instance of the existing "verify before
+      referencing" / zero-hallucination discipline, applied to runtime
+      behavior claims rather than static code symbols.
+      Shipped as **TR-TEST-007** (new entry — distinct from TR-TEST-006's
+      write-effect verification, this covers self-report vs. ground truth for
+      a behavioral/security claim) in the "Testing" section; a checklist line
+      item in `templates/completion-checklist.md`; the
+      compartmentalized-agents example extended with `SelfReportingAgent`
+      (`isolation.py`) and a test showing its self-report gives a false pass
+      on an isolation leak that `ToolRegistry.list_tools()` — ground truth —
+      catches.
+- [x] **Layering rule** (graduates from v0.7's roadmapped item, second
+      exemplar: private ADR-013's Phase A → A.5 → B → C → D rollout table,
+      alongside the existing private deployment-proposal citation).
+      Foundational/shared infrastructure ships first; every subsequent phase
+      is immediately usable on arrival — no functionality idles behind an
+      unmet dependency, and no phase is "mostly done" before the next starts.
+      Shipped as a new "Rollout Sequencing" section in
+      `docs/ai-engineering-operating-model.md` with a genericized phase-table
+      shape, plus a `docs/requirements-implementation-map.md` row —
+      documented pattern, no new TR-ID (matches other "Documented"-only rows
+      in that map).
+
+All three shipped. Promotion bar, consistent with v0.7's rule: exported only
+once the private implementation has *running, hands-on evidence* behind it,
+not just an accepted design ADR — met here by ADR-014's spike outcome
+(2026-07-29).
+
+## Backlog — unscheduled
+
+Deferred from the 2026-07-13 Zero-Trust-for-AI-Agents review, design-stage
+only as of 2026-07-13 with no running implementation cited since. Not
+attached to any version — promotion requires the same bar as v0.7/v0.8: an
+operating track record in the private monorepo (commits, tests, hands-on
+evidence), not just an accepted design ADR.
 
 - [ ] **Disposition contract** — triage agents emit a structured disposition
       (query / think / report) as a loop-contract output field, extending
@@ -136,11 +217,6 @@ evidence TR-SEC-010 had — commits, tests, an operating track record):**
       coverage (fraction of agent outputs a human reviewed), and
       explainability-by-trigger-ID (every agent output cites the ID of its
       triggering event, a mandatory loop-contract field) (private-repo deployment proposal)
-- [ ] **Compartmentalization worked example** — the most-exposed agent gets
-      the fewest permissions (write-only into a quarantine zone), the
-      most-privileged agent gets no public egress, and promotion out of
-      quarantine is human-gated: agent proposes + safety report, human
-      approves, agent executes (private ADR-031)
 - [ ] **Human-gated model experimentation + dual-LLM review** — model
       adoption is a human judgment recorded as a reviewable config diff,
       never a runtime switch; critical calls may use a producer→reviewer
@@ -151,10 +227,6 @@ evidence TR-SEC-010 had — commits, tests, an operating track record):**
       keeping the dependency (Anthropic Zero-Trust eBook). **Unproven here**
       — export only after it has been practiced at least once in the private
       monorepo
-- [ ] **Layering rule** for agent/platform rollouts (operating-model doc):
-      foundational ops/observability ships first; every subsequent phase is
-      sized to be immediately usable — no functionality that idles behind
-      unmet dependencies (private-repo deployment proposal)
 
 ## Non-goals
 

docs/ai-engineering-operating-model.md

@@ -41,6 +41,24 @@ by humans and other agents.
 - **ADR lifecycle** preserves why a decision was made and how it can be
   superseded later.
 
+## Rollout Sequencing
+
+Multi-phase agent or platform builds ship in **layers**, not a single
+big-bang release: foundational, shared infrastructure ships first, and every
+subsequent phase is immediately usable the moment it lands — no phase should
+sit "mostly done," idling behind a later phase that hasn't been built yet.
+
+| Phase | Ships | Immediately usable as |
+|---|---|---|
+| Foundations | Shared infra (auth, storage, observability, backup) | The measurement/ops base every later phase is built on |
+| Capability A | First agent/workflow, fully wired end to end | A working, narrow slice — not a stub |
+| Capability B | Second agent/workflow, reusing Foundations | Independently usable even if a later Capability C is delayed |
+| Wrap-up | Docs, CI, reproducibility | A rebuildable system, not tribal knowledge |
+
+Each phase's own tests pass before the next phase starts — no phase is
+"mostly done." Documentation updates land in the same change as the phase
+they describe, not batched at the end.
+
 ## Repo-Time Controls
 
 - `scripts/check-config-consistency.py` catches retired model strings and