Input-side defenses dominate the LLM security literature: classify the prompt, filter the retrieval, sanitize the tool description. They are necessary and they are not sufficient, because a determined indirect injection will eventually get some instruction through. What decides whether that instruction becomes a breach is the other side of the model — egress. EchoLeak is the canonical proof. The stolen data did not walk out through a shell; it was encoded into an outbound reference — a link or image the rendering surface would resolve — and left through a channel nobody was inspecting. This paper treats egress inspection as a mandatory checkpoint, not an afterthought.
The injection and the tool use are means; the end is data leaving through an outbound reference. Inspecting the model's output for that reference is the last, and often only remaining, place to stop it.
Why egress is the attacker's hardest link to avoid
Consider the exploit chain as a whole: untrusted content is ingested, an instruction is followed, and data is exfiltrated. An attacker can vary the first two links almost infinitely — new injection phrasings, new documents, new tool paths — which is precisely why ingress classification can never be complete. But the third link is constrained by physics: to exfiltrate, the data has to leave, and there are only so many channels through which an LLM response can carry it. That asymmetry is the reason egress is worth defending hard. The output surface is narrow and enumerable in a way the input surface is not.
What egress inspection actually examines
Egress inspection reads the model's response — and any structured tool output destined for a client that will render it — for data-shaped payloads riding in channels that resolve. The concrete surfaces are well known, which is what makes them defensible.
- URLs and query strings: sensitive context base64-ed or concatenated into a link the browser will fetch, the classic EchoLeak vector.
- Image and resource references: markdown images and HTML tags whose src the client resolves automatically, turning a render into a beacon.
- Markup and hidden spans: zero-width characters, off-screen elements, and encodings that carry data past a human reading the visible text.
- Structured fields: tool-call arguments and JSON that smuggle context into a downstream system under the guise of a legitimate parameter.
The decision is not merely 'does this contain a URL.' It is whether the response is attempting to move privileged context off-platform, weighted by the provenance carried from ingress: a response that encodes data into an outbound reference shortly after the model ingested an external, untrusted span is exactly the pattern to block or redact. Provenance is what lets egress inspection distinguish a helpful link the user asked for from a link the injected instruction built.
Because external spans were labeled untrusted on the way in, the egress checkpoint can apply a sharper rule: content derived from untrusted context may not leave through a resolving channel.
Placement and the latency problem
Egress inspection has to sit in the response path at the gateway, after the model produces output and before the client receives it. That placement is what makes it authoritative — it sees the final bytes — and it is also what makes it a latency risk, because it is on the user-visible critical path. The engineering answer mirrors the ingress tier: cheap deterministic checks first (does the response emit any resolving reference at all; most do not), and the expensive classification reserved for responses that carry one. Streaming complicates this — you cannot un-send a token — so a response that will emit a resolving reference is buffered at the boundary until the reference is cleared, rather than streamed and retracted.
Fail closed, and record the block
Like every checkpoint in this architecture, egress denies on uncertainty: if the inspection cannot clear a resolving reference, the reference is stripped or the response is held, not passed. And every block is emitted as an evidence event — which span, which channel, what was redacted — so an exfiltration attempt becomes a finding a human can review rather than a silent success. This is the difference EchoLeak makes concrete: with egress inspection, the same exploit that leaked a user's context becomes a logged, denied event at the last boundary.
Scope of the claim
Egress inspection does not make exfiltration impossible; a sufficiently clever covert channel can still exist, and side channels are a research problem, not a solved one. What it does is close the channels that real exploits actually use — resolving URLs, image references, hidden markup — and remove the assumption that a response is safe simply because the prompt was checked. Paired with ingress classification and pre-action authorization, it is the checkpoint that most directly converts a scope-violation exploit from a breach into an alert.