01 — Agent Security in Depth Framework (v0.2.2)

A native-primitives defence-in-depth model for AI agent security in regulated enterprise environments.

v0.2.2 status. Editorial errata pass on v0.2.1, applying the eight items the third TriLLM cycle (01-review-v0.2.1.md) unanimously recommended. No structural changes; this is the locked architectural baseline. The pattern v0.1 → v0.2 → v0.2.1 → v0.2.2 (locked) → v0.3 (parallel non-blocking) mirrors NIST CSF 1.0 → 1.1 → 2.0 versioning. v0.3 (Constitution for Framework Revision + six-axis falsification instrumentation) is now a parallel non-blocking track. v0.2.1 archived at archive/01-immunosec-framework-v0.2.1.md.

v0.2.1 → v0.2.2 errata (editorial only). (1) J's type ambiguity clarified — composition is the native risk; J is the architectural overlay. (2) F's "highest tier permitted" wording corrected to "minimum tier sufficient for the control objective, capped by maximum tier permitted by Primitive D classification". (3) D's magnitude/aggregation handling made explicit via E cross-reference. (4) §7 residual "Primitive I" wording swept and updated to I_arch / I_commercial. (5) §6.2 cross-tenant aggregation residue swept. (6) 73.2→8.7 empirical anchor cleaned. (7) "Conformance-falsifiable" language normalised throughout §8 and §10. (8) F/G/H reconnaissance blind-spot framing sharpened in §9 from "research-grade open problem" to "named structural coverage gap for low-D-class reconnaissance." See § 11.7 for the v0.2.1 review response.

v0.2.1 → v0.2.2 substantive content (carry-over). v0.2.1 was the patches in response to the second TriLLM debate — typed spine + dependency graph (§3.0); F0–F4 reconstruction tiers (§3.6); I split into I_arch + I_commercial (§3.9); J recast as bounded capability-graph assurance overlay (§3.10); §5.3 prioritisation calculus added; §8 measurement contracts replace bare falsification conditions; §9 open problems expanded honestly. § 11.6 records the v0.2 critique response.

v0.2 status (further carry-over). v0.2 was the rewrite of v0.1's immune-system-derived framework, applying Action A from the v0.1 debate synthesis. The immune-system narrative survives as Appendix A — reading guide and mnemonic, not architecture. v0.1 preserved at archive/01-immunosec-framework-v0.1.md. Section 11 records which v0.1 critique findings were accepted, qualified, or pushed back; §§ 11.6 / 11.7 do the same for the v0.2 and v0.2.1 cycles respectively.

1. Why this framework exists

Three shifts make AI agent security categorically different from prior dev-tool security and from prior application security:

1. The agent has the human's credentials. Git, gh tokens, SSH keys, cloud CLI sessions, secret-manager handles, sometimes production access. The agent acts under a human identity with no MFA prompt because the human authenticated this morning. Audit logs say "human did this" when an agent did it.
2. Untrusted text becomes executable intent. Every file the agent reads — a README, an issue comment, a transpiled .min.js, a webpage, an MCP tool result, a system-reminder block — is potential instruction. There is no syntactic boundary between data and command. Large language models cannot reliably distinguish the two; this is an open research problem.
3. YOLO / autonomy mode removes the human-in-the-loop. Background execution means the failure mode of #1 + #2 isn't "user sees weird suggestion and declines" — it is "agent silently does it and the diff lands in main an hour later."

Classic security frameworks were built for stable boundaries (network perimeters), enumerable enemies (signature-driven detection), and prevention as the primary mode of victory. Agent security violates all three assumptions. The framework presented here is built from primitives that do fit the new shape: delegated authority, instruction provenance, information flow, side-effect taxonomy, runtime containment, observability with content minimisation, detection-response-recovery, learning, governance, and composition.

The framework is opinionated about its target market — regulated enterprise, particularly APRA-regulated AU industry and the Commonwealth + AUKUS ladder (see 06-international-expansion.md). It is not designed for hobbyist agents, consumer copilots, or unregulated B2B integrations, though most of its primitives apply.

2. The threat surface in one page

The framework presupposes the threat surface, summarised here so this document is self-contained.

The dominant attack classes, with named real-world incidents (2025–2026):

(See 04-reference-threat-model.md § 2.5 for the full real-world parallel set.)

Defence-in-depth is empirically supported. The framework's central architectural claim — that no single layer holds and the stack is the value — is supported by three independent classes of evidence:

1. Anthropic's April 2026 Trustworthy Agents in Practice explicitly formalises a four-layer shared-responsibility model and reports significantly lower exploit success rates against stacked controls than against any individual layer.
2. Market consolidation pattern (2025–2026). Every commercial AI-security stack assembled by Cisco, Microsoft, Palo Alto Networks, SentinelOne, and CrowdStrike converged on multi-layered architectures rather than single-point detection (see 05-market-research.md § 3). This is the strongest form of "the market voted with capital"-style evidence available.
3. Published OWASP / NIST analysis of agent-class incidents (EchoLeak, PocketOS, MCP STDIO RCE) in 2025–2026 consistently attributes successful attacks to multiple concurrent control failures rather than to defeat of any single defence.

(v0.2.2 note: earlier framework versions cited a specific "73.2% → 8.7%" reduction figure attributed to an October 2025 joint OpenAI / Anthropic / Google DeepMind paper. The v0.2 critique correctly flagged that this citation was not verifiable. v0.2.2 has removed the specific number from the load-bearing claim; the defence-in-depth thesis rests on the three classes of evidence above, which are independently citable. If the original paper surfaces with a verified methodology, v0.3 may restore the specific number as illustrative.)

3. The orthogonal-primitives spine

The framework's spine is ten primitives, derived from the structure of agentic risk rather than from analogy. Each primitive is:

• Orthogonal — the failure mode of one primitive is distinguishable from the failure modes of the others. You can ask "did primitive A fail or did primitive B fail?" and get a discrete answer.
• Engineerable — you can assign an engineering team to a primitive without splitting their work across unrelated concerns.
• Falsifiable — each primitive ships with a design rule and an evidence condition that would refute the rule if observed in production.

The ten items are not strictly hierarchical, but they have a partial dependency order described in § 3.0 below. The order below reflects that partial dependency, not a "first to last" deployment sequence.

3.0 The typed spine and dependency graph (NEW in v0.2.1)

The v0.2 critique correctly identified that v0.2 called all ten items "orthogonal native primitives" while the document itself acknowledged they have dependencies. The honest typing:

