Two components each passed review alone; one now launders text into the other. How do you scope the reachable effect?

## What you have been handed A finding lands: attacker-influenced prose reached a downstream component through the free-text member of an otherwise typed handoff, and the downstream component acted on it. Both components had been reviewed. Both approvals were, individually, sound. Your job is to say how large this is. ## The union, not the intersection The blast radius of a laundered injection is the **union** of the two components' privileges, exercised in one session. - The upstream component's own exposure was its **read** surface: whatever material it ingests, which by design includes content from outside. - The downstream component's own exposure was its **act** surface: whatever it can write, call, file, assign or spend. Separately, each is bounded and each is defensible: a reader that cannot act is a limited problem, and an actor that only ever receives clean input is a limited problem. The laundering hop composes them. After it, content from the upstream reader's world can drive the downstream actor's capabilities. The reachable effect is therefore everything the downstream component can reach — and the entry point is everything the upstream component will read and restate. People reach instinctively for the intersection (*what do they have in common?*) or for the weaker of the two (*but the vendor component can't do anything*). Both understate it. The right question is: for each capability the reader holds, is there a path from something an outsider can write to a call that exercises it? ## The wrong answer, stated plainly > *That sub-component only talks to our own orchestrator.* This is offered as a mitigation and it is a category error. It is a statement about **connectivity** — about which processes may send to which. Connectivity bounds the *sender set*. It cannot bound the *content set*, because a member of the sender set is restating text an outsider composed. Internal provenance is not integrity. The same error appears in other clothes: *it is behind the boundary*, *it is our own service account*, *the traffic never leaves the VPC*. All of them describe topology. None of them describes what is in the message. ## What each review actually measured When a capability is approved on its own, what is being assessed is the effect of that capability given the inputs it was expected to see. That is a real assessment and it is usually correct. What it structurally cannot cover is a *pair*: the reviewer of the reading component was not asked what happens when its output steers an actor, and the reviewer of the acting component was not asked what its input would be if the writer were restating outside material. Composition is the property nobody's review had in scope, which is exactly why this class of finding survives a process where every individual approval was reasonable. Say this in the triage rather than implying that somebody was careless. It sharpens the finding: the defect is at the hop where the trust label changes hands, and it is invisible from either component's own review. ## Getting the directions right Several claims here are easy to state backwards, and an interviewer will listen for it: - The downstream component acting proves the span **reached its context**. It does not prove the upstream component was compromised, or that any store was breached. - A successful reproduction proves the construction worked **once, against one deployment**. With a probabilistic reader that is not the same as a reliable capability. - An audit record showing the call proves **which call ran under which authority**. It does not record who chose the argument values. - The absence of an alert proves nothing was **flagged**, not that nothing happened; no screen was watching that hop. ## Scoping method A workable procedure for the write-up: 1. Enumerate the reading component's capabilities — everything it can call, with what authority. 2. For each, ask whether an argument or a decision could be steered by prose in the handoff's free-text member. 3. Enumerate what the emitting component will ingest, and from whom. That is the entry surface. 4. State the union: entry surface in, capability set out, in one session. 5. Record the reliability honestly — how many attempts, against which deployment, and whether either side has shipped since. ## What not to claim Do not report the union as *the attacker has full control of the downstream component*. They have influence over text the component reads, which is a probabilistic lever on a capable actor, not a shell. The distinction matters to whoever prices the response, and overstating it is how a real finding gets argued down.