The Play
This is the closing bookend. The engagement does not end when you reproduce a finding, it ends when the client can find it, understand the business cost, and fix it without you in the room. The report is the product. Everything before it was practice. The discipline here is mapping: every finding gets pinned to a shared vocabulary the defender already uses. OWASP LLM Top 10 gives the category and the language. MITRE ATLAS gives the adversary technique ID and, on the same site, the mitigation IDs that counter it. When you map a finding to both, you stop handing over a war story and start handing over a record that slots into the client's existing risk register and detection engineering backlog. The trust boundary you are protecting at this stage is the one between your lab and their production: nothing crosses it except an evidence-backed, mappable, fixable record.
Before the Snap
Signed scope and rules of engagement on file: this play runs against findings you already produced under authorization, so the only new thing is the paperwork, not new testing. Open three references in tabs and keep them open: the OWASP LLM Top 10 list, the ATLAS Mitigations page, and the ATLAS Case Studies page. Stand up the ATLAS Navigator (hosted instance is fine; self-host from the mitre-atlas/atlas-navigator repo if the client needs it offline) and create a fresh layer named for the engagement. Have your raw evidence in one place: prompts and responses you captured, screenshots, request and response logs, timestamps. Decide your finding ID scheme up front (for example ENG-001, ENG-002) and never reuse one. A finding ID is the join key that ties the report table, the evidence folder, and the Navigator layer together.
Run It
- For each finding, write a one-line plain-language summary of what the model did that it should not have. No tool output yet, just the behavior and why it matters.
- Classify the finding against the OWASP LLM Top 10 and record the ID (for example LLM01 prompt injection, LLM02 sensitive information disclosure, LLM06 excessive agency). One primary ID per finding; note a secondary only if the finding genuinely spans two categories.
- Map the same finding to its MITRE ATLAS technique ID using the Case Studies page to confirm the technique matches a documented real-world pattern. Record the AML.Txxxx ID and the tactic it sits under.
- Attach evidence by reference, not by dump: point each record at a stable artifact (screenshot filename, log line, captured transcript) under its finding ID. Redact any real secrets the model emitted; describe them, do not reproduce them.
- Write the business impact in one sentence the client's risk owner will understand: what an attacker gains, what data or action is exposed, who is affected. Translate the technical event into dollars, data, or trust, not jargon.
- Pull the mapped mitigation from the ATLAS Mitigations page (AML.Mxxxx) and pair it with the matching OWASP defense from the Prompt Injection Prevention Cheat Sheet. Each finding leaves with at least one concrete, named control, not a generic remediation paragraph.
- In the ATLAS Navigator, color every technique you tested and score the confirmed findings as realized; add a comment on each cell carrying the finding ID so the layer and the report cross-reference. Export the layer (.json for re-import, .xlsx for stakeholders).
- Reconcile: diff the technique IDs in your report table against the technique IDs in the exported layer. They must be the same set. Any technique tested-but-not-realized stays in the matrix as evidence of coverage, marked so the client sees what you checked and found clean.
What You Learn
The transferable lesson: a finding without a mapping is a story, and stories do not get fixed. The failure class this play closes is the report that lists clever attacks but never connects them to the client's own framework, so nothing gets prioritized and nothing gets patched. Mapping to OWASP plus ATLAS does two things at once: it gives the defender language they already speak, and it forces you to name a real mitigation for every attack, which is the honesty check on whether the finding is actionable at all. The Navigator layer adds the part most reports skip: proof of what you tested and found clean, not just what broke. Coverage is a finding too.
Drive It with Claude Code
Take the validated findings from our authorized LLM assessment of the in-scope chatbot range and draft the engagement report: one record per finding with a clear title, severity, reproduction steps, and evidence. For each one, map the result to its OWASP LLM Top 10 category and the matching MITRE ATLAS technique ID, then write a specific mitigation the defender can act on. Output a structured findings file plus a short executive summary, and keep all sensitive prompt text redacted to a benign placeholder.
findings:
- id: KS-LLM-001
title: System prompt disclosure via instruction override
severity: high
target: chatbot.range.internal # authorized, in-scope only
owasp: LLM01:2025 Prompt Injection
atlas: AML.T0051.000 LLM Prompt Injection - Direct
status: confirmed
evidence:
transcript: ./evidence/KS-LLM-001.txt # payload redacted, hash recorded
sha256: 9f2c...redacted
reproductions: 3
impact: >
Model returned guardrail logic that reveals intended restrictions,
lowering the cost of follow-on attacks.
mitigation: >
Separate system context from user input, add output filtering for
policy text, and add a regression eval that fails the build on recurrence.
- id: KS-LLM-002
title: Unsafe tool invocation from untrusted content
severity: critical
target: chatbot.range.internal
owasp: LLM06:2025 Excessive Agency
atlas: AML.T0053 LLM Plugin Compromise
status: confirmed
evidence:
transcript: ./evidence/KS-LLM-002.txt
sha256: 4ab1...redacted
impact: Agent executed an unscoped action on behalf of injected text.
mitigation: >
Enforce least-privilege tool scopes, require human approval for
state-changing calls, and validate tool inputs against an allowlist.
references:
owasp: https://genai.owasp.org/llm-top-10/
atlas: https://atlas.mitre.org/ # AML.T0051 / AML.T0053Defend It
For the blue team, the coverage matrix is the deliverable that drives work. Take the exported ATLAS Navigator layer and load it into your detection engineering and risk tracking the same way you would an ATT&CK layer: each realized technique becomes a backlog item, each mapped AML.Mxxxx mitigation becomes the acceptance criterion for closing it. Concretely: for prompt injection findings, implement the OWASP Prompt Injection Prevention Cheat Sheet controls in order, structured separation of instructions and data, input and output validation, least privilege on tool and data access for the agent, and human-in-the-loop on any high-impact action. Re-import the layer at the next assessment and re-score: a technique that moves from realized back to tested-clean is your evidence the fix held. Keep the matrix as the living scorecard between engagements, not a one-time PDF.