LLM08:2026 Hidden Context Exposure
The Successor to System Prompt Leakage

In 30 seconds

• What changed: 2025's LLM07 "System Prompt Leakage" is renamed and re-scoped to LLM08:2026 Hidden Context Exposure and moved from position 7 to 8.
• Why it matters: the entry no longer covers only the system prompt leaking — it covers the failure to keep any hidden context or state out of reach: session state, retrieved documents, tool outputs, and inferred context such as role and permissions.
• Core principle: a system prompt is not a security control. It sits in the same token stream as user input, with no enforced trust boundary. Anything the model can infer, it can leak.
• Not the same as LLM02: LLM02 protects sensitive data the model ingests or memorizes; LLM08 protects the application's own internal instructions, context, and state.
• Defense: keep secrets out of the prompt, enforce access control in deterministic app code outside the model, and treat inferred context as leakable.

Cross-reference: OWASP Top 10 for LLM Applications 2026 — what changed.

What the 2026 rename actually changed

In the 2025 list, position 7 was "System Prompt Leakage" — a narrow entry that read as "don't let your system prompt escape." The 2026 revision from the OWASP GenAI Security Project (released 2026-08-04) renames it to Hidden Context Exposure and re-scopes it to a general failure mode: information that should stay out of reach does not. The position shifts one slot, from 7 to 8.

The name change is the point. "System Prompt Leakage" framed the defense as protecting one artifact. In practice, teams that hardened the system prompt against extraction still leaked the same class of information through other channels — retrieved documents, tool outputs, session state, and context the model could infer about its own role and privileges. LLM08 names the whole surface instead of one instance of it.

The 2026 list also introduced a methodology change worth knowing when you read any single entry: for the first time the community vote was tested against a record of 7,714 real incidents (6,639 carried enough detail to classify), with the vote weighted 75% and the incident data 25%. That quarter-weight can move an entry a tier, not rewrite the list — LLM08's one-slot shift is consistent with a re-scope rather than a re-ranking.

Why "hidden context" is broader than "system prompt"

Hidden context is everything the application keeps behind the model that it would prefer an attacker not see or manipulate. The system prompt is one member of that set. The full set includes:

• The system prompt — the instructions that set the model's role and rules.
• Session state — what the application is tracking about the current interaction.
• Retrieved documents — RAG context injected into the prompt at runtime.
• Tool outputs — results returned to the model from functions or APIs.
• Inferred context — the model's implicit understanding of its role, the user's identity, and what permissions it believes are in force.

That last item is the reason the broader framing matters. You can strip a literal system prompt from a response and still leak the logic encoded in it, because the model can be led to reveal what it has inferred: which tier the user is in, which actions it thinks it may take, which internal names or fields exist. The operating rule is blunt: anything the model can infer, it can leak.

A system prompt is not a security control

This is the load-bearing claim of LLM08, and it holds for a structural reason. In current LLM deployments the system prompt, user input, retrieved documents, tool outputs, conversation history, and memory are pooled into one token stream with no enforced trust boundary. The model does not receive your instructions on a privileged channel; it receives them next to the attacker's input, and it weighs them together.

Two consequences follow:

• An inferred rule is a bypassable rule. An attacker who infers what the system prompt says can craft input to talk the model around it. Constraining the model's role in the prompt is a partial mitigation — useful for shaping behavior, worthless as a boundary.
• A secret in the prompt is a secret on the exposure surface. API keys, credentials, connection strings, or internal policy placed in the system prompt do not become safe by being "hidden." They become part of what the model may reveal or act on. Keep them out entirely.

The same limitation is why prompt injection (LLM01) has no reliable prevention today, a conclusion consistent with NIST (2025) and the UK NCSC (2025). If the system prompt cannot be a trust boundary against injection, it cannot be one against exposure either.

LLM08 vs LLM02: two different failures

These entries are easy to conflate because both end in "something leaks." They protect different things and call for different controls.

Shorthand: LLM02 is about the data flowing through the model; LLM08 is about the scaffolding around it.

Where LLM08 stops and the Agentic list begins

