OWASP 2026 Compliance Matrix — brain-server (v1.27.12 “Agentic”)

Last reviewed: 2026-09-09 against the two 2026 OWASP agentic frameworks (rows below were first drawn up at v1.27.12; the dated addendum after Part 2 carries the deltas the v1.28.63–.76 hardening line shipped — the row statuses stay, the addendum extends them).

Provenance of the two dates above, stated because they are hand-typed.

• 2025-12-09 for the Agentic edition is a REPO-INTERNAL RECONCILIATION, not a publisher-verified fact: this file previously said 2025-12-10 while COMPLIANCE.md and docs/MEMGHOST_MITIGATION.md both said 2025-12-09. The majority and the audit agree on the 9th, so the odd file was corrected to match. The publisher page is not reachable from a build, so this is the best available reading and is labelled as such rather than asserted as verified.
• 2026-08-04 for the LLM edition is left unchanged deliberately. Seven sources in this repo carry it, backed by a live fetch recorded at docs/SECURITY_AUDIT_20260912_FOURTH_PASS.md:119 (“REAL and EXACT”, with the DOI above). An audit leg proposed 2026-08-03 with no source in the tree; a DOI-backed claim is not swapped for an unsourced one. Resolving it needs a fetch against the publisher, not a repository edit.

This is the buyer/auditor artifact: every control carries a status — Shipped vX.Y (with the exact feature), or Ceiling v2.x (a documented residual-risk decision with an owner). The framework’s own position (2026) is that prompt injection has no prevention — there is no engineering fix (NIST 2025 / NCSC 2025 / Debenedetti et al. 2025 agree) — so this matrix’s standard is 100% control coverage, not 100% risk elimination: every control has either a named implementation or a documented, owned residual-risk decision. That is the audit-ready form of “hardened.”

Companion: SECURITY.md (ZT4AI posture, §), COMPLIANCE.md (§observability playbook), THREAT_MODEL.md.

Part 1 — OWASP GenAI LLM Top 10:2026 (LLM01–LLM10)

Ranking is incident-grounded (~10,000 real incidents; first edition, not expert votes). LLM01’s mitigation list is the load-bearing set for this stack (least-privilege policy engine, invisible-char strip at every ingest+render boundary, provenance-labeled channel, explicit human confirmation surfacing the exact action, Rule of Two, memory writes as privileged operations, MCP/tool supply-chain pinning). The 2026 MCP-defense literature converges on the same shape: SHIELDMCP (ACL 2026 — per-run tool-description hashes, parameter validation, response wrapping with instruction detection) matches the catalog pins plus the single-block tool-result envelope; Arcjet’s trusted-guidance vs untrusted-evidence split matches the fence plus per-hit provenance; the April-2026 MCP incident wave (Unit42 taxonomy, Microsoft XPIA advisory) confirms sanitize plus classify as the current state of the art, which is what the screen plus optional local classifier implements.

Part 2 — OWASP Top 10 for Agentic Applications:2026 (ASI01–ASI10)

Incident names OWASP cites: EchoLeak (goal hijack), Amazon Q (tool misuse), GitHub MCP exploit (supply chain), AutoGPT RCE (code exec), Gemini memory attack (memory poisoning), Replit meltdown (rogue agents).

Dated addendum — 2026-09-23 (the DecisionModel seam, v1.32.10)

The decision-harness seam landed as types + tests only (the DecisionModel trait in the always-on SDK decision module; the kernel’s workflow::harness consumes it with a deterministic reference model and the decide adapter). No routes, no state change, no learned models — the v1.32.8 gate is untouched. The type-level controls:

Dated addendum — 2026-09-23 (the Decision Harness engine, v1.32.11 part 1 — engine only)

The harness’s deterministic pipeline engine landed as code + tests only (the config document with canonical hashing, the pure stage runner with per-stage provenance records, the additive run-trace table + session-log kinds’ writer). No routes, no learned models, no inference — the v1.32.8 gate is untouched. The engine-level controls:

The AI-law note (code vs legal, deliberately not overstated): automatic per-run traces with immutable references — input/context digests, config hash, model digests, retrieval parameters, a compile-time environment fingerprint — are the TECHNICAL LOGGING CAPABILITY behind EU AI Act Art. 12(1)-style automatic event recording (high-risk obligations generally apply from 2026-08-02; the deployer-side retention duty, e.g. the six-month minimum, is the deployer’s, not the software’s) and keep GDPR Art. 22-style transparency consistent (a decision trace an operator can replay and inspect). This round ships the capability and its tests; it makes NO legal conclusion — whether any given deployment is in scope of those regimes is the operator’s determination with counsel.

Dated addendum — 2026-09-24 (the Decision Harness surfaces, v1.32.11 part 2 — routes + enforcement)

The harness’s public-safe route face landed: execute a run, read its stored trace, replay it under its own recorded conditions, and the DPO-gated listing — plus the gate-side enforcement of the mode law (an exploratory run can propose, never promote). The pipeline semantics stay the line’s private core; what is public here is route EXISTENCE and the authz posture. The surface-level controls:

The AI-law note, continued (code vs legal, no legal conclusions): the trace READ surface — a bounded, audited, role-gated route returning the stored trace document — is the ACCESS side of the same Art. 12-style logging capability shipped earlier on this line (the high-risk obligations regime generally applies from 2026-08-02 for in-scope systems; deployer retention remains the deployer’s duty, not the software’s). Shipping access control around log inspection is a technical control; it makes NO legal conclusion about any deployment’s regulatory scope — that determination stays the operator’s, with counsel.

Dated addendum — 2026-09-24 (the model registry: identity, lifecycle, and oversight)

The model registry is a technical control plane for model identity and human disposition. It does not store weights or evaluation contents, and it does not decide whether a particular deployment is legally in scope. The rows below describe shipped code controls, not a legal conclusion.

The human-approved lifecycle is an engineering analogue to an oversight-and-recordkeeping pattern, not a claim that a registry satisfies any particular legal provision. The EU AI Act’s official text describes Article 12 automatic event recording and Article 14 human oversight, and states a general application date of 2 August 2026 (with specified provisions applying earlier); those dates and obligations are a legal source, not a classification of this software. Whether a deployment is high-risk, who is the provider/deployer, and what retention or records apply remain operator-and-counsel determinations.

Dated addendum — 2026-09-24 (decision evaluation records, schema 1.32.14)

R30 adds a bounded decision-evaluation record, not an authoritative judgment oracle. The only accepted source in this round is an operator-declared, non-authoritative manifest whose case and manifest digests are checked against persisted decision traces. QC/GDL gold packs are not decision labels, and missing metric legs are not represented as zero. The controls below describe shipped technical behavior only.

The technical audit receipt and evaluation record are evidence mechanisms, not legal conclusions. The official EU AI Act text describes logging and human oversight obligations in its own scope; NIST AI 600-1 and the OWASP Agentic Security Initiative provide risk/security guidance. They do not determine whether a deployment is high-risk, who is provider versus deployer, or which retention, documentation, lawful-basis, consent, or jurisdiction-specific duties apply. Those remain operator-and-counsel decisions.

Dated addendum — 2026-09-25 (Shell M6-S0 contract integrity)

R31 hardens the shell boundary without adding a product surface or changing the kernel wire contract. The generated TypeScript client is synchronized only by an explicit generation step; ordinary tests and builds are non-mutating, and CI byte-compares a temporary regeneration against the committed output. The render-boundary sanitizer uses the same closed invisible-scalar membership as the canonical fixture and server Rust implementation, with exhaustive tests, visible-sample preservation, and idempotence. The shell workflow is triggered by contract/fixture changes, grants read-only repository permission, pins external actions, installs the declared Linux/Tauri/Rust prerequisites, and runs the real dedicated-port Chromium and WebKit e2e suite without bypassing WebKit CSP.

For later M6 work, R30’s evaluation record is a checked audit acceptance over an explicitly operator-declared, non-authoritative manifest. It has no generic evaluation signature field and no separate judgment registry. This entry records technical controls and dated source context only; it makes no legal, compliance, release, or public-publication determination. Provider/deployer status, regulatory scope, retention, documentation, and jurisdiction-specific duties remain operator-and-counsel decisions.

Dated addendum — 2026-09-25 (R33 — registry lifecycle contract integrity)

R33 records the technical controls around the existing registry row and the registry_lifecycle proposal contract. This addendum makes no legal or compliance claim.

Dated addendum — 2026-09-25 (R34 — GDL provider boundary hardening)

R34 records technical controls at the existing GDL launch seam. It is not a certification, legal conclusion, conformity claim, or risk-elimination claim.

Dated addendum — 2026-09-25 (R35 — GDL launch execution integrity)

R35 records technical controls around the existing GDL execution and settlement seams. This addendum is dated engineering and risk context only. It is not a certification, legal conclusion, conformity claim, high-risk classification, risk-elimination claim, or release/publication decision.

The dated standards and legal materials used for R35 are engineering context. They do not determine provider/deployer status, regulatory scope, conformity, or any jurisdiction-specific obligation. Those remain operator-and-counsel decisions.

Part 3 — AIUC-1 crosswalk (procurement bridge)

A crosswalk maps ASI01–ASI10 to the AI-Under-Contract (AIUC-1) requirements so procurement can bridge the OWASP agentic list to a contractual requirement set instead of maintaining two separate controls. The crosswalk is directional: each ASI control satisfies the AIUC-1 requirement it names; the reverse mapping is not claimed. Deployers drafting a contract can cite the ASI rows above as the control-evidence for the corresponding AIUC-1 clause.

Part 4 — Residual risk (the “100%” answer, named with owners)

These are the honest ceilings every control list converges on. Each is a documented residual-risk decision with an owner, not an omission.

Bottom line. “100% hardened” = 100% control coverage, not 100% risk elimination. The residual-risk section is the truthful statement an auditor can sign.