Hidden Context Exposure Is Agent Reconnaissance Now
Hidden Context Exposure Is Agent Reconnaissance Now
OWASP’s 2026 LLM Top 10 reframes prompt leakage as Hidden Context Exposure. In an agentic system, that hidden context is not just a secret prompt. It is the map of what the agent can do, which systems it can touch, and where the next attack should go.
OWASP published the Top 10 for LLM Applications 2026 on August 3, calling it a guide grounded in real-world AI security incidents and mapped to frameworks including the OWASP Top 10 for Agentic Applications. One of the most important changes is easy to miss: System Prompt Leakage has expanded into LLM08: Hidden Context Exposure.
That is a better category for the systems security teams are actually deploying.
In 2024, prompt leakage meant “can a user make the model reveal the system prompt?” In 2026, hidden context includes tool schemas, internal policies, workflow logic, user roles, connector permissions, refusal boundaries, retrieved records, and memory state. For a normal chatbot, that disclosure is embarrassing. For an agent, it is reconnaissance.
The shift: leakage becomes targeting
Security programs like clean categories. Secrets are secrets. Prompts are prompts. Tools are tools. Logs are logs.
Agents do not respect those categories.
An enterprise agent assembles a working context from many places: developer instructions, retrieved documents, identity claims, role mappings, memory summaries, tool descriptions, and API affordances. The model uses that context to decide what to do next. An attacker uses the same context to decide how to attack.
That means the first dangerous interaction may not look like an exploit at all.
It may look like:
- “What systems can you help me update?”
- “Which actions require approval?”
- “What fields does the deploy tool accept?”
- “What sources did you use for this answer?”
- “What do you remember about the last incident?”
- “What would make you refuse a request?”
Individually, those questions can look like normal user discovery. Together, they become an application-specific attack map.
The attacker does not need to steal a database on the first prompt. They can first learn the tool surface, permission model, workflow rules, memory hints, and refusal boundaries. Then they can write the prompt injection that fits your system instead of a generic jailbreak that gets caught.
A simple attack chain
This is why Hidden Context Exposure belongs in the same conversation as the OWASP Agentic Top 10 2026. OWASP describes the agentic list as a framework for risks in systems that reason, use tools, maintain memory, delegate work, and take actions. Hidden context is the connective tissue between those capabilities.
If an attacker learns the tool surface, ASI02 becomes easier. If they learn autonomy thresholds, ASI03 becomes easier. If they learn memory shape, ASI06 becomes easier. If they learn communication paths, ASI07 and ASI08 become easier. If your logs cannot tie the probing phase to the action phase, ASI10 is already failing.
Memory makes hidden context persistent
Recent research makes this sharper. The July 2026 paper Agent Data Injection Attacks are Realistic Threats to AI Agents argues that agent data injection can hide malicious data inside trusted-looking metadata or context, leading to unintended actions across real agents and coding tools.
Another July 2026 paper, Your Agent’s Memories Are Not Its Own, shows a forged reasoning attack against agent memory. The key lesson is not that memory can be poisoned. The key lesson is that memory is now a security object.
If memory stores prior decisions, tool usage, user preferences, reasoning traces, and workflow shortcuts, then it also stores targeting material.
An attacker who can read memory learns how the agent behaves.
An attacker who can write memory changes how the agent behaves later.
An attacker who can influence what the agent remembers gets a delayed execution surface that may activate days after the original interaction.
What security teams should classify as hidden context
The hard part is that hidden context is rarely stored in one place. It is assembled at runtime.
| Context Type | Why Attackers Want It | Control That Holds |
|---|---|---|
| Tool schemas | Tool names, parameters, accepted formats, and side effects reveal where abuse can be disguised as normal work. | Expose only task-needed tools, redact irrelevant schema detail, and log schema enumeration as reconnaissance. |
| Approval rules | Thresholds tell an attacker how to stay below review or split one risky action into many low-friction actions. | Keep approval logic out of model-visible text where possible, and detect repeated boundary probing. |
| Connector scopes | Knowing which SaaS systems, repos, tickets, and databases are connected turns generic prompt injection into targeted abuse. | Use per-task connector grants, scope minimization, and egress controls tied to business intent. |
| Memory state | Stored preferences and reasoning traces can reveal shortcuts, trusted users, incident names, and past exceptions. | Treat memory writes like database writes: provenance, review, retention, retrieval filtering, and tamper evidence. |
| Refusal boundaries | Refusal explanations can teach an attacker exactly which phrasing, role, source, or workflow will be accepted. | Return minimal refusal detail externally, while keeping full internal reason codes for defenders. |
The wrong fix: hide everything from the model
There is a tempting response: remove all context, hide every tool, and make the model ask a policy service for everything.
That can work for narrow systems. It breaks the value proposition of many agents.
The better rule is not “the model sees nothing.” The better rule is context least privilege.
Give the agent the context required for the current task, at the moment it needs it, with the minimum detail needed to act safely. Then record what context was exposed, why it was exposed, and whether the user interaction looked like discovery, operation, or abuse.
Minimize
Do not load the whole capability graph when the task needs one connector and one safe action.
Segment
Separate instructions, data, tool metadata, memory, and approval logic so untrusted content cannot blend into trusted context.
Detect
Watch for capability discovery, role probing, schema enumeration, memory fishing, and refusal-boundary testing.
What to do this quarter
Start with the questions that expose whether hidden context is governed or accidental:
- Can we list every tool schema, memory source, role rule, approval rule, and retrieved policy the agent can see during a run?
- Can we prove which hidden context was included before a risky action?
- Do we detect users who ask repeated capability, boundary, and role-discovery questions before making an action request?
- Can we separate “model refused” from “model taught the attacker how the boundary works”?
- Can we revoke or quarantine memory entries with the same urgency as compromised credentials?
- Can we scope context per task instead of per agent deployment?
If the answer is no, the organization does not have an AI secrecy problem. It has an AI reconnaissance problem.
Hidden Context Exposure is not about whether a chatbot leaks a prompt. It is about whether an attacker can map your agent’s operating model before they abuse it. The control objective is to reduce what the agent reveals, reduce what the attacker can infer, and detect reconnaissance before it becomes a business action.
Sources
- OWASP GenAI LLM Top 10 2026
- OWASP Agentic Security Initiative
- The OWASP Top 10 for LLM Applications 2026: From Model Risks to Agentic Security
- Agent Data Injection Attacks are Realistic Threats to AI Agents
- Your Agent’s Memories Are Not Its Own: Forged Reasoning Attacks on LLM Agent Memory and Defenses
Rogue Security builds runtime security for agentic AI systems. Learn more at rogue.security.