Hidden context exposure

Every application built on a language model assembles things the user never sees into its prompt: instructions, retrieved policy, the shape of the tools it can call. Hidden context exposure is OWASP’s name for that material being extracted, inferred, or reconstructed by someone it was never written for.

What counts as hidden context

The obvious member is the system prompt, but OWASP’s list runs longer: developer instructions, policy text retrieved from a RAG store, configuration data, and the schemas of the tools the application exposes to the model. The common thread is not where the text comes from — none of it was meant for the user, and all of it is available to the model regardless.

That width is what changed in 2026. OWASP’s prior list scoped this to the prompt alone, under the name System Prompt Leakage. The 2026 edition retired that name for Hidden Context Exposure: a system prompt, a leaked tool schema and a leaked authorization rule all fail the same way.

How severity is decided

Exposure is not automatically dangerous. OWASP ties severity to what sits in hidden context and how much the application depends on it staying hidden: informational when nothing sensitive is there, medium when internal rules help an attacker without deciding anything critical, high when credentials sit there, critical when disclosure reaches remote code execution.

That scale points at the real failure. A leaked API key would cause harm — but the risk is placing the key in hidden context at all, not that it was later read. The mitigations follow the same logic: keep sensitive data out of a probing conversation’s reach, and do not let the model enforce authorization or content policy — that belongs outside it.

Where definitions disagree

The 2025 and 2026 categories disagree on scope, not on the underlying claim. LLM07:2025 held that a leaked system prompt is not itself the risk — the risk is delegating session management and authorization to the model, and storing sensitive data somewhere it should not be. LLM08:2026 makes the identical argument and widens what “somewhere” covers: developer instructions, RAG policy text and tool schemas fail exactly the way a system prompt does, so a category built only around the prompt was drawing the boundary in the wrong place.

OWASP’s own wording carries a second, smaller tension. Its description says hidden context “should not be solely relied upon” as a security boundary — a hedge that allows it as one layer among others. Its mitigations go further: privilege separation and authorization checks “must not be delegated to the LLM,” unconditionally. The second statement is the one to build a system on.

Questions and answers

Is hidden context exposure the same thing as system prompt leakage?

It absorbed it. OWASP's 2025 list had a category called System Prompt Leakage, scoped to the system prompt alone. The 2026 list retired that category and replaced it with Hidden Context Exposure, which covers the system prompt plus developer instructions, retrieved policy text, and tool or function schemas, on the reasoning that all of these fail the same way: content the application never meant a user to see, sitting where the model can read it.

Is hidden context always a secret?

No, and OWASP says the opposite on purpose. Practitioners should design on the assumption that hidden context is discoverable and that its contents should not be considered a secret. Credentials, connection strings and authorization logic do not belong there regardless of whether anyone ever extracts them; the mistake is placing sensitive material somewhere readable, not failing to keep it hidden.

What decides how severe an exposure is?

What was placed in the hidden context and how much the application depends on it staying hidden. A leak with no secrets and no security reliance on secrecy is informational. A leak of internal rules or workflow logic that helps an attacker without gating a critical decision is medium. Embedded credentials, or authorization decided by hidden-context secrecy, is high. Disclosure that chains to remote code execution, broad data exfiltration or privilege escalation is critical.

Can a system prompt stop hidden context from being misused?

Not for anything critical. OWASP states this two ways: hidden context generally "should not be solely relied upon" as a security boundary, and more strongly, that controls like privilege separation and authorization bounds checks "must not be delegated to the LLM" at all. Those controls belong in a deterministic system the model cannot talk its way around.