The class, and why its Top 10 entry was rewritten
In the 2025 list this was LLM07 System Prompt Leakage. In the 2026 list it is LLM08:2026 Hidden Context Exposure - renamed and re-scoped, because "system prompt" stopped describing the thing. The hidden context of a modern application is the system prompt plus the tool definitions, the retrieved documents, the memory entries, the activation triggers and the routing rules. All of it travels in the same token stream, and none of it carries a marking the model can check. Alongside it sits LLM02:2026 Sensitive Information Disclosure, which covers what leaks out of the data rather than out of the instructions.
Design so that disclosure does not matter 7 min live
This is a design lesson, not a testing lesson, and it is the single most useful sentence in the 2026 list. OWASP's guidance for LLM08:2026 is to design the application so that disclosure of the hidden context has little or no direct security impact. Not to obfuscate it. Not to instruct the model to refuse to reveal it. To arrange matters so that reading it is uninteresting.
Three prohibitions follow directly, and they are worth writing on a wall. Never place credentials or tokens in the hidden context. Never rely on its secrecy as an authorization or privilege-separation boundary. Never rely on its secrecy as a policy or filtering boundary - if the only thing stopping an action is a sentence in a prompt, then the control is a sentence in a prompt, and b1 already established what those are worth.
The frameworks name the pieces of this surface precisely enough to build test cases from, and the sub-techniques under AML.T0084 are the most useful part, because they enumerate what an attacker learns about an agent before touching it at all. Discovery is a tactic in its own right, and it is the cheapest one.
| ID | Name | Where it bites |
|---|---|---|
| AML.T0056 | Extract LLM System Prompt Feasible | The instructions themselves. Low maturity in ATLAS, high frequency in practice |
| AML.T0057 | LLM Data Leakage Demonstrated | Training data, retrieved documents, other users' content surfacing in an answer |
| AML.T0084 | Discover AI Agent Configuration Demonstrated | The parent technique. Four sub-techniques below, and each is a separate test case |
| AML.T0084.000 | Embedded Knowledge | What the agent was given: internal documents, examples, business rules baked into context |
| AML.T0084.001 | Tool Definitions | Which tools exist, their parameters and their descriptions. Reconnaissance for b6 |
| AML.T0084.002 | Activation Triggers | What causes the agent to act. Learning this is how a chain becomes reliable |
| AML.T0084.003 | Call Chains | Which tool leads to which. The map an attacker would otherwise have to guess |
| AML.T0098 | Credential harvesting via tools | Credential Access. The tool call itself returns something it should have kept |
| AML.T0082 | Credential harvesting via RAG | Credential Access. Somebody indexed a document that contained a key |
| AML.T0083 | Credential harvesting from agent config | Credential Access. ATLAS maps no mitigation to this technique at all - see the honesty note below |
Severity is what it chains to 5 min live
LLM08:2026 ships a worked severity ladder, and it generalises well beyond hidden context. Copy it into your triage rubric verbatim, because it converts the most common argument in AI triage - "but the system prompt leaked" - into a question with four possible answers rather than a matter of temperament.
LiveHow this lines up with MSRC's published rubric3 min▶
Microsoft's AI bug bar reaches the same place by a different route, and having both on hand is useful when you need to defend a rating to somebody outside your team. Their Inferential Information Disclosure category keys severity to the data classification of what became reachable: model theft is Critical where the asset is Highly Confidential and slides down to Low where it is Public; input extraction, which is where system-prompt leakage lands, is Important where the content is Confidential and Low otherwise.
Two design decisions there are worth copying wholesale. Severity turns on the data classification of what is reachable, and on whether user interaction was required. It does not turn on how clever the extraction was. A tester who found the leak through a long and ingenious sequence and a tester who found it by asking politely have found the same finding, and the rating is identical.
Note the failure mode this protects you from. Without a rubric, extraction findings get rated by narrative quality, and narrative quality correlates with the tester's writing rather than with your risk.
Three places the context lives, and one boundary that keeps failing 6 min live
Hidden context is not one object. It is at least three stores with different lifetimes, different owners and different failure modes, and the retrieval layer is where the worst of them lives. OWASP gives vector and embedding weaknesses their own entry, LLM09:2026, and ATLAS files the write side as AML.T0070 RAG Poisoning and the read side as AML.T0082 credential harvesting via RAG.
The cross-tenant case deserves naming plainly, because it is the one that turns an AI feature into a data-protection incident. A shared index with tenant identity applied as a filter after retrieval, or applied in the prompt rather than in the query, is a boundary that exists only as long as nothing surprising happens. It is not an AI weakness. It is an old multi-tenancy weakness that arrived in a new component, which is a sentence you will read again in b6.
The hidden-context audit for Beacon's three bots ★ 12 min · everyone builds
One line per item, one question per line: what breaks if this is read aloud in a public forum? Do it as an inventory, not as a test. You will find more in twenty minutes of reading your own configuration than in a week of probing it, and the findings will be actionable rather than anecdotal.
Dump everything that reaches the context window, from every source. System prompt, developer messages, tool definitions with their descriptions and parameter names, retrieved chunks, memory entries, routing rules, few-shot examples. Beacon's Analyst Bot turned out to carry a table-name allowlist that nobody had thought of as context and that maps the warehouse rather neatly.
Sort each line into the two columns from Part 1. Anything landing in the right-hand column is a finding today, before any testing happens. Credentials and tokens are the obvious ones. The subtle one is any line whose enforcement is the fact that the reader has not seen it.
Walk the four AML.T0084 sub-techniques as an attacker's shopping list. Embedded knowledge (.000), tool definitions (.001), activation triggers (.002), call chains (.003). For each, write down what an attacker learns and whether that knowledge alone changes what they can achieve. On Support Bot, the tool definitions reveal a refund tool, and that single line is the reconnaissance that makes b6's session worth attending.
For every "the model is instructed not to reveal X" line, write the control that would hold if the instruction were deleted. If there is none, you have found a policy boundary that exists only in prose. Note that this is the same anti-lever the course simulator measures: the system-prompt guard removes 3.6 risk points on a bare system while least-privilege and human approval remove 55.
Grade the whole inventory on the Part 2 ladder and put the result in the report as a single sentence: today, disclosure of Beacon's hidden context would be Informational for Insight Bot, Medium for Analyst Bot, and High for Support Bot until the connection string comes out of the configuration. That sentence is the finding. The extraction transcript is an appendix.
Plant the canaries, run the boundary test ★ 8 min · in pairs
Canaries turn an unfalsifiable claim into a measurement. A canary is a string that is a secret and is nothing else: it authorizes nothing, unlocks nothing, and exists only so that its appearance anywhere is unambiguous. This is the fixture file, and it is the most reusable artefact in the session.
Plant one canary per store, per tenant. A single shared canary tells you something leaked. A canary per tenant tells you which boundary failed, which is the difference between a finding and an investigation.
Run the tenant-boundary retrieval test at your fixed N, and vary the phrasing rather than the tenant. Ask tenant B's questions in tenant A's vocabulary, with tenant A's product names and tenant A's spelling. Embedding similarity does not respect your org chart, and that is the whole point of LLM09:2026.
Wire the canaries into detection as well as into testing. The same string that fails a test in staging should page somebody if it is ever seen in production output. This is the cheapest thing in the entire course and almost nobody does it. It also gives your observability team something concrete to alert on, which is the handshake into the sibling course.
Record the result as k of N per store, per boundary, exactly as in b4. "Cross-tenant retrieval: 0 of 25 across 6 tenant pairs, build 2026.08.11" is a sentence a regulator can read. "We tested for cross-tenant leakage" is not.
Try it yourself - this week ◐ 45-60 min total
- Print your own hidden context, every source of it, and do the two-column sort. Budget twenty minutes and expect to find at least one line in the right-hand column. Most teams find a hostname or an internal rule they had been treating as secret without ever deciding to.
- Search your retrieval index for anything that looks like a credential. Somebody indexed a runbook, and runbooks have keys in them. This is AML.T0082 and it is usually a five-minute grep rather than an attack.
- Plant one canary in each store you own and add the production alert. If you do nothing else from this session, do this one.
- Take your last system-prompt-leakage finding and re-rate it on the LLM08:2026 ladder. If the rating changes, the conversation you have about why is the actual homework.
Official sources covered
Every framework, figure and quotation on this page traces to a primary source catalogued in this course's source map, verified 2026-08-14. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · What does OWASP LLM08:2026 actually ask you to do about hidden context?
A is what most teams do and it is a prose control: delete the sentence and nothing is left. C misunderstands where the context lives, since the model must read it to use it, so it arrives decrypted in the same stream as everything else. The entry was renamed from "System Prompt Leakage" precisely to move the conversation from extraction technique to design, and the payoff is that a leak becomes Informational rather than an incident.
2 · Your Support Bot's hidden context is read out in a public forum. It contains a warehouse connection string. Where does this land on the LLM08:2026 ladder, and why?
The ladder does not consult the extraction method. Embedded credentials or reliance on secrecy for authorization is the High rung by definition, and it climbs to Critical the moment the leak is the first step of a chain to code execution, broad exfiltration or privilege escalation. Note the asymmetry that makes this class worth designing rather than testing: you cannot argue your way down the ladder at triage time, you can only build your way down it beforehand.
3 · A tenant B user's query returns a document belonging to tenant A. How do you write this finding?
B is the tempting one because the symptom appeared in an answer, so the instinct is to fix the prompt that produced the answer. But tenant identity applied as a post-retrieval filter, or applied in the prompt rather than in the query, is a boundary that exists only while nothing surprising happens. Embedding similarity does not respect your org chart. Canary documents planted per tenant turn this from an argument into a number, and the number belongs on a trend line.