@tyroneross/build-loop 0.30.3

package/skills/security-methodology/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: build-loop:security-methodology
+description: "Use when a build crosses a security boundary (auth, authz, secrets handling, network exposure, persistence of sensitive data) or when Phase 1 Assess flags `triggers.riskSurfaceChange: true`. Provides the threat-modeling and scoped-permission methodology for build-loop's security-reviewer agent."
+version: 0.1.0
+user-invocable: false
+---
+
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# Security Methodology
+
+This is the canon the `security-reviewer` agent grades against, and the canon the `defenseclaw-bridge` skill maps to runtime config. It is **not** a runtime defense layer: it does not block prompts, it does not rewrite outputs, it does not replace DefenseClaw / NeMo Guardrails / Llama Guard. It tells you (a) what risk classes exist, (b) how to detect them by reading code, and (c) which IDs from which framework apply.
+
+## When to load
+
+- **Auto-loaded** by `agents/security-reviewer.md` in Phase 4 Review sub-step A whenever Assess flagged `triggers.riskSurfaceChange: true`.
+- **Auto-loaded** by `skills/defenseclaw-bridge/SKILL.md` after Phase 3 Execute when the build produced agent-builder-style artifacts (`tool-contract.md`, `agent-manifest.md`, `guardrail.md`).
+- **User-invocable** standalone: ask "what are the security concerns for this design", "give me the OWASP threat model for this", "which ASI risks does this surface", and the orchestrator should `Skill("build-loop:security-methodology")`.
+
+This skill is **knowledge only**. It writes nothing. It performs no scans. The grading logic lives in `security-reviewer`; the runtime mapping lives in `defenseclaw-bridge`.
+
+## What this skill ships
+
+| File | Contents |
+|---|---|
+| `references/owasp-llm-top-10.md` | LLM01–LLM10, full names + detection patterns (what code/config/diff signals each risk) |
+| `references/owasp-agentic-top-10.md` | ASI01–ASI10, full names + detection patterns. Verified labels per OWASP GenAI Security Project, 2025-12-09 release |
+| `references/owasp-web-top-10.md` | A01, A03, A06, A10 — the four web risks most relevant to LLM-backed apps. Other six referenced, not enumerated |
+| `references/mitre-atlas-starter.md` | Pointer to atlas.mitre.org + ~12 starter ATLAS techniques most relevant to product-dev agents. Cite by ID; not re-authored |
+| `references/nist-600-1-mapping.md` | Seven engineering-relevant NIST AI 600-1 risk areas mapped to OWASP IDs. The other five (CBRN, Environmental, IP, Obscene, Violent) are referenced as policy-level |
+| `references/cross-source-matrix.md` | The single decision table: row = risk class, columns = OWASP LLM / OWASP Agentic / NIST 600-1 / DefenseClaw control |
+
+The cross-source matrix is the **load-bearing artifact**. Every finding from `security-reviewer` cites a row in this matrix; every config row from `defenseclaw-bridge` traces back to one.
+
+## Structure of the canon (reading order)
+
+If you have time for one file, read `cross-source-matrix.md`. It tells you which framework owns which risk and how the frameworks line up. If you have time for two, read the matrix and the OWASP Agentic file — that's where most production-grade agent risk lives in 2026.
+
+If you're grading a diff (as `security-reviewer` does):
+
+1. Open `cross-source-matrix.md` and find the row for the risk class the diff might surface.
+2. Open the `owasp-*.md` reference for the framework cited in that row's first column — its **detection patterns** section names the code/config shapes that are evidence of the risk.
+3. If the framework cited is OWASP LLM, also check the OWASP Agentic row alongside it — agentic risks **stack on top of** LLM risks (an agent that calls an injected LLM is two risks, not one).
+4. NIST 600-1 is the regulator-facing framework. Map findings to NIST areas at the end, not at the start. NIST is for the report, not the detection.
+5. MITRE ATLAS is adversary-perspective — useful for red teams, secondary for build-time review. Cite by technique ID only when it sharpens a finding's evidence.
+
+## Verified scope (what this canon **does** cover)
+
+- Build-time, code-readable risk: prompt construction, tool surfaces, identity/privilege boundaries, supply-chain points of trust, persistent memory, code-execution paths, HTTP boundary at the LLM.
+- Cross-source mapping so a single finding can be cited in OWASP, NIST, ATLAS without translation.
+- Detection patterns specific enough to grep for in a diff (e.g., "user input concatenated into a system prompt" → LLM01 detection signal).
+
+## Out of scope (what this canon **does not** cover)
+
+- Runtime enforcement code. That lives in DefenseClaw / NeMo / Llama Guard / your own gateway. The `defenseclaw-bridge` skill maps from this canon to DefenseClaw config; mapping to NeMo or Llama Guard is left to project-specific bridges.
+- Model theft (LLM10) at the deployment level. Agent-builder-style apps don't host weights.
+- CBRN, environmental, IP, obscene, and violent content from NIST 600-1 — those are policy/legal concerns, not engineering. They're referenced for completeness in `nist-600-1-mapping.md` but not deeply mapped.
+- The full MITRE ATLAS taxonomy. ATLAS has 16 tactics and 84 techniques as of v5.1.0 (Nov 2025) plus 14 agentic additions (Feb 2026). Re-authoring it would duplicate the project; the starter file points at the source.
+- Adversarial test corpora. Red-team corpora are out of build-loop's scope per `~/dev/research/topics/product-dev/product-dev.agentic-systems-original-synthesis.md` recommendation #4.
+
+## Where these references come from
+
+This skill packages and cross-maps four authoritative sources. Each reference file inside `references/` cites its own source. The canonical research file with full citation, retrieval dates, source tier, and the original cross-source matrix lives at:
+
+- `~/dev/research/topics/product-dev/product-dev.agentic-systems-security-references.md` — the verified canon. T1 sources throughout (OWASP project pages, NIST publication, MITRE ATLAS, Cisco DefenseClaw repo).
+
+The companion **gap analysis** that motivated shipping these artifacts inside build-loop:
+
+- `~/dev/research/topics/product-dev/product-dev.agentic-systems-original-synthesis.md` — recommendations table (security-related: #4 red-team playbook, #10 cost-budget enforcement, plus the new "govern/inspect/prove" recommendation).
+
+The agent-builder methodology that this skill cross-references when classifying agentic risks (autonomy ladder A0–A4, permission tiers T0–T5, role decomposition):
+
+- `~/dev/git-folder/agent-builder/plugin/references/methodology/13-agentic-product-dev-synthesis.md` — single canonical synthesis, A0–A4 autonomy ladder.
+- `~/dev/git-folder/agent-builder/plugin/references/templates/agentic-handoff/` — 15 template files; the security-relevant subset is `tool-contract.md`, `agent-manifest.md`, `guardrail.md`, `system-boundary.md`, `flow-topology.md`, `role-card.md`.
+
+If the agent-builder plugin is not installed locally, the research-folder pointer above is sufficient — file 13's substance is reproduced in the addendum-v2 research file (`~/dev/research/topics/product-dev/product-dev.agentic-systems-template-pack-addendum-v2.md`).
+
+## Relationship to other build-loop skills
+
+| Skill | Relationship |
+|---|---|
+| `agents/security-reviewer.md` | Consumes this skill's references as its grading rubric. |
+| `skills/defenseclaw-bridge/` | Maps this skill's risk IDs to DefenseClaw config rows + Rego policy stubs. |
+| `skills/plan-verify/` | The `risk-surface-change-without-threat-model` rule references this skill — every Phase 2 plan that touches a risk surface must point at a threat-model artifact (or this skill if no project-specific artifact exists). |
+| `skills/build-loop/` | The orchestrator's Phase 1 Assess scans the goal and file list for risk-surface signals; if any fire, it sets `triggers.riskSurfaceChange: true`, which routes both `security-reviewer` (Phase 4-A) and the `risk-surface-change-without-threat-model` plan-verify rule (Phase 2). |
+
+## Risk-surface trigger signals (what flips `riskSurfaceChange: true`)
+
+Phase 1 Assess sets the flag when any of these are introduced or modified:
+
+- A new tool, MCP server, plugin, or skill (LLM07, ASI02, ASI04).
+- A new LLM call or change to an existing prompt that ships in production (LLM01, ASI01, ASI06).
+- New persistent memory or vector store (ASI06, NIST Info Integrity).
+- An auth, authz, identity, or permission boundary change (LLM07, ASI03, A01).
+- An external API call introduced by the build (LLM05, ASI04, A06, A10).
+- Handling of new user data classes — PII, financial, health, credentials, regulated records (LLM06, NIST Data Privacy).
+
+The orchestrator scans the goal text for keywords matching these classes and inspects the planned file set. Either signal flips the trigger; the trigger is sticky for the rest of the build.
+
+## Limitations
+
+- ⚠️ OWASP Agentic Top 10 (2026) is a 2025-12-09 release; the published PDF was inspected for the labels but field practice with this taxonomy is still early. Treat ASI01–ASI10 as "the best framing available", not "the field's settled answer".
+- ⚠️ MITRE ATLAS technique enumeration is summarized, not re-authored. Always check `https://atlas.mitre.org/` for the current technique catalog before citing a specific technique in a finding.
+- ⚠️ NIST AI 600-1 is a profile, not a regulation. Regulatory regimes (EU AI Act, US executive orders, sectoral rules) cite NIST but add their own requirements. This skill does not track regulatory regimes; pair with project-specific legal review when one applies.
+- ⚠️ The cross-source matrix has known gaps. ASI07 (insecure inter-agent communication) does not have a clean DefenseClaw mapping because the runtime control surface for A2A trust is still an industry-open problem. The matrix marks this row `(gap)` rather than papering over it.

package/skills/security-methodology/references/cross-source-matrix.md

@@ -0,0 +1,77 @@
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# Cross-Source Risk Matrix
+
+Single decision table mapping each risk class to its OWASP LLM ID, OWASP Agentic ID, NIST 600-1 risk area, and the DefenseClaw runtime control that implements the operational defense (when one exists).
+
+**Use.** This is the load-bearing artifact of the security-methodology skill. The `security-reviewer` agent cites a row from this matrix in every finding. The `defenseclaw-bridge` skill maps from this matrix to DefenseClaw config rows.
+
+**Source.** Adapted from `~/dev/research/topics/product-dev/product-dev.agentic-systems-security-references.md` §"Cross-source map: where each risk lives". The research file is the canonical citation trail; this file is the build-loop-internal copy.
+
+## Reading conventions
+
+- Cells with **two or more IDs** mean both apply (the risk lives in both frameworks; cite both).
+- `(implicit X)` means the framework doesn't have a top-level entry but the risk is covered indirectly under X.
+- `(n/a)` means the framework genuinely doesn't address the row.
+- `(gap)` in the DefenseClaw column means there is no clean general-purpose runtime control yet — surface as a known unknown rather than paper over.
+- `(operational)` means the row is operational concern (cost, deprecation, fleet management) that DefenseClaw doesn't claim to cover.
+
+## The matrix
+
+| Risk class | OWASP LLM | OWASP Agentic | NIST 600-1 | DefenseClaw control |
+|---|---|---|---|---|
+| Prompt injection (direct user input) | LLM01 | ASI01 | Information Security | Inspect (pre-call scan) |
+| Prompt injection (indirect — tool output, RAG, file content) | LLM01 + LLM07 | ASI01 + ASI06 | Information Security + Information Integrity | Inspect (pre-call + post-call) |
+| Output trusted as input (XSS / SQLi / RCE via model output) | LLM02 | ASI05 | Information Security | Inspect (post-call sanitize) |
+| Excessive agency (more tools / autonomy / scope than needed) | LLM08 | ASI02 + ASI03 | Human-AI Configuration | Govern (admission) + policy gates |
+| Identity / privilege abuse | LLM07 | ASI03 | Information Security | Govern (least-privilege) + Inspect (auth checks) |
+| Tool / plugin insecure design | LLM07 | ASI02 | Information Security + Value Chain | Govern (skill / MCP scanner) |
+| Supply chain (model, tool, MCP, plugin, A2A peer) | LLM05 | ASI04 | Value Chain | Govern (admission scanner) |
+| Memory & context poisoning | (implicit LLM01) | ASI06 | Information Integrity | Govern (skill scan) + Inspect (post-call) |
+| Inter-agent communication (spoofing, weak trust, no identity) | (n/a) | ASI07 | Information Security | (gap) |
+| Cascading failures (output → input across agents) | LLM02 (downstream) | ASI08 | Information Integrity + Human-AI Configuration | Inspect + circuit breakers |
+| Human-agent trust exploitation (over-confident explanations) | LLM09 | ASI09 | Human-AI Configuration | Audit (Prove) for review sampling |
+| Rogue / misaligned agent (compromised or drifted) | (implicit LLM03) | ASI10 | Information Integrity | Govern (continuous re-scan) + kill-switch |
+| Sensitive info disclosure (secrets / PII / training data leakage) | LLM06 | (covered in ASI06 / ASI09) | Data Privacy + (IP — policy-level) | Inspect (post-call PII / secrets scan) |
+| Model DoS / cost runaway | LLM04 | (operational) | (operational) | Inspect (rate limits, budgets) |
+| Model theft (weights / architecture) | LLM10 | (operational) | (IP — policy-level) | (out of agent-builder scope) |
+| Unsafe code execution | LLM07 | ASI05 | Information Security | Govern (CodeGuard) + Sandbox |
+| Confabulation (hallucinated facts) | (indirect LLM09) | (n/a) | Confabulation | Audit (Prove) — review sampling for fact claims |
+| Harmful bias / homogenization | (n/a — content) | (n/a) | Harmful Bias and Homogenization | (project-specific eval; no DefenseClaw analog) |
+
+**Reading the matrix.** Every engineering-relevant row has at least three sources. ASI07 is the row where DefenseClaw doesn't yet have a general solution — consistent with the broader industry state, which is still working out A2A trust models. That `(gap)` is a *known unknown* worth surfacing in findings, not papering over.
+
+## How a finding cites a row
+
+A `security-reviewer` finding always includes a `mapped_risks` array drawn from the second and third columns of this matrix. Format:
+
+```json
+{
+  "id": "SEC-007",
+  "severity": "HIGH",
+  "title": "Tool output flows into agent prompt without sanitization",
+  "mapped_risks": ["LLM01", "LLM07", "ASI01", "ASI06"],
+  "evidence": "src/agents/researcher/loop.ts:88-104",
+  "snippet": "...prompt += `\\nTool result:\\n${toolResult.text}`...",
+  "recommendation": "Wrap tool output in a delimited 'untrusted-tool-output' block and add a post-call output validator before the result re-enters the next loop iteration."
+}
+```
+
+When the finding is being prepped for an audit-grade report, add NIST cite:
+
+```json
+"mapped_risks": ["LLM01", "LLM07", "ASI01", "ASI06", "NIST:Information Integrity"]
+```
+
+The `NIST:` prefix disambiguates from OWASP IDs.
+
+## How `defenseclaw-bridge` maps a row
+
+The bridge skill reads this matrix in reverse: given a project's tool-contract, agent-manifest, and guardrail artifacts, it identifies which rows the project surfaces, then writes a DefenseClaw config row for each surfaced risk. The mapping lives at `skills/defenseclaw-bridge/references/dc-config-mapping.md`.
+
+## Limitations
+
+- ⚠️ The matrix is **build-time descriptive**, not runtime prescriptive. A row's DefenseClaw column names a control that *fits* the risk, not one that *is configured* in any specific project. Configuration lives in `defenseclaw-bridge`'s output.
+- ⚠️ Some rows (Inter-agent comms, Bias, Confabulation) genuinely have no clean DefenseClaw mapping. The `(gap)` and `(project-specific eval)` markers are honest, not placeholders.
+- ⚠️ The OWASP Agentic Top 10 (2026) is a recent release; the matrix's mapping reflects a year of community discussion, not a decade of field experience. Treat IDs as "the best framing available", not "settled answer".
+- ⚠️ NIST 600-1 has twelve risk areas; this matrix maps only the seven engineering-relevant ones (per `nist-600-1-mapping.md`). The other five (CBRN, Dangerous/Violent, Environmental, IP, Obscene) are policy-level and not in this matrix.

package/skills/security-methodology/references/mitre-atlas-starter.md

@@ -0,0 +1,83 @@
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# MITRE ATLAS — Starter Subset for Product-Dev Agents
+
+ATLAS is to AI what ATT&CK is to enterprise security: an adversary-perspective tactic/technique catalog with case studies. **Designed for red teams, threat hunters, and detection engineers — not for developers writing prompts.** This file does not re-author ATLAS; it points at the source and lists ~12 starter techniques that are the most relevant to product-dev agents at build-time review.
+
+**Source.** `https://atlas.mitre.org/` — T1, MITRE-published, government and Fortune 500 adoption. Retrieved 2026-05-02.
+
+## Current scope (Nov 2025 v5.1.0 + Feb 2026 update)
+
+- 16 tactics (top-level adversary goals)
+- 84 techniques (specific attack methods)
+- 32 mitigations
+- 42 case studies, including:
+  - Microsoft 365 Copilot insider exploitation
+  - Hugging Face organization-confusion supply-chain attack
+  - Multi-step financial-transaction hijacking through assistant-as-insider patterns
+- 14 new techniques specifically for AI Agents and GenAI from the Zenity Labs collaboration (Oct 2025)
+
+**Always check the live ATLAS catalog before citing a specific technique ID.** This file is a starter map, not a snapshot.
+
+## When to cite ATLAS in a security-reviewer finding
+
+Cite an ATLAS technique by ID when one of these is true:
+
+1. The finding describes an **attack path** (how an adversary would exploit), not just a defect. Example: "user input flows into a system prompt — ATLAS technique for prompt injection."
+2. The project has a red team / pen test program and is tracking findings by ATLAS ID.
+3. The finding is being prepped for an audit report that requires standardized adversary taxonomy.
+
+**Skip ATLAS** when the finding is straightforwardly an OWASP LLM/Agentic ID. Don't double-cite for the same content; pick one. ATLAS is the *adversary* lens; OWASP is the *application* lens.
+
+## Starter technique map
+
+The list below is illustrative. Each line names a class of attack, points at the ATLAS tactic family, and lists the OWASP IDs that already cover the same risk. **Always look up the live technique IDs at `https://atlas.mitre.org/` before quoting an ID in a finding** — the catalog evolves and snapshot lists go stale.
+
+| Attack class | ATLAS tactic family | OWASP cross-map |
+|---|---|---|
+| Direct prompt injection (user input) | Initial Access / Execution | LLM01, ASI01 |
+| Indirect prompt injection (RAG, web content, tool output) | Initial Access / Persistence | LLM01 + LLM07, ASI01 + ASI06 |
+| Adversarial example to bypass guardrails | Defense Evasion | LLM01 |
+| Tool-call manipulation via crafted tool descriptions or schemas | Initial Access / Execution | ASI02, LLM07 |
+| Memory-poisoning attacks across sessions | Persistence | ASI06 |
+| Sandbox escape from code interpreter | Privilege Escalation / Execution | ASI05, A03 |
+| Multi-step financial-transaction hijacking (assistant-as-insider) | Impact | ASI03, ASI09 |
+| Model repository organization-confusion (Hugging Face case) | Initial Access / Resource Development | LLM05, ASI04, A06 |
+| Exfiltration through tool side channels | Exfiltration | LLM06 |
+| Cost / resource exhaustion | Impact | LLM04 |
+| Output-channel exfiltration (markdown image rendering, link leakage) | Exfiltration | LLM06, LLM02 |
+| Model theft via API querying | Collection / Exfiltration | LLM10 |
+
+## Why ATLAS is secondary, not primary, for build-time review
+
+ATLAS is most valuable for:
+
+- **Red-team test design** — what attacks should the offensive testing program try? ATLAS gives you the menu.
+- **Detection engineering** — what telemetry would I need to see this attack? ATLAS lists the observable signals.
+- **Incident response taxonomy** — "we saw this attack class" should map to a standard ID for postmortems and audits.
+
+It's secondary for **build-time review** because most ATLAS techniques are already framed as defects in the OWASP LLM/Agentic Top 10. A finding cited as "LLM01 + ASI01" is more discoverable to a developer than "ATLAS T15.001 + T1606" — the developer is going to look up the OWASP ID anyway.
+
+The exceptions where ATLAS adds value at build time:
+
+- **Memory poisoning** — ATLAS has more granular technique IDs for *how* the poisoning happens (e.g., adversarial training data vs. RAG-corpus injection vs. session-state tampering). When a finding needs that granularity, cite ATLAS.
+- **Supply-chain organization-confusion attacks** — ATLAS captured the Hugging Face case study with specific technique IDs. When the finding involves a model registry attack, ATLAS is the cleanest citation.
+- **Tool-call manipulation via schema crafting** — Newer technique class added in the Feb 2026 update. ATLAS is the only published taxonomy that names this distinct from generic prompt injection.
+
+## What this file does not contain
+
+- The full ATLAS taxonomy (16 tactics × 84 techniques + 14 agentic additions). Re-authoring it would duplicate the project. Always pull from the source.
+- ATLAS mitigations enumeration. ATLAS publishes 32 mitigations alongside the techniques; for the canonical list, see the source.
+- Case studies. Eight pages of context per case study live at the source; quoting them inline would just be a copy.
+
+## Limitations
+
+- ⚠️ Technique IDs are stable in ATLAS, but the catalog evolves. The "Feb 2026 update" referenced above adds techniques; pre-update finding IDs may still be valid but their parent tactic could be reorganized. Always pull live before citing.
+- ⚠️ The OWASP/ATLAS overlap is not 1:1. Some ATLAS techniques have no OWASP analogue (e.g., specific data-poisoning training-pipeline attacks); some OWASP IDs map to multiple ATLAS techniques. The cross-map column above is an approximation, not an authoritative mapping.
+- ❓ The Zenity Labs additions (Oct 2025, 14 agentic techniques) were verified as a count at canon time; the full ID list and mappings are pending future updates.
+
+## Quick reference link
+
+For the canonical tactic list, technique catalog, mitigations, and case studies, follow:
+
+`https://atlas.mitre.org/` → Matrices → AI/ML matrix.

package/skills/security-methodology/references/nist-600-1-mapping.md

@@ -0,0 +1,119 @@
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# NIST AI 600-1 — Engineering-Relevant Risk Areas
+
+NIST AI 600-1, "Artificial Intelligence Risk Management Framework: Generative AI Profile" (July 2024), is the GenAI-specific companion to AI RMF 1.0. **Not a regulation** — but as the most detailed government-published GenAI risk framework, it has become the de facto reference for regulators, auditors, insurers, and enterprise procurement.
+
+**Source.** `https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf` — T1, NIST publication. Retrieved 2026-05-02.
+
+NIST 600-1 names twelve risk areas. **Seven are engineering choices** (you can change them by changing the build); five are policy / legal / content-moderation concerns that engineering can support but cannot single-handedly resolve. This file maps the seven engineering-relevant areas to OWASP IDs and notes the boundary on the other five.
+
+## The four NIST functions (lifecycle frame)
+
+NIST 600-1 organizes work around four functions that map cleanly onto build/operate:
+
+| Function | What it does | Build-loop phase analogue |
+|---|---|---|
+| **Govern** | Policies, accountability, oversight, AI usage policies. | Out of scope for build-loop (org policy concern). |
+| **Map** | Risk identification, use cases, intended purpose, stakeholders, data sources, supply-chain dependencies. | Phase 1 Assess + threat-model artifact. |
+| **Measure** | Testing for hallucinations, bias, privacy leaks, security, environmental impact. | Phase 4 Review (validate + fact-check + security-review). |
+| **Manage** | Post-deployment monitoring, appeal/override mechanisms, incident response, recovery, change management, deactivation. | Out of build-loop scope (runtime), but artifacts reference it. |
+
+The build-time security review covers **Map** and **Measure** for the seven engineering-relevant risk areas below.
+
+## Engineering-relevant risk areas (7)
+
+### 1. Information Security
+
+**What NIST means.** Confidentiality, integrity, availability of the AI system itself and the data it handles.
+
+**Build-time signals.** Authentication, authorization, encryption-in-transit, secrets handling, secure tool design, sandbox boundaries.
+
+**OWASP cross-map.** LLM05 (Supply Chain), LLM06 (Sensitive Info Disclosure), LLM07 (Plugin Design), LLM08 (Excessive Agency), ASI02 (Tool Misuse), ASI03 (Privilege Abuse), ASI04 (Supply Chain), ASI05 (Code Execution), ASI07 (Inter-Agent Comms), A01 (Access Control), A03 (Injection), A06 (Vulnerable Components), A10 (SSRF).
+
+### 2. Information Integrity
+
+**What NIST means.** Trustworthiness of the information the AI produces and consumes — provenance, factuality, resistance to manipulation.
+
+**Build-time signals.** Prompt-vs-data delimiters, retrieval provenance, memory-write integrity, output-validation paths, signature/hash on inputs.
+
+**OWASP cross-map.** LLM01 (Prompt Injection), LLM03 (Training Data Poisoning), ASI01 (Goal Hijack), ASI06 (Memory Poisoning), ASI08 (Cascading Failures), ASI10 (Rogue Agents).
+
+### 3. Data Privacy
+
+**What NIST means.** Personal data, regulated data classes, consent, scoping, retention, redaction.
+
+**Build-time signals.** Redaction in prompt construction, scoped data access in tools, retention of conversation history, audit logging that doesn't leak the data being audited.
+
+**OWASP cross-map.** LLM06 (Sensitive Info Disclosure). Pairs at the boundary with LLM07 (Plugin Design — tool data access scope) and ASI03 (Privilege Abuse — wrong identity reading data).
+
+### 4. Value Chain and Component Integration
+
+**What NIST means.** Risks introduced by third-party models, datasets, tools, MCP servers, plugins, libraries — the dependency graph.
+
+**Build-time signals.** Pinning, signing, install-source verification, scanner gates on new dependencies, lockfiles committed.
+
+**OWASP cross-map.** LLM05 (Supply Chain), ASI04 (Agentic Supply Chain), A06 (Vulnerable Components).
+
+### 5. Human-AI Configuration
+
+**What NIST means.** How humans interact with the AI: what they're shown, what they approve, when they can override, calibration of trust.
+
+**Build-time signals.** Approval UX design, evidence-vs-explanation surfacing, override paths, clear "this is generated" framing, autonomy-level boundaries.
+
+**OWASP cross-map.** LLM08 (Excessive Agency), LLM09 (Overreliance), ASI09 (Human-Agent Trust Exploitation).
+
+### 6. Confabulation
+
+**What NIST means.** The model produces plausible-sounding outputs that are factually wrong (the technical term for hallucination at the policy layer).
+
+**Build-time signals.** Eval coverage on factual claims, output-validation paths for high-stakes assertions, citation requirements, confidence calibration.
+
+**OWASP cross-map.** Indirectly LLM09 (Overreliance — humans trusting confabulations). Cross-cuts the design intent of `agents/fact-checker.md` in build-loop.
+
+### 7. Harmful Bias and Homogenization
+
+**What NIST means.** Outputs that are systematically biased against subgroups, or that reduce diversity in some downstream measure.
+
+**Build-time signals.** Eval coverage across demographic / subgroup slices, monitoring for output-distribution drift, bias-aware prompt design.
+
+**OWASP cross-map.** No direct OWASP analog — bias is its own concern. Build-loop's `fact-checker` and `mock-scanner` agents do not deeply check bias; bias review is project-specific and typically requires labeled eval sets.
+
+## Policy-level risk areas (5) — referenced, not deeply mapped
+
+These five NIST risk areas affect what an AI system is allowed to do, not how it's built. Engineering can support guardrails for them but cannot single-handedly resolve them. Build-loop's security-reviewer flags surfaces relevant to these areas but does not grade against them.
+
+| NIST area | What it covers | Engineering boundary |
+|---|---|---|
+| **CBRN Information or Capabilities** | The AI helps a user produce chemical, biological, radiological, or nuclear weapons capability. | Provider-side filtering + content policy. Engineering can disallow specific tool surfaces (e.g., no chemistry calculation tools), but the substantive control is content-policy-shaped. |
+| **Dangerous, Violent, or Hateful Content** | The AI produces or facilitates such content. | Provider-side filtering + content policy. |
+| **Environmental Impacts** | Compute / energy / water consumption. | Engineering can use smaller models, cache aggressively, but the substantive accounting is ops-shaped. |
+| **Intellectual Property** | The AI reproduces copyrighted material, leaks trade secrets, or trains on unlicensed corpora. | Engineering can scope data access, but the substantive control is licensing/legal. |
+| **Obscene or Degrading Content** | The AI produces such content. | Provider-side filtering + content policy. |
+
+For these five, the security-reviewer should:
+
+- **Flag** when a build introduces a surface that materially expands the attack surface of one of these (e.g., a tool that fetches arbitrary chemistry data, an integration that ingests potentially-copyrighted user uploads).
+- **Not grade** the content policy itself — that's a separate review track.
+
+## Companion frameworks
+
+NIST 600-1 has at least one notable agentic-specific companion:
+
+- **CSA Agentic AI NIST AI RMF Profile v1** — Cloud Security Alliance's lab-status profile mapping the agentic-specific extensions to NIST 600-1's areas. Useful for teams already aligned to NIST that need agentic-specific extensions. T2 source. ⚠️ Lab status as of canon time; revisit when CSA promotes it out of lab status.
+
+## How to cite NIST in a finding
+
+NIST citations in a build-loop security finding should:
+
+- Name the **risk area** (e.g., "NIST 600-1 §Information Integrity"), not a paragraph number — area names are stable; pagination is not.
+- Sit alongside, not in place of, the OWASP cite. NIST is the **regulator-facing** framing; OWASP is the **developer-facing** framing.
+- Appear in the Phase 4-F report when the build is being prepped for audit / procurement / regulator review. Skip in routine builds.
+
+Format: `mapped_risks: ["LLM07", "ASI03", "NIST:Information Security"]`. Inline `NIST:` prefix avoids confusion with OWASP IDs.
+
+## Limitations
+
+- ⚠️ NIST 600-1 is a profile, not a regulation. Treat it as the de-facto reference, not as a binding constraint. Regulatory regimes (EU AI Act, US executive orders, sectoral rules) may cite it but add their own requirements.
+- ⚠️ The seven-vs-five split between "engineering" and "policy" risks is this skill's editorial call, not NIST's. NIST treats all twelve as a single set; this skill separates them so a build-time review knows which it can grade and which it can only flag.
+- ❓ CSA Agentic AI NIST AI RMF Profile v1 is referenced in the canon but not deeply inspected. T2 with version pin; revisit when promoted.

package/skills/security-methodology/references/owasp-agentic-top-10.md

@@ -0,0 +1,157 @@
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# OWASP Top 10 for Agentic Applications (2026)
+
+Released 2025-12-09 by the OWASP GenAI Security Project. Orchestration-and-execution-layer risks specific to agents that plan, act, and use tools. **Complements rather than replaces** the LLM Top 10 — content-level risks (LLM01–10) still apply *inside* an agent.
+
+**Source.** `https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/` — T1, OWASP GenAI Security Project. Retrieved 2026-05-02.
+
+## Verified labels (use these exactly)
+
+The labels below were verified against the OWASP GenAI Security Project release page (T1) with secondary confirmation against the Aikido enumeration of the 2026 list. Use the IDs and full names verbatim in findings.
+
+1. **ASI01 — Agent Goal Hijack**
+2. **ASI02 — Tool Misuse and Exploitation**
+3. **ASI03 — Identity and Privilege Abuse**
+4. **ASI04 — Agentic Supply Chain Vulnerabilities**
+5. **ASI05 — Unexpected Code Execution**
+6. **ASI06 — Memory and Context Poisoning**
+7. **ASI07 — Insecure Inter-Agent Communication**
+8. **ASI08 — Cascading Failures**
+9. **ASI09 — Human-Agent Trust Exploitation**
+10. **ASI10 — Rogue Agents**
+
+## ASI01 — Agent Goal Hijack
+
+**What it covers.** Attackers redirect agent objectives by manipulating instructions, tool outputs, or external content. The agentic descendant of LLM01 plus LLM07 — same injection surface, but now the LLM acts on the injection instead of just speaking it.
+
+**Detection patterns.**
+- Agent loop that re-reads its instructions from a mutable source on each iteration (file, DB row, prior tool output).
+- "Refine the goal based on what the user / tool / search said" patterns where the goal is rewritten in-flight.
+- No instruction-vs-data delimiter when feeding tool outputs back into the agent's reasoning step.
+- A tool that returns natural language which then becomes part of the agent's planning context.
+
+**Severity calibration.** ASI01 with a tool surface above T2 (write or external-call) is almost always **HIGH** or **CRITICAL**. ASI01 in a draft-only (A1, T0–T1) agent is often **MEDIUM**.
+
+## ASI02 — Tool Misuse and Exploitation
+
+**What it covers.** Agent uses legitimate tools in unintended ways: privilege escalation through chaining, parameter abuse, unintended scopes, retry abuse, race conditions.
+
+**Detection patterns.**
+- Tool that takes a free-form parameter where the implementation does what the parameter says (path traversal, query injection, scope expansion via wildcards).
+- Tool chains where output of tool A goes directly into the call args of tool B with no schema check.
+- Tools without per-run idempotency keys (same destructive action can be replayed).
+- Permission tier on the tool weaker than the worst case its parameters allow.
+- Wildcard or regex scopes (`scope: "*"`, `path: "**/*"`) that the agent could exploit even when the spec assumed narrower use.
+
+**Severity calibration.** Tool misuse on T4/T5 tools (external comms, irreversible) is **HIGH** or **CRITICAL**. T1/T2 (read-only) misuse is usually **MEDIUM** unless it leaks data.
+
+## ASI03 — Identity and Privilege Abuse
+
+**What it covers.** Agent acts under wrong identity, escalates privilege, bypasses user-scoped authorization.
+
+**Detection patterns.**
+- Tool call that uses ambient agent credentials when the action is conceptually user-scoped (e.g., agent's GitHub token doing things the requesting user couldn't do directly).
+- No identity propagation through the agent → tool → downstream-API chain.
+- A2A (agent-to-agent) handoff that drops the original user identity.
+- Scope of "act on behalf of user X" not enforced inside the tool — the tool trusts a parameter the agent supplied to identify the user.
+- Multi-tenant data access where the tenant ID comes from agent context, not from a verified session/JWT.
+
+**Severity calibration.** Cross-tenant access is **CRITICAL** by default. Same-tenant privilege drift is **HIGH**. Self-service privilege widening (agent grants itself more scope) is **CRITICAL** — the bug compounds.
+
+## ASI04 — Agentic Supply Chain Vulnerabilities
+
+**What it covers.** Compromised models, tools, MCP servers, skills, plugins, prompt templates, A2A peers.
+
+**Detection patterns.**
+- New MCP server, skill, plugin, or agent template installed without an admission scan or install-source check.
+- Skill / plugin / prompt-template fetched from a URL or npm/PyPI package without pin (LLM05 root cause; ASI04 is the agentic consequence — full agent compromise, not just model output).
+- Trust assumed because a peer agent is "ours" — same-org A2A peers can be compromised independently.
+- Generated code committed and run without a CodeGuard-equivalent static check (secrets, dangerous exec, weak crypto, injection patterns).
+
+**Severity calibration.** Always at least **HIGH** when remediation requires re-bootstrapping the agent. **CRITICAL** when the compromised peer can act on production data.
+
+## ASI05 — Unexpected Code Execution
+
+**What it covers.** Agent or tools execute unintended code paths. Sandbox escape, unsafe deserialization, plugin RCE, attacker-controlled exec via the agent.
+
+**Detection patterns.**
+- `eval`, `exec`, `Function(...)`, `child_process.exec`, `subprocess.run(..., shell=True)`, dynamic `import` of paths derived from the agent's reasoning.
+- Code-interpreter tool exposed to the agent without a hardened sandbox.
+- Browser automation tool with un-allowlisted URL navigation.
+- Deserializer (`pickle`, unrestricted `yaml.load`, custom binary parsers) on data that came from the model or a tool.
+- File-write tool that allows arbitrary paths (path traversal, write to `~/.ssh/`, write into the project's bin or hooks).
+
+**Severity calibration.** ASI05 is usually **CRITICAL** — RCE class. Drop to **HIGH** only when a strong sandbox confines the impact.
+
+## ASI06 — Memory and Context Poisoning
+
+**What it covers.** Persistent memory or retrieved context manipulated to alter future agent behavior.
+
+**Detection patterns.**
+- Persistent agent memory store (vector DB, KV store, file-based) writable by user input without curation.
+- Memory shared across users without per-user scoping.
+- RAG corpus that ingests user-uploaded content into a shared index.
+- Memory entries with no integrity check, signature, or write-time provenance.
+- "The agent learns from each interaction" pattern with no quarantine for unverified entries.
+
+**Severity calibration.** Cross-user memory poisoning is **HIGH** or **CRITICAL** (one user can poison another's session). Single-user persistence with no integrity check is **MEDIUM** unless the memory feeds a higher-tier action.
+
+## ASI07 — Insecure Inter-Agent Communication
+
+**What it covers.** Spoofed messages between agents, weak trust between A2A peers, lack of identity propagation across agent boundaries.
+
+**Detection patterns.**
+- A2A messages (between agents inside one process or across services) with no signing, no signed envelope, no verifiable sender identity.
+- Agent-A code that trusts a `from_agent` field provided in the message body.
+- No replay protection (nonces, timestamps with windows) on inter-agent messages.
+- Inter-agent envelope without a content schema — receiver parses freeform text from sender.
+- "Critic" agent receiving the diff to review through a path attacker can also write to.
+
+**Severity calibration.** ASI07 is the row in the cross-source matrix that DefenseClaw doesn't have a clean runtime control for. Industry-open. Treat it as **HIGH** when an A2A boundary handles user data, **MEDIUM** when scoped to internal coordination only. Surface it explicitly — don't paper over.
+
+## ASI08 — Cascading Failures
+
+**What it covers.** One agent's bad output becomes another's input; failures compound through automated pipelines.
+
+**Detection patterns.**
+- Sequential agent pipeline with no validation between stages.
+- "Refine" pattern where output of one critic agent becomes the next agent's instruction with no human checkpoint.
+- Retry-on-failure that re-feeds the failed output as context for the retry (failure context can poison the retry).
+- Multi-agent loop with no convergence guard or oscillation detector.
+
+**Severity calibration.** Usually **MEDIUM** at design time (impact depends on what the cascade reaches). **HIGH** when the cascade ends in a T4/T5 action.
+
+## ASI09 — Human-Agent Trust Exploitation
+
+**What it covers.** Confident, polished agent explanations mislead human operators into approving harmful actions.
+
+**Detection patterns.**
+- Approval UX that displays the agent's natural-language explanation prominently and the underlying evidence (diff, params, tool args) in a collapsed/secondary surface.
+- No "what will actually happen" preview alongside the agent's pitch.
+- Confidence claims surfaced from the model directly without independent calibration.
+- Default-yes UX on non-trivial actions.
+- Approval flow that auto-confirms after a short delay.
+
+**Severity calibration.** Pairs with LLM09 (Overreliance). Severity tracks the action class — HIGH on T4/T5, MEDIUM elsewhere.
+
+## ASI10 — Rogue Agents
+
+**What it covers.** Compromised or misaligned agents diverge from intended behavior. Includes: agent whose model was swapped, agent whose system prompt was overwritten, agent that's been adversarially fine-tuned, agent whose tool catalog was widened post-deploy without a re-eval.
+
+**Detection patterns.**
+- Agent config (model, prompt, tool list) loaded from a writable source at runtime without integrity check.
+- No periodic re-evaluation against a pinned eval set after deploy.
+- No kill-switch: if the agent goes wrong, can it be stopped within minutes? Hours?
+- "Self-improving" agent that updates its own prompt or tool catalog without human review.
+
+**Severity calibration.** Latent risk; severity is a function of detection-and-recovery time, not of immediate exploit. Surface as **MEDIUM** with a recommendation to add the missing control (eval re-run, integrity check, kill-switch path).
+
+## Important framing
+
+Three of the top four risks — **ASI02** (Tool Misuse), **ASI03** (Privilege Abuse), **ASI04** (Supply Chain) — are about identity, tools, and delegated trust. This is consistent with the broader industry view: **the surface area of risk in agents is the surface area of their actions, not their words**. A finding that's "the model said something bad" is LLM01 — content-layer. A finding that's "the agent did something bad" is ASI01–10 — action-layer. Build-time review should weight the action-layer findings more heavily; the model is going to say something bad eventually, the question is what happens when it does.
+
+## Verification status
+
+- ✅ ASI01–ASI10 verified (T1, OWASP GenAI Security Project release page; secondary confirmation via Aikido enumeration of the 2026 list).
+- The agent system that drove this skill's creation flipped ASI02–ASI06 from `[INFERRED]` to verified during this build — see `~/dev/research/topics/product-dev/product-dev.agentic-systems-security-references.md` §Verification status for the trail.