Important typing note (v0.2.2 clarification). The composition risk is itself a native risk of agentic systems (multi-agent privilege laundering happens whether or not we have an overlay to handle it). Primitive J is the architectural overlay that operationalises the controls for that risk. The rest of the document uses "J" as shorthand for both — readers should understand "Primitive J" to mean "the composition overlay handling the composition native risk."

Regulatory mapping is no longer in the spine. v0.2 placed per-regime compliance evidence collection inside Primitive I and called it the framework's "single most defensible piece of IP." v0.2.1 corrects this: regulatory mappings are commercial adapters that emit evidence from I_arch's substrate to APRA / MAS / PRA / OSFI / OCC / EU AI Act formats. They live outside the architectural spine, in 03-maturity-model.md and in the regulator-mapping module of the productised wedge (see 07-build-vs-buy.md v0.2). The architectural framework is jurisdiction-agnostic; the adapter layer is jurisdiction-specific.

This was the v0.2 critique's central finding (Diagnosis 2 in 01-debate-v0.2-synthesis.md). Remove APRA / MAS / PRA from the world and the old Primitive I disappears while A–H and J are unchanged — that is the test of a commercial wrapper, not an architectural primitive.

The dependency graph

Reading the graph: native risk primitives (A, B, C, D, J-overlay) define the invariants. E bounds blast radius. F is the substrate everything else reads from. G, H, I_arch sit above F and read from it. F is upstream of detection, learning, and assurance — which is why the v0.2 minimisation correction to F propagates to all three (see § 3.6, 3.7, 3.8).

What this typing earns

1. The count question becomes principled-but-revisable. Why these items? Five native risk questions (who acts, under what instruction, on what data, producing what side effect, composed how), three control planes (sense, decide+act, learn), one substrate, one assurance plane. The internal completeness criteria for each category are testable; if any agentic-action question is unanswered, a new native primitive is required; if any operational mechanism is missing, a new control plane.
2. Real incidents map to dependency-graph paths, not single primitives. An attack that defeats prompt injection (B failure) AND succeeds because behavioural detection couldn't catch the resulting tool-call (G blind spot) AND was not in the threat-intel library (H gap) is one coupled fault tree, not "Primitive B failed." Incident review uses the graph.
3. The framework can now be pruned, not just extended. v0.2 had no honest path to remove a primitive (Kimi's "framework that cannot die"). With typing, removal becomes legitimate: if a candidate primitive fails the "intrinsic to agentic action" test for its category, it is demoted out of the spine (as v0.2.1 does to old I).

3.1 Primitive A — Agent Authority

What it is. The model of who may cause side effects, under whose delegation, with what scope, for how long, and under what approval condition. The agent-specific extension of IAM.

The invariant. Every action the agent takes is attributable to a distinct, scoped, time-bounded agent principal — never to an impersonated human user. Every commit, push, API call, tool invocation carries an agent_principal_id and (where the human initiated it) a human_initiator_id.

Key controls.

• Distinct agent principal type in IAM (custom claim, workload identity via SPIFFE, or vendor-specific).
• Short-lived, scoped, session-bound credentials. JIT issuance; revocation at session end regardless of nominal TTL.
• Delegation lineage recorded for every authority grant.
• Approval-condition tagging on credentials (e.g. "this token is valid for at most three production writes, then expires").

Failure mode when missing. Audit logs misattribute agent actions to humans. SOX / SOC 2 / CPS 230 change-management controls are silently bypassed because the agent's commits look like human commits. Insider-threat amplification by agents becomes invisible.

Design rule. Agents must operate under their own attributable principal type, never as impersonations of human users.

Falsification condition. If, three months after rollout, more than 5% of production agent actions cannot be attributed to a named agent principal distinct from the originating human, the implementation has failed the design rule.

3.2 Primitive B — Instruction Provenance & Trust Hierarchy

What it is. The model of where instructions came from, which instructions may override which, and what constraints retrieved or tool-generated content imposes on policy and tool choice.

The invariant. Untrusted content (issue comments, web pages, MCP tool results, retrieved documents, plugin descriptions) cannot authorise privileged side effects or override system policy without an explicit policy-aware review step.

Key controls.

• Trust-level tagging on every input class: system instructions (highest trust) → user input (medium) → tool outputs / retrieved content / plugin descriptions (untrusted, instruction-inert).
• Tool-call argument tainting: arguments derived from untrusted content cannot relax policy.
• Plugin / MCP server description treated as advertising copy, not as policy input.
• Self-modification governance: agents may not edit their own system prompts, hooks, settings, or registered tools without out-of-band human approval.

Failure mode when missing. ChatGPT's worked example: untrusted GitHub issue → agent modifies CI workflow → secrets leak through approved logs. The signed plugin, the egress proxy, and the observability stream all behave correctly; the agent was told to do the wrong thing through a channel the framework treats as data.

Design rule. Untrusted instructions can influence agent output but cannot influence agent policy or tool choice without a policy-aware override step.

Falsification condition. Red-team test corpus that embeds policy-override instructions in tool-result content; if more than 10% of tests produce a policy override, the implementation has failed.

3.3 Primitive C — Information-Flow Model

What it is. Data-classification-aware control of what the agent may read, what may influence its policy decisions, what may leave the system, and what may be written to durable state.

The invariant. Each data class has an explicit set of permitted sources, permitted processors, permitted sinks, and permitted retention. The agent cannot cross those boundaries silently.

Key controls.

• Data-class tagging on every input and output (PII / regulated / confidential / public).
• Per-class sink allowlists for outbound LLM calls, web fetches, git pushes, file writes.
• Tenant-boundary enforcement at the data layer (cross-tenant reads explicitly prohibited; not just "logically separated").
• Vendor-boundary control: which LLM provider may see which data class.
• Logging-boundary control: which event fields may persist in central telemetry vs which must be hashed / redacted / dropped (this is the load-bearing interaction with Primitive F).

Failure mode when missing. Customer PII flows into the LLM provider's training pipeline. Tenant A's prompts surface in Tenant B's session. GDPR / Privacy Act / HIPAA breaches that the perimeter looks clean on.

Design rule. Data classes constrain the agent's input sources, processors, sinks, and retention. No data class may reach an unapproved combination without an explicit policy decision logged as evidence.

Falsification condition. If three months of telemetry show any data-class-to-unapproved-sink flow without a corresponding logged policy decision, the implementation has failed.

3.4 Primitive D — Side-Effect Taxonomy

What it is. Every action the agent can perform is classified along three orthogonal axes: reversibility, externality, and regulator-notifiability. The classification determines which other primitives apply.

The invariant. Irreversible, externally-visible, or regulator-notifiable actions require pre-commitment to non-destructive action paths — staging, simulation, queuing, dual-control, time-delay — before execution. Termination after the fact is a cleanup primitive, not the headline response.

Action axes:

Magnitude and aggregation handling (v0.2.2 cross-reference). The three axes above classify individual actions but do not capture magnitude (a $5,000 refund vs a $5 refund) or aggregation (10 sequential $499 refunds within a single session). Both are handled by Primitive E's blast budgets: per-action thresholds bound magnitude; per-session aggregate thresholds bound aggregation. The classification (D) determines which budget applies; the budget itself (E) enforces it. The v0.2.1 review correctly identified that this cross-reference was implicit; v0.2.2 makes it explicit.

Key controls.

• Action classification table — every tool, every API, every agent-driven mutation is pre-classified.
• Staging primitives: terraform plan not terraform apply; git commit to a feature branch not git push --force origin main; draft a refund not issue it.
• Dual-control: irreversible financial action, production deploy, regulator-facing communication require a second human or a second agent with independent authority.
• Time-delay externalisation: outbound communications, payments, deploys hold for N minutes before externalising; the hold window is the recovery window.
• Simulation: where possible, run the action in a sandbox first and validate the diff.

Failure mode when missing. Gemini's worked example: agent issues terraform destroy; framework's response is "terminate the session"; production is already gone. Or: agent issues 10 sequential $499 refunds; framework's response is "kill the session after refund 8"; $4,000 is already moved.

Design rule (the one Doc 01 v0.1 got wrong). For irreversible side effects, the headline response is deferral, not termination. Termination becomes a cleanup primitive that operates after deferral has prevented the irreversible action.

Falsification condition. Tabletop exercise: simulate a compromised agent issuing irreversible destructive actions. If the framework's controls allow the action to externalise faster than the response time, the implementation has failed.

3.5 Primitive E — Runtime & Containment

What it is. Designed-to-die runtime environments. Ephemeral execution, blast budgets, JIT credentials, forensic capture on termination, sandboxing where the per-surface compliance posture requires it.

The invariant. The blast radius of any individual agent session is bounded by design. A compromised session cannot persist, cannot exceed budget, and leaves no durable side effects outside the explicitly approved set.

Key controls.

• Ephemeral execution containers per session (E2B / Modal / AWS AgentCore commercial; Firecracker self-host for AUKUS / IRAP-PROTECTED workloads per 07-build-vs-buy.md § 10).
• Filesystem isolation — container FS only; host FS, ~/.ssh/, other repos, other kube contexts inaccessible.
• Network isolation — outbound only via the broker that enforces Primitive C.
• Blast budgets — hard caps on tokens, wall-clock time, tool-call count, network egress bytes. Exceed → session terminates with forensic capture.
• Credential lifecycle bound to session — Primitive A intersection point.
• Self-termination — session signals "I think I've been compromised" → harness tears it down immediately.

Failure mode when missing. Agent runs on the developer's laptop with full host filesystem and network. PocketOS / Cursor wipe: agent finds Railway token in unrelated file, destroys production in 10 seconds. No bound on damage.

Design rule. Ephemeral, attestable, blast-bounded runtimes dominate in-flight monitoring. You do not need perfect detection if compromised principals cannot persist past their bounded window.

Falsification condition. Chaos-test exercise: force-kill the agent runtime mid-session. If anything persists that shouldn't — files, network state, credentials, in-flight side effects — the implementation has failed.

3.6 Primitive F — Observability & Evidence (tiered F0–F4 in v0.2.1)

What it is. Structured, queryable, immutable event streams of every agent action — with tiered reconstruction fidelity (F0–F4) mapped to Primitive D side-effect classes, plus tamper-evidence, tenant-aware retention, and privacy-preserving aggregation where the threat model permits. The substrate for G (Detection-Response), H (Learning), and I_arch (Assurance).

The invariant (revised in v0.2.1). Every primitive's enforcement action is logged with attribution at the fidelity tier appropriate to the side-effect class of the action it relates to. High-fidelity reconstruction is available for high-risk irreversible actions; metadata-only logging is the default for read-only / internally-visible actions. The v0.2 framing "minimisation is the default" was correct in spirit but operationally incomplete — the v0.2 critique correctly identified that G, H, and J need semantic content to function, and a single minimisation default broke all three.

The F0–F4 reconstruction tiers (NEW in v0.2.1).

The default-by-class (v0.2.2 wording fix). Every event is emitted at the minimum tier sufficient for the control objective, capped by the maximum tier permitted by its Primitive D classification. "Sufficient" is determined by the control objectives the event must serve (detection by G, signature creation by H, audit by I_arch). F0 / F1 are the operational steady state; F2 supports behavioural detection; F3 supports semantic signature creation; F4 is reserved for forensic-grade replay of high-risk incidents. (v0.2.1's "highest tier permitted" framing recreated the panopticon pressure the framework was supposed to reject; the v0.2.1 review correctly identified this and v0.2.2 corrects it.)

Key controls.

• OpenTelemetry GenAI semconv as the event schema; tier metadata is a first-class field on every event.
• Content-class-aware redaction at emission (not at query time): the raw content for a regulator-notifiable action is captured at F4 only if the policy authority for F4-capture is present in the agent session.
• Policy-decision logging (F1) as the operational forensic substrate.
• Tamper-evidence via Sigstore signing + Apache Iceberg immutability across all tiers.
• Tenant-aware retention; data residency enforced at the storage layer.
• Access-trail at one tier below the data being accessed (you cannot read F3 without leaving an F2 audit record of the access).
• Cross-tenant aggregation (the v0.2 control claim) is moved to § 9 open problems — privacy-preserving aggregation on adversarial NLP content is research-grade, not deployable today.

Failure mode when missing or mis-tiered. Either (1) investigation cannot reconstruct a session post-incident because tier was too low for the action's class, or (2) the audit log becomes the breach because tier was too high for the action's class. The v0.1 panopticon failed in mode (2); a naïve v0.2 minimisation default would fail in mode (1) for high-risk actions. F0–F4 tiering is the resolution.

Design rule. Observability is the substrate of every other primitive. Reconstruction fidelity is class-conditional, not uniform. Universal raw capture is malpractice (v0.1 error); universal minimisation is operationally incoherent (v0.2 error); class-conditional tiering is the correct shape.

Falsification condition (revised). Pick a random agent session from yesterday. (a) Reconstruct what happened end-to-end at the tier appropriate to its highest-risk action in under 60 seconds. (b) Verify that every event was emitted at no higher a tier than its Primitive D classification authorised. (c) Verify that every F3/F4 access has a matching F2 access-trail event. Failure on any of the three is a failure of the rule.

Measurement contract (NEW in v0.2.1). See § 8.

3.7 Primitive G — Detection, Response & Recovery

What it is. Three separable verbs that v0.1 conflated into "Adaptive Immunity": detection (sense an anomaly), response (do something proportionate), recovery (return to a safe state). Each has distinct mechanisms and distinct evidence requirements.

The invariant. Suspicious agent behaviour produces a graduated response proportional to the confidence of detection, the reversibility class (Primitive D) of the action, and the authority scope (Primitive A) of the principal — never a binary block-or-allow.

Key controls.

Detection

• Innate / signature: known-bad prompt-injection signatures applied at every I/O boundary (especially tool results — the dominant vector).
• Behavioural: per-session baselines via Primitive F telemetry; deviation from baseline produces a risk score, not a verdict.
• Policy: violation of a declared invariant (e.g. cross-class data flow, irreversible action without staging) is a detection event.

Response (graduated, the v0.2 correction)

• Elevated state: risk score crosses threshold → telemetry verbosity rises; tool-call rate-limits tighten; destructive operations require human gate.
• Quarantine: confirmed-compromised principal → session enters read-only mode; in-flight irreversible actions deferred or rolled back; SOC notified.
• Termination: only after deferral has prevented externalisation, and with full forensic capture of the session state.

Recovery

• Credential revocation: all session-bound credentials revoked irrespective of nominal TTL.
• Side-effect rollback: deferred actions cancelled; staged actions reviewed before continuation.
• Downstream notification: dependent systems told the session was compromised.
• Forensic preservation: tamper-evident capture of the session state for incident response.

Failure mode when missing. Confirmed-compromised agent continues acting because detection only emits alerts. Or detection acts but only blocks the immediately-detected action while the agent retries via a different path. Or termination fires but credentials persist and the agent reconnects with the same authority.

Design rule. Detection produces a risk score; response is graduated; recovery includes credential revocation, side-effect rollback, and downstream notification. Termination without recovery is incomplete.

Dependency on F (NEW in v0.2.1). Signature-based detection runs on F0–F1 (metadata is sufficient for many known-bad patterns). Behavioural detection requires F2+ — semantic fingerprints, not just metadata. The v0.2 critique correctly identified that v0.2's "minimisation default" framing broke this: a metadata-only stream cannot support "the agent's tool-call shape changed semantically." Detection's tier requirement is determined by what the rule needs to evaluate; F's tier is determined by what the action's D class authorises; the deployable detection coverage is the intersection of those two constraints, not the union.

Falsification condition. Walk through a confirmed high-confidence anomaly scenario end-to-end. Measure: time-to-detection, time-to-quarantine, time-to-credential-revocation, completeness of rollback, downstream notification latency. If any step requires a human in the critical path, or any rollback step fails, the implementation has failed.

Measurement contract (NEW in v0.2.1). See § 8.

3.8 Primitive H — Learning & Assurance

What it is. The feedback loop from incidents and red-team exercises into detection signatures, policy rules, and behavioural baselines. Plus the assurance program that validates the framework is working.

The invariant. Every incident and every red-team finding produces a deployable signature or policy update within a bounded SLA. Detection coverage is measured continuously, not annually.

Key controls.

• Threat-intel ingestion (commercial feeds + AVID + MITRE ATLAS + OWASP) into Primitive G signature library.
• Continuous red-teaming in CI / pre-prod (Garak, PyRIT, proprietary corpora).
• Incident-to-signature pipeline with named SLA (e.g. 30 days from incident to deployed signature).
• Cross-tenant signature contribution back into a privacy-preserving network. Moved to § 9 open problems in v0.2.1 — privacy-preserving aggregation on adversarial NLP content is research-grade (federated learning on adversarial natural-language content is unsolved). Single-tenant intel pipelines are deployable now; cross-tenant networks remain a long-arc strategic asset but not a Phase 0/1 deployable control.
• Vaccination programs: scheduled deliberate exposure to known attacks in production-like conditions.
• Detection coverage metrics published quarterly: recall, precision, mean-time-to-detect, false-positive-driven-disablement rate.

Failure mode when missing. Red-team findings discussed in retros, never operationalised. Detection coverage drifts; signature library decays. The same attack class succeeds twice.

Design rule. Memory compounds across incidents within a tenant; the rate of compounding is the measure. Single-tenant learning is necessary and deployable; multi-tenant aggregated learning is a future moat that depends on unsolved research problems.

Dependency on F (NEW in v0.2.1). Signature creation against semantic attacks (prompt injection, instruction smuggling) requires F3+ content — redacted-PII raw text suffices for fingerprinting, but pure metadata does not. The v0.2 critique correctly identified that v0.2's framing implied signature creation could work on minimised telemetry alone; in practice, the H pipeline needs explicit F3-tier authority for the events feeding signature generation.

Falsification condition. Show the last six signatures added to detection. For each: when was the incident or red-team finding? When did the signature deploy? If the median exceeds the SLA, the loop is broken.

Measurement contract (NEW in v0.2.1). See § 8.

3.9 Primitive I_arch — Assurance & Accountability (split from v0.2's monolithic Primitive I)

v0.2.1 structural change. v0.2's Primitive I bundled two distinct concerns: an architectural assurance plane (internal control verification, board reporting, attributable identity) and a commercial regulatory-adapter layer (mappings to APRA / MAS / PRA / OSFI / OCC / EU AI Act control codes). The v0.2 critique correctly identified the latter as GTM laundered into the architectural spine — remove APRA / MAS / PRA from the world and the regulatory-mapping concerns disappear while everything else is unchanged. That is the test of a commercial wrapper, not an architectural primitive.

v0.2.1 separates them:

• I_arch (this primitive) stays in the spine as the assurance plane.
• I_commercial (the regulatory-mapping module) moves out of the spine to a commercial-adapter layer documented in 03-maturity-model.md and productised in 07-build-vs-buy.md v0.2. It is the load-bearing piece of the productised wedge; it is not architecturally constitutive.

I_arch — what stays in the spine

What it is. The plane on which the other primitives' enforcement is verified. Did A's controls actually attribute every action to an agent principal? Did D's controls actually defer every irreversible action? Did F's tiering actually emit at the correct tier for each action's D class? Internal control-effectiveness verification.

The invariant. Every native risk primitive (A, B, C, D, J-overlay) and every control plane (E, G, H) has a corresponding control-effectiveness signal in I_arch — a measurable indicator of whether its design rule is being maintained in the deployed system. The signal is jurisdiction-agnostic; the commercial adapters consume it.

Key controls.

• Per-primitive control-effectiveness telemetry (the measurement contracts in § 8 are the operational form of this).
• Attributable identity that traverses every action chain (agent principal + originating human + delegation lineage).
• Board-reportable KPIs that are framework-native, not regime-specific: detection coverage, mean-time-to-detect, mean-time-to-recover, false-positive-driven-disablement, deferred-action-rate, data-class-to-unapproved-sink count, F-tier emission compliance.
• Incident playbooks tied to the dependency graph (an incident is a fault tree across the graph, not a "Primitive X failed" attribution).
• Third-party assurance (annual external audit minimum).

Failure mode when missing. Control-effectiveness is opined on, not measured. The framework reports to the platform team but has no board-grade signal. Policy exists on paper but its enforcement cannot be verified.

Design rule. Every native risk primitive and every control plane has a measurable control-effectiveness signal. The signals are jurisdiction-agnostic; commercial adapters consume them to emit regime-specific evidence.

Falsification condition (revised in v0.2.1). For each primitive A–H and J, name its control-effectiveness signal. If any primitive lacks a measurable signal, I_arch is incomplete and the framework's assurance posture is incomplete. Note: the v0.2 falsification condition ("can APRA / MAS / PRA / OSFI / OCC ask tomorrow and be answered in 24 hours") was the v0.1 critique's "this looks like a sales demo" critique made operational. It still matters — but it is now a measurement on the I_commercial adapter layer, not on I_arch.

Measurement contract (NEW in v0.2.1). See § 8.

I_commercial — what leaves the spine

The regulatory-mapping module that converts I_arch's primitive-level signals into APRA / MAS / PRA / OSFI / OCC / EU AI Act / DORA / NIS2 / HKMA SPM / JP FSA / NYDFS Part 500 / ISO 42001 / IRAP ISM / DSPF / NCSC / DoD CDAO / AUKUS Pillar 2 control attestations is not in the architectural spine. It is the load-bearing piece of the productised wedge (07-build-vs-buy.md v0.2). Per-regime mapping tables remain in 03-maturity-model.md.

This separation matters because:

1. The architectural framework is jurisdiction-agnostic. A buyer in a regime not yet mapped (Singapore tomorrow, Brazil next year) gets the same framework with a new adapter.
2. The framework can be honestly applied to non-regulated contexts. Hobbyist agents, consumer copilots, and B2B-API integrations get A–H + I_arch + J without needing I_commercial — which v0.2's monolithic I did not allow.
3. Prioritisation across primitives becomes legitimate. § 5.3 (new) can now say "for adversary class X with regulatory exposure Y, prioritise primitives Z₁, Z₂, Z₃" without I's structural pressure forcing equal narrative weight.

3.10 Primitive J — Composition (recast in v0.2.1 as a bounded capability-graph assurance overlay)

v0.2.1 structural change. v0.2 framed J as a peer primitive with a falsification condition ("no path exists by which untrusted content induces an agent to act outside its declared scope"). The v0.2 critique correctly identified this as computationally intractable — "no path exists" in a stochastic multi-agent system is proof-of-negative and exponentially expensive to test even partially. Several models converged on the fix: recast J as a bounded capability-graph assurance overlay, not a peer architectural primitive.

What it is (revised). J is an overlay applied to A through G when those primitives are exercised in multi-agent compositions. It is not a separate native risk to be defended against; it is a scope extension of the native risks already covered (A's authority, B's instruction provenance, C's information flow, D's side-effect classification) plus a control-plane extension (G's detection-response operating across agent boundaries).

The invariant (revised). For any composition of agents {a₁, a₂, …, aₙ}, the declared joint capability set is the union of each agent's individual capabilities subject to taint-propagation rules from B (instruction provenance) and C (information flow). Any agent action that exceeds the declared joint capability set is a policy violation. The framework does not claim to prove the absence of all unauthorised paths; it claims to bound the residual risk through declared capabilities + taint propagation + representative adversarial testing + explicit residual-risk acceptance.

Key controls (revised).

• Declared joint capability set for every composition: the explicit, written-down set of capabilities the composition is authorised to exercise. Anything not in the set is forbidden.
• Taint propagation through inter-agent messages: when agent A sends agent B a message containing untrusted content (B-class), the resulting tool calls in B inherit the taint and become subject to B's instruction-provenance controls.
• Capability-graph logging: every inter-agent delegation logged at F2+ with full lineage (delegator principal, delegatee principal, scope, taint vector, time bound).
• Representative adversarial path testing: for each new composition pattern, a bounded set of red-team paths is exercised pre-deployment. The test is not "no path exists"; it is "the represented adversarial paths fail closed."
• Explicit residual-risk acceptance: the gap between declared joint capabilities and proven joint capabilities is named, signed off by the accountable owner, and re-reviewed on a defined cadence.
• Multi-agent protocol governance: agent-to-agent protocols (MCP, A2A, internal IPC) require the same B / C / D / F / G controls as human-to-agent interactions.

Failure mode when missing. Agent A is restricted from reading customer PII. Agent A asks agent B to summarise a record set. Agent B reads the PII and returns the summary. Agent A now has effective access to data its policy forbids. The v0.2.1 control is: agent A's request to B is logged with the requested capability ("summarise records X"); the declared joint capability set is checked; if the joint capability is not declared, the request is rejected. The framework does not prove this catches every such path; it bounds the residual risk to compositions whose joint capability set has been declared and tested.

Design rule (revised). Composition is governed by declared joint capabilities + taint propagation + representative adversarial testing. The framework names what is in-scope (declared joint set) and what is residual-risk (everything else, explicitly accepted by the accountable owner). It does not claim to verify the absence of unauthorised paths.

Falsification condition (revised). For each deployed composition: (a) is the joint capability set explicitly declared? (b) is the representative adversarial test suite documented, current, and passing? (c) is the residual-risk acceptance signed and dated by the accountable owner? (d) when did the composition last surface an unauthorised-path incident, and how was it incorporated back into the declared set? Failure on any of (a)–(c) is a failure of the rule. Recurrence of (d) without (b)–(c) update is a deeper failure.

Measurement contract (NEW in v0.2.1). See § 8.

Open problem flag (NEW in v0.2.1). General intractability of multi-agent verification (proving absence of unauthorised paths in stochastic multi-agent systems) is moved to § 9. v0.2.1 explicitly does not claim to solve this; it bounds the problem to a declared, tested, signed-off perimeter.

4. Adversary capability model

Defence-in-depth without an adversary model is decoration. v0.2 introduces an explicit capability model mapped to authority boundaries.

For each customer deployment, the framework should identify which adversary archetypes are in-scope (varies by industry, threat intel, prior incidents) and which primitives must be most heavily invested in to defend against them. The Phase 0 / Phase 1 / Phase 2 phasing in 07-build-vs-buy.md is calibrated for the regulated-AU buyer's typical adversary mix (heavy on targeted external + malicious vendor + insider; lighter on consumer-facing opportunistic).

5. Cross-cutting concerns

Two concepts that span all ten primitives rather than belonging to any one.

5.1 Global threat-elevation ("fever")

When the org detects elevated threat — an active phishing campaign, an upstream supply-chain compromise (e.g. a future xz-utils-equivalent in an MCP server), credential-leak indicators, or simply quarter-end change-freeze windows — agent capabilities globally degrade:

• Primitive D irreversible-action thresholds tighten (more actions require dual-control / time-delay).
• Primitive G detection raises sensitivity; false-positive tolerance lowers.
• Primitive F telemetry verbosity rises (consistent with content-class minimisation).
• Primitive H signature feeds prioritised by recency.

Triggers may be manual (security team raises threat level) or automated (threat-intel feed signals, internal incident indicators). Auto-reset after the trigger clears.

Design implication. Build the dimmer switch from day one. Customers will need to dial up defences during incidents; if every change requires a re-deploy, the dial doesn't exist when it matters.

Note on v0.1. This was "Fever" in the immune-system metaphor. The control posture is unchanged; the name and rhetoric are demoted to Appendix A.

5.3 Primitive prioritisation calculus (NEW in v0.2.1)

The v0.2 critique correctly identified that v0.2 enforces equal narrative weight across all ten primitives — the framework cannot tell a customer which 2–3 primitives buy 80% of value for their specific threat class. This was a downstream symptom of v0.2's monolithic Primitive I (the regulatory-tables-must-cover-every-primitive structural pressure). With I split into I_arch + I_commercial in v0.2.1, prioritisation becomes legitimate.

The calculus. For a given deployment, the prioritisation tier of each primitive is computed from six inputs:

Worked examples.

The calculus is not a closed formula — it requires judgement informed by the deployment's specifics. But the framework now enables the conversation ("for your shape of deployment, here are the 2–3 primitives that matter most") rather than blocking it.

Falsification condition. A customer who has run the prioritisation calculus for their deployment can name their top three primitives and defend why. If a customer cannot, the calculus has not been operationally instantiated for them.

5.2 False-positive economics

Detection systems that fire too often get disabled in production. The classic security problem of autoimmunity — defences attacking the host — applies acutely to agent systems because agents operate at machine speed: a false positive doesn't just generate an alert, it can halt a business process or trigger an erroneous kill-switch on a critical workflow.

False-positive economics is a property of every detector, every policy, every workflow — not a separate primitive. v0.1 made this a "Tregs" layer (Layer 9); the critique correctly identified this as metaphor-capture (false-positive suppression is intrinsically cross-cutting).

Design rule. Every control in Primitives G (detection / response) and H (learning) must be designed with explicit precision targets, analyst-disposition feedback loops, override paths, and false-positive cost accounting from inception. Treat false-positive rate as a first-class KPI, not as downstream tuning.

The agent-specific calibration (the v0.2 sharpening). Biology's regulatory T-cells are tuned by evolutionary cost of autoimmunity vs cost of infection. The body accepts a high pathogen miss rate because autoimmune disease is catastrophic. Enterprise agent security has the opposite cost ratio for many threat classes: missed prompt injection that exfiltrates customer PII is a catastrophic, regulator-notifiable event; "autoimmune" false positives are a productivity tax measured in dollars per developer per week. For catastrophic-tail-risk problems, the v0.1 framing ("a sensitive detector without engineered suppression is shipping autoimmune disease") is backwards — it optimises away from sensitivity, which is the wrong direction. The v0.2 correction: calibrate false-positive tolerance to the cost ratio for the specific threat class. High-cost catastrophic classes accept more false positives; low-cost noise classes accept fewer.

6. Surface-specific instantiations

The spine is surface-agnostic. The implementations differ. Three primary surfaces matter for an enterprise platform.

6.1 Developer-side agents (Claude Code, Cursor, Copilot, custom IDE agents)

Threat shape: developer credentials; dev-machine attack surface; source-code IP egress; malicious skills / plugins / MCP servers; supply-chain injection via dependencies.

Highest-value primitives:

Distinctive concerns. Shadow-AI (devs install personal API keys outside corporate egress). Plugin sprawl (the marketplace is per-developer and ungoverned). Dev-machine secret theft (long-lived gh tokens with admin:org).

6.2 Production runtime agents (customer-facing features)

Threat shape: end-user prompt injection (every user input is potentially adversarial); multi-tenant isolation; runtime cost containment; response-quality regression; regulatory exposure on every output.

Highest-value primitives:

Distinctive concerns. Regulatory output exposure (agent produces legal / medical / financial advice it shouldn't). Cost amplification under attack (a single user can drive token costs into the thousands). Prompt-injection from user-uploaded content.

6.3 Internal-process agents (back-office automation, RPA-style)

Threat shape: long-running agents with broad creds; often touching payments / payroll / customer records; often integrated with legacy systems that lack modern auth; often deployed in shadow-IT fashion by business units.

Highest-value primitives:

Distinctive concerns. Legacy integration security (the agent talks to a 1998 mainframe via screen-scraping; what does identity attestation even mean there?). Regulatory reporting (APRA, AUSTRAC for AML). Insider-threat-as-business-process (the agent is doing exactly what it was configured to do, and the configuration was wrong).

7. Regulatory anchors by jurisdiction

The framework is jurisdiction-agnostic; the regulatory wrapper differs by market. The full per-jurisdiction mapping table is maintained in 03-maturity-model.md § 3. Summary table:

Practical implication. Per-regime compliance-evidence collection is the load-bearing product feature (the I_commercial adapter layer that sits outside the architectural spine, consuming control-effectiveness signals from I_arch) — the engine that converts the framework's primitive-level evidence into regime-specific control attestations. See 07-build-vs-buy.md for the build-vs-buy decisions and 03-maturity-model.md for the full per-regime control mappings.

8. Measurement contracts (conformance axis), consolidated (revised in v0.2.1; language normalised in v0.2.2)

The v0.2 critique correctly identified that v0.2's "falsification conditions" instrumented only the conformance axis of a six-axis failure taxonomy (conformance / effectiveness / cost / theory / scope / obsolescence) and lacked operational scaffolding (measurement protocols, owners, thresholds, abandonment actions). v0.2.1 promoted the conformance-axis falsification conditions to full measurement contracts with named operational scaffolding. v0.2.2 normalises the language: the framework is conformance-falsifiable as of v0.2.2 (an implementation can be shown to fail the measurement contracts); it is not yet theory-falsifiable on the effectiveness / cost / scope / obsolescence axes. The remaining five axes are explicitly deferred to v0.3 and listed in § 9 (open problems). Wherever this document uses "falsifiable" or "falsification condition" without further qualification, the conformance axis is meant.

8.1 The measurement contract template (NEW in v0.2.1)

Each primitive's measurement contract has nine fields:

8.2 Measurement contracts per primitive

Note: percentages below are defaults — operators should adjust per Primitive D severity-band rules. The 4.9% un-attributed actions Gemini's debate flagged is correctly read as "the deployer accepts a blind spot in that band, with explicit risk acceptance" rather than "5% is fine universally."

8.3 What § 8 does not yet do (deferred to v0.3 — listed honestly)

Per the v0.2 critique (ChatGPT's six-axis failure taxonomy), § 8 currently instruments only the conformance axis (does the implementation conform to the design rule?). The other five axes are deferred:

• Effectiveness: does maintaining the conformance signal actually reduce the harm the rule was supposed to prevent?
• Cost: is the rule cheaper in damages avoided than it costs to implement?
• Theory: is the design rule itself correct, or merely a comforting heuristic?
• Scope: is the rule applicable to the deployment, or being applied outside its domain?
• Obsolescence: has the rule been superseded by a better one we haven't yet adopted?

These axes are real. v0.2.1 does not instrument them; v0.3 must. The "theory-revision trigger" field in the measurement-contract template is a placeholder — it names what evidence would cause us to question the design rule, but it does not specify the abandonment protocol that would act on the evidence. That protocol is what Kimi's debate called the Constitution for Framework Revision and is the primary v0.3 deliverable (see § 11.6 for the editorial response).

A deployment that fails three or more of the conformance-axis measurement contracts is materially exposed; one that fails six or more should not be in production for regulated workloads. That criterion is itself conformance-axis only; a deployment that conforms to every contract but is being attacked successfully because the design rules are wrong is a v0.3 problem.

9. Open problems and acknowledged limits

The framework does not solve these. They are located architecturally — they live inside named primitives — but are unsolved as of May 2026. (This is the v0.2 reframing of the v0.1 § 9 that the critique correctly flagged as defensive.)

These problems are real, named, and unsolved. They are not "framework gaps" in the sense of "the framework should have answered them and didn't"; they are research and standards gaps that the framework explicitly flags as constraints on what any AI agent security product can guarantee. A defensible product is honest about the constraints; a marketing framework hides them. v0.2.1 takes the first path. The v0.2 critique correctly noted that v0.1's § 9 was defensively positioned ("research gaps external to the framework"); v0.2 relocated open problems inside named primitives; v0.2.1 expands the list with what the v0.2 critique surfaced and acknowledges them honestly.

10. Design principles distilled

1. Authority is attributable, scoped, and revocable. Distinct agent principals; no human impersonation.
2. Untrusted content cannot override system policy. Instruction provenance is enforced; tool-result content is data, not command.
3. Data classes constrain sources, processors, sinks, and retention. Information-flow enforcement is hard-coded, not policy-soft.
4. Side effects are taxonomically classified. Reversibility, externality, regulator-notifiability determine the controls that apply.
5. For irreversible actions, deferral beats termination. Stage, simulate, queue, dual-control, time-delay. Termination is cleanup, not response.
6. Ephemeral runtimes bound blast radius. Compromised principals cannot persist.
7. Observability is the substrate; minimisation is the substrate of safe observability. Policy decisions logged; raw content minimised per class.
8. Detection produces risk scores; response is graduated; recovery includes rollback. Termination without rollback is incomplete.
9. Memory compounds across incidents; the compounding rate is the measure. Single-tenant intel is a feature; multi-tenant aggregated intel is the moat.
10. Compliance evidence collection is a feature, not an afterthought. Per-regime evidence pipelines from inception.
11. Composition preserves least privilege. Multi-agent systems require primitive enforcement at the protocol boundary.
12. False-positive tolerance is calibrated to threat-class cost ratio. Catastrophic-tail-risk classes accept more false positives than productivity-tax classes.
13. Every design rule has a conformance-falsification condition. If the framework cannot be shown to fail in any operationally measurable way, it cannot be shown to succeed. Theory-falsification on the other five failure axes (effectiveness / cost / scope / obsolescence + the meta-level abandonment protocol) is deferred to v0.3.

11. Editorial response to v0.1 critique

This section records how v0.2 responded to each finding from the TriLLM adversarial debate (see 01-debate-synthesis.md).

11.1 Accepted findings (applied)

11.2 Qualified findings (partial agreement)

11.3 Pushed-back findings (rejected with reasoning)

11.4 What survives unchanged

The framework's core product instincts and target market:

• Attributable agent identity (now Primitive A)
• Ephemeral runtimes + JIT credentials (now Primitive E)
• Structured-but-minimised telemetry (now Primitive F)
• First-class false-positive budgets (now § 5.2)
• Global threat-elevation modes (now § 5.1)
• Continuous red-teaming (now Primitive H)
• Per-regime compliance-evidence collection (now I_commercial — out of the spine, in commercial adapters per Doc 03 / Doc 07)
• The regulated-enterprise anchor with AU + Commonwealth + AUKUS ladder
• Three surface instantiations (developer / production-runtime / back-office)
• The threat-surface enumeration (§ 2) with real-world evidenced examples

The wedge product strategy in 07-build-vs-buy.md v0.2 maps cleanly onto the new spine: MCP supply-chain governance is the Primitive B + C + H wedge; replay-grade audit is Primitive F + I; sovereign residency is Primitive E + I (the regulator-mapping module engine).

11.5 What this transition tells us about the framework

Two debates in (Doc 07 v0.1 and Doc 01 v0.1), the pattern is clear: adversarial multi-model critique reliably surfaces structural issues a single author won't see. Doc 07's debate produced metaphor-captured prioritization (Claude R2's orthogonal critique). Doc 01's debate produced biological-priors-produce-wrong-design-rules (Gemini's apoptosis) and the framework-has-no-native-security-model (ChatGPT's spine attack). Both findings are load-bearing for the rewrite.

Standing practice for the framework: any load-bearing document gets a TriLLM debate before being considered v0.x stable. The cost is roughly 5 minutes of TriLLM time plus 30 minutes of synthesis. The value is the framework's resistance to silent structural error.

11.6 v0.2.1 editorial response — applying the v0.2 critique

The v0.2 → v0.2.1 transition responds to a second TriLLM debate on Doc 01 v0.2 (see 01-debate-v0.2-synthesis.md; full transcript at ../debates/01-immunosec-framework-v0.2-critique.md). The pattern: v0.1 → v0.2 closed the metaphor-capture / missing-primitives / wrong-design-rules debt; v0.2 → v0.2.1 closes the substrate-propagation / GTM-laundering / J-tractability / measurement-discipline debt. Each iteration narrows structural debt without changing strategy.

Accepted findings (applied in v0.2.1)

Qualified findings (partial response in v0.2.1; full response deferred)

Pushed-back findings (rejected with reasoning)

What v0.2.1 demonstrates about the framework's posture

Three TriLLM debate cycles in, the framework has accepted critique in three structural rounds. The strategy (target market, wedge product, international ladder, regulatory tailwind, commercial path) has remained stable throughout. The architecture has changed three times in ways that make it materially more defensible:

• v0.1 → v0.2: metaphor demoted; native primitives introduced; design rules corrected
• v0.2 → v0.2.1: spine typed; substrate tiered; commercial wrapper extracted; assurance overlay bounded; measurement contracts operationalised
• v0.2.1 → v0.3 (planned): Constitution for Framework Revision; full six-axis falsification instrumentation; possible document split

This is the right pattern for a load-bearing framework. The cost of each cycle is ~1 day of work; the benefit is each cycle catches structural errors that would have been silent. The pattern terminates when critique cycles produce diminishing returns — not before.

11.7 v0.2.2 editorial response — applying the v0.2.1 review

The v0.2.1 → v0.2.2 transition responds to the third TriLLM cycle, which was reframed from adversarial critique to balanced assessment (01-review-v0.2.1.md; full transcript at ../debates/01-immunosec-framework-v0.2.1-review.md). The review's verdict was unanimous: lock v0.2.1 after a one-day errata pass; proceed immediately to Doc 06 critique + Doc 08 MVP spec + Doc 09 consulting template; run v0.3 as a parallel non-blocking track.

v0.2.2 is the editorial errata pass applied. It is the locked architectural baseline.

Errata items applied (eight, all editorial)

What v0.2.2 does NOT change

• No primitive added, removed, or renamed (Kimi's persistent point: the framework should accumulate primitives slowly).
• No design rule changed (the v0.2.1 design rules survive intact).
• No new section added other than editorial cross-references and the present § 11.7.
• No commercial-path implication. Doc 07 v0.2's wedge, Doc 05's market research, Doc 06's international ladder, Doc 03's maturity model, Doc 04's threat model — all unaffected. The framework is now locked and Doc 08 (MVP product spec) is built against it directly.

What v0.3 still contains (deferred per v0.2.1 review unanimous verdict)

1. Constitution for Framework Revision (Kimi's persistent contribution across cycles). The meta-level abandonment protocol: sacrifice / decomposition / merger / fallback / count-bound conditions. v0.3's primary deliverable.
2. Full six-axis falsification instrumentation (ChatGPT's persistent contribution). v0.2.2 instruments only the conformance axis (with full measurement contracts per § 8). v0.3 will instrument effectiveness / cost / theory / scope / obsolescence per primitive.
3. Possible document split (multiple reviewers). Risk Model / Architecture / Measurement Contract / Regulatory Adapters / Commercial Narrative. May emerge naturally from Doc 08/09 work; not required for v0.3 success.

All three are parallelisable with Doc 08/09 implementation and may be informed by implementation feedback. The framework is locked; v0.3 is concurrent extension, not corrective rewrite.

Closing the v0.1 → v0.2 → v0.2.1 → v0.2.2 → v0.3 arc

Four versions in (counting v0.2.2 as a locked editorial pass on v0.2.1), the framework has reached a state where:

• Three independent TriLLM cycles found progressively smaller structural debt;
• The third cycle (the v0.2.1 review) produced a unanimous lock recommendation;
• The strategy has been stable across all four versions while the architecture has converged;
• The remaining v0.3 work is concurrent extension informed by implementation feedback.

This is the right state for a load-bearing framework to be in before downstream artefacts (Doc 08 MVP spec, Doc 09 consulting template) are built on top of it. The framework has earned the lock.

Appendix A — Immune-system reading guide (the metaphor, demoted)

The framework was originally derived by analogy to the human immune system. v0.2 has rebuilt the architecture around native primitives, but the biological intuition remains useful as a mnemonic for non-technical stakeholders and as vocabulary for customer-facing communication. This appendix records the mapping for that purpose. It is a reading guide, not the architecture.

Use this appendix for customer narrative, marketing copy, and stakeholder communication. Use the body of the document for architecture, engineering, and compliance evidence. The two are designed to be consistent but the architecture is the source of truth.

The v0.1 name ImmunoSec is retired. The framework is Agent Security in Depth.

Next: see 02-controls-landscape.md for a per-primitive inventory of what exists today and where the genuine wedge gaps sit. See 03-maturity-model.md for a customer-facing maturity scorecard. See 07-build-vs-buy.md v0.2 for the build-vs-buy investment plan.