One delivered finding in your AI red-team report came from a chain: untrusted retrieved content steered the assistant into a tool call, and that call moved data out. How do you map it onto a published adversary technique reference without inflating your finding count?

Two questions look like one question and are not: **what counts as one finding?** and **how many technique identifiers does that finding carry?** Chained findings go wrong when a team answers the second question and lets the answer decide the first. ### The report's unit One finding is **one path a defender closes as a single decision**. If breaking any single link kills the whole chain, and one team owns the fix, that is one item however many steps it passed through. It genuinely becomes more than one when the intermediate weakness is independently exploitable on its own, when the same end effect is reachable from an entirely different entry point, or when the steps sit with different owners whose fixes are scheduled separately. The test is not step count; it is how many separate remediation decisions the client has to make. ### The mapping's unit Mapping is not bound by that at all. A chained finding maps to a **sequence**: a primary technique for what was actually achieved, plus supporting techniques for each enabling step, presented in causal order inside the one entry. The ordering is what carries the information. A defender who reads *untrusted content entered here → the model was steered → the tool executed → data left* can see three candidate break points and pick the cheapest one to close. The same three codes as an unordered set say only "these techniques were involved" and leave the defender to reconstruct the path from your prose. A workable entry shape: ``` Finding: assistant exfiltrates conversation data via an attacker-authored document Impact / primary technique: <identifier> - what the attacker achieved Enabling step 1 (entry): <identifier> - untrusted content reached the context Enabling step 2 (pivot): <identifier> - the tool call the model was steered into Unmapped element: the composition itself, where the reference has no chain concept ``` ### Why primary-by-impact rather than primary-by-entry-point The reader's first question is what the attacker got, and the report's severity rating follows the delivered effect. Map to the entry point alone and a data-egress path indexes next to input-handling curiosities: anyone filtering the catalogue by technique to find their serious items will not see it. Map to the last step alone and you hide that the whole thing began with content the system fetched for itself, which is precisely the part the platform team can cheaply fix. Primary by impact, supporting steps retained, is the arrangement that survives both readings. ### What it costs, and the number that misleads Splitting is cheap to do and expensive downstream. Three findings where there was one path becomes three tickets, three triage conversations, three re-test requests at verification, and three rows in next year's trend, all describing one piece of work. Re-testing is the concrete cost: verifying one closed chain is one exercise; verifying three separate items is three, and two of them will be re-verifying the same fix. The misleading number is the **finding count**. It gets lifted into the executive summary, compared against last quarter and against the other vendor's report, and treated as a measure of thoroughness or of how bad the system is. Every incentive in that loop pushes toward splitting, and splitting costs nothing to justify because each fragment is technically a real technique. The same distortion appears one level down in the per-technique histogram: pad a chain with plausible supporting codes and that technique's bar grows without a single additional observation behind it. The defence is a written house rule — **one exploitable path, one finding; map as many techniques as the chain genuinely touches** — applied consistently enough that your own year-over-year counts stay comparable. You lose nothing in rigour: the technique detail all survives, it just lives inside the finding rather than multiplying it. ### What I would check before delivery For each identifier in the chain, does that step's *evidence* satisfy the entry's description, or was the list padded with plausible-sounding techniques to look thorough? Padding is easy to spot on review — ask which artefact demonstrates that step, and a padded entry has none. Then check the rating: it should reflect the end-to-end outcome, not the worst individual step, and certainly not an average across steps. And check the composition itself: if the reference has no way to express that these steps form a chain, say so explicitly in the entry, because the novelty of a chained finding usually lives in the composition and that is exactly the part a mapping silently discards.