Every LLM application assembles a context window out of material the user never sees: the system prompt, developer instructions, retrieved policy text from a RAG knowledge base or configuration store, user-profile data, and the schemas of the tools and functions the model is allowed to call. That material is invisible to the user but fully available to the model. LLM08:2026 Hidden Context Exposure is the risk that this material is extracted, inferred, or reconstructed by someone who was not meant to have it.
The single most important sentence in the OWASP entry is a design instruction, not a vulnerability description: practitioners should design under the assumption that hidden context is discoverable, and nothing in the context window should be treated as a secret. Disclosure of your system prompt should be an embarrassment at worst. If it is a breach, the design is wrong before any attacker gets involved.
New in the 2026 edition, and what it replaced
This entry carries a new name and a wider scope. The 2025 edition had System Prompt Leakage, which described one artefact leaking: the system prompt. The 2026 edition replaces it with Hidden Context Exposure, described by the editors as “a broader framework for the same failure to trust information that should have stayed out of reach.”
The re-scoping tracks what changed in the ecosystem between the two editions. In 2025 the hidden part of a typical deployment really was mostly one block of instructions written by a developer. By 2026 the hidden part is assembled at request time from several sources, most of which the developer does not author directly:
| Source of hidden context | Typical content | Why it grew |
|---|---|---|
| System / developer prompt | Role, tone, refusal rules, output format | Unchanged since 2025 |
| Tool and function schemas | Tool names, parameters, descriptions, role requirements | MCP servers and function calling make the tool list part of the prompt |
| Retrieved policy text | Business rules, entitlement logic, escalation criteria | RAG over configuration and policy stores |
| User-profile and session material | Account tier, permissions, prior state | Personalisation injected per request |
Once the tool catalogue and the policy corpus are inside the context window, “the system prompt leaked” stops describing the failure. What leaks is a map of the application’s internal control logic. Hence the rename.
The entry also states its boundaries explicitly. LLM08 does not cover leakage of regulated user or training data (that is LLM02:2026 Sensitive Information Disclosure), the agentic amplifications (persistent memory, inter-agent channels, tool-configuration persistence, multi-step agent compromise) which belong to the OWASP Top 10 for Agentic Applications, or generic application-security problems that LLM systems merely inherit, such as server-side log leakage, client-side bundle inspection, and infrastructure-layer side channels.
Severity depends on what you put in there
OWASP grades this entry by consequence, not by whether extraction succeeded, because extraction should be assumed. The severity bands in the source are:
| Band | Condition |
|---|---|
| Informational | No secrets, no security-relevant logic, no reliance on confidentiality |
| Medium | Internal rules, filtering criteria, role descriptions or workflow logic that meaningfully aids an attacker but does not gate critical decisions |
| High | Embedded credentials or tokens, or reliance on hidden-context secrecy for authorisation or content policy |
| Critical | Disclosure chains to remote code execution, broad data exfiltration, or privilege escalation in a connected system |
Two things move a finding up this scale, and both are decisions made at build time: putting secrets in the context, and relying on the context’s confidentiality as a control. Neither is a property of the attack.
How the exposure arises
The OWASP entry lists five categories of risk.
Sensitive functionality, tool and function schemas. The hidden context reveals system architecture, the available tools and functions, API keys, database credentials, or user tokens. OWASP is blunt about where the fault lies: exposure of credentials causes harm, but “the real risk is that sensitive credentials are placed in the hidden context in the first place.”
Behavioural control logic. Internal decision-making rules that were meant to stay confidential: how the application chooses between paths, what it escalates, what it silently downgrades. An attacker who reads these gains an accurate model of the application. Probing stops being blind, and the attacker can aim at specific weaknesses.
Reverse engineering of safety and refusal mechanisms. System prompts commonly define the conditions for refusing or filtering. A normal user sees only “Sorry, I cannot do that.” Leakage reveals the triggers, the conditions, and - the part that matters - the exceptions. The attacker stops guessing at what the filter catches and starts constructing inputs that sit in the gaps.
Permissions and user roles. Instruction context often carries authorisation hints. OWASP’s
example: a tool description served by an internal-facing MCP server states that the caller must hold
the developer role, or that a given role may search a particular RAG document set. That is a
directory of privileged functionality and an invitation to targeted probing via prompt injection
(LLM01:2026), which in turn may reveal sensitive information (LLM02:2026).
Output structure and formatting rules. System prompts specify JSON schemas, templates and validation constraints. When those leak, the attacker learns what downstream systems assume. They can then produce output that is structurally valid (it passes the schema check and matches the template) while carrying manipulated values, causing incorrect parsing or unintended behaviour further down the pipeline.
Why it amplifies the rest of the list
Hidden Context Exposure is a reconnaissance-class risk. Its direct impact is often low; its value to an attacker is that it converts every other entry from guesswork into aimed work. OWASP names four chains:
| Disclosed | Amplifies |
|---|---|
| Rules and internal logic | More targeted prompt injection (LLM01:2026) |
| Embedded credentials | Sensitive information disclosure (LLM02:2026) |
| Tool permissions and schemas | Excessive agency (LLM03:2026) |
| Output-formatting rules | Improper output handling (LLM10:2026) |
This is why the entry survives its own advice. Take an application that follows the guidance perfectly, with no secrets in context and no reliance on secrecy. Disclosure still hands the attacker the tool catalogue and the refusal conditions, and that is worth something to them.
Mitigations
The three strategies in the source are all structural. None of them is a filter that tries to detect extraction attempts, and that omission is deliberate: because the model can be induced to reveal what it can read, the fix is to change what it can read and what depends on secrecy.
Keep sensitive data out of the hidden context
Do not embed credentials, secrets, or security-critical configuration in system prompts or anywhere else in the assembled context. Assume everything available to the model is available to users. Externalise that material to systems the model does not directly access, and avoid letting the model handle sensitive data at all.
In practice this means a tool call that needs an API key should be executed by application code that holds the key, with the model supplying only the non-secret parameters. If the model needs to know that a credential exists, it needs a handle, not the credential.
Use deterministic controls, not instructions, for behaviour
Because LLMs are vulnerable to prompt injection, hidden context must not be the primary mechanism for controlling model behaviour. Enforce critical behaviour in independent, deterministic systems outside the model. Harmful-content detection, for example, belongs in external safeguards and not in a paragraph of the system prompt.
OWASP notes that specialised fine-tuning or further training may reduce the likelihood of disclosure, and then immediately qualifies it: it “provides no consistent guarantee and may have other unintended consequences.” Treat it as friction, not as a control, and do not let its presence justify keeping secrets in the prompt.
Enforce authorisation outside the model
Privilege separation, authorisation bounds checks and equivalent controls must not be delegated to the LLM, by system prompt or by any other mechanism. They need to be deterministic and auditable, which LLMs are not well suited to provide. Where a workflow spans different levels of access, separate it by authorisation context and grant each part only the privileges it requires.
The failure mode this prevents is the common one: a system prompt that says “only answer billing questions for the authenticated user’s own account” is a request, not an access control. The retrieval layer and the tool layer must independently be incapable of reaching another account’s data, whatever the model is persuaded to ask for.
Attack scenarios
Credential leakage via system prompt. An application places a set of credentials for a tool it can call into the system prompt. The prompt is leaked to an attacker, who then uses the credentials directly, outside the application, for whatever those credentials permit. The application’s own guardrails are irrelevant at that point.
Tool schema extraction. An attacker extracts the tool list and parameter schemas through conversational probing. No credential is disclosed; no policy is overtly bypassed. What the attacker gains is concrete targets: they now know which tool calls exist, what arguments they take, and where to aim subsequent prompt-injection attempts and downstream action chaining. This is the scenario that best illustrates why the entry exists even in well-built systems.
Bypassing restrictions via guardrail disclosure. A system prompt prohibits offensive content, external links and code execution. The attacker extracts it and crafts a prompt-injection payload that navigates around the specific prohibitions it names. The guardrail was a sentence, and the attacker read the sentence.
Failure modes and what you would see
The uncomfortable property of this risk is that successful extraction produces normal-looking traffic. A conversational probe that recovers the tool schema is a conversation. There is no error, no exception, no failed authentication. Useful signals are indirect:
- Sessions whose messages are disproportionately meta-questions about the assistant’s own rules, capabilities or formatting instead of task content.
- Model responses that quote or paraphrase instruction text. Log these output-side, since the extraction is visible in what the model said even when the input looked benign.
- Requests for tools by exact internal name from accounts that were never told those names.
None of these are reliable detections, and the source proposes none. The defensible position is the one OWASP states at the top: build so that disclosure does not matter, then treat any detection you manage as a bonus.
Related entries
- LLM01:2026 Prompt Injection - the delivery mechanism for most extraction attempts, and the primary beneficiary of anything extracted.
- LLM09:2026 Vector and Embedding Weaknesses - retrieved policy text is hidden context; when it is retrieved from a shared index, the retrieval layer becomes a second route to the same material.
- LLM10:2026 Improper Output Handling - leaked output-formatting rules let an attacker produce structurally valid output carrying manipulated values.
- AI security overview - the full 2026 list and how the entries relate.