The LLM Top 10 owns the risk while the model is a component. The moment the model becomes an actor — calling tools, carrying memory across sessions, driving downstream consequences — the exposure risk moves into the OWASP Agentic Top 10 (for example ASI03 Identity and Privilege Abuse and ASI06 Memory and Context Poisoning). Pair the two lists rather than treating either as complete. See the Agentic list (currently Turkish-only): OWASP Agentic Top 10 (ASI).

Concrete defenses

LLM08 has a practical upside over LLM01: unlike untrusted-input injection, hidden-context exposure is largely a design problem you can engineer out.

• Keep secrets and credentials out of the prompt. Hold them in application code with least privilege. The prompt should never contain a key, token, or connection string.
• Never delegate critical access control to the model. Authorization decisions belong to a deterministic policy engine outside the LLM, evaluated in trusted code before any privileged action runs. "The prompt told it not to" is not an access control.
• Put the guardrail outside the model. Validate outputs against a strict schema in trusted app code — not a second LLM, which inherits the same token-stream weakness.
• Treat inferred context as leakable. Assume role, permissions, internal field names, and policy logic can be surfaced. Design so that revealing them costs you nothing, because the real control lives elsewhere.
• Constrain the role in the system prompt only as behavior shaping. It reduces casual leakage; it is not a boundary. Do not rely on it against a motivated attacker.
• Require human confirmation for privileged, irreversible, or externally visible actions, and budget agent capabilities so the blast radius of any single inferred instruction stays small.
• Strip invisible characters at every ingest and render boundary — tag-block (U+E0000–U+E007F), variation selectors (U+FE00–U+FE0F), and zero-width characters (U+200B/200C/200D/2060) — so hidden context cannot be smuggled in or exfiltrated through channels a human reviewer cannot see.

Honesty note and sources

The English entry IDs and titles above (LLM01–LLM10, LLM08 Hidden Context Exposure) are the official OWASP titles from the 2026 OWASP Top 10 for LLM Applications. The summaries, tables, and any accompanying JSON in the AltaySec cluster are a community-maintained derivative published under CC BY-SA 4.0; the authoritative wording lives in the official OWASP document. Where this article and the OWASP text differ, the OWASP text governs.

Official reference: OWASP GenAI Security Project — Top 10 for LLM Applications 2026. Turkish translation and dataset: GitHub and Hugging Face.

Frequently Asked Questions

What changed from 2025 System Prompt Leakage to 2026 Hidden Context Exposure?

OWASP renamed the entry and broadened its scope. In 2025 it was LLM07 System Prompt Leakage, framed narrowly around the system prompt escaping. In 2026 it becomes LLM08 Hidden Context Exposure (position 7 to 8), covering the failure to keep any hidden context or state out of reach — system prompt, session state, retrieved documents, tool outputs, and inferred role or permissions.

Is my system prompt a security control?

No. The system prompt sits in the same token stream as user input, retrieved content, and tool outputs with no enforced trust boundary, so the model weighs your instructions alongside an attacker's. Any rule an attacker can infer can be bypassed, and any secret placed in the prompt becomes part of the exposure surface. Use it to shape behavior, never as a boundary.

How is LLM08 different from LLM02 Sensitive Information Disclosure?

LLM02 protects sensitive data the model ingests, is trained on, or memorizes — for example PII or confidential records. LLM08 protects the application's own internal instructions, context, and state. Shorthand: LLM02 is the data flowing through the model; LLM08 is the scaffolding around it.

Can I stop hidden context from leaking entirely?

You cannot guarantee the model will keep inferred context secret — anything it can infer, it can leak. The durable fix is to make leakage cheap: keep secrets and credentials out of the prompt, enforce access control in a deterministic policy engine outside the model, and design so that revealing role, permissions, or internal names costs you nothing because the real control lives elsewhere.

Where does LLM08 hand off to the OWASP Agentic Top 10?

The LLM Top 10 owns the risk while the model is a component. Once the model becomes an actor — calling tools, carrying memory across sessions, driving downstream consequences — related exposure risk moves to the Agentic Top 10, such as ASI03 Identity and Privilege Abuse and ASI06 Memory and Context Poisoning. Pair the two lists.

Sources