The unintended exposure of conversation details, connected-system data, or prior prompts to an external tool or server. In AI-integrated environments, context leakage is a governance issue because the AI may send more information than the user expected or intended.
Expanded Definition
Context leakage occurs when an AI system forwards more surrounding information than is required to complete a task, including prior prompts, hidden instructions, retrieved documents, conversation history, or connected-system data. In NHI and agentic AI environments, the concern is not only disclosure to a human user, but also unintended transmission to an external model endpoint, plugin, or tool server. That makes the issue a governance and data-minimisation problem, not just a prompt-engineering issue.
Definitions vary across vendors because some describe the problem as prompt leakage, while others treat it as overbroad tool context, unsafe retrieval, or cross-session contamination. The most useful operational definition is whether sensitive context was supplied without a clear necessity-to-execute basis. NIST’s AI Risk Management Framework helps frame this as a trustworthiness and data-governance control problem, while OWASP’s agentic guidance treats tool exposure and instruction handling as core attack surfaces. For practical comparison, see Anthropic — first AI-orchestrated cyber espionage campaign report and Ultimate Guide to NHIs — Why NHI Security Matters Now.
The most common misapplication is assuming context leakage is harmless because no secret was explicitly typed into the chat, which occurs when hidden system prompts, API outputs, or connected records are still exposed.
Examples and Use Cases
Implementing context controls rigorously often introduces latency and workflow friction, requiring organisations to weigh safer data minimisation against the convenience of broad retrieval and richer agent autonomy.
- An internal support agent sends a full ticket thread, including customer tokens and prior troubleshooting notes, to an external model when only the latest incident summary was needed.
- A coding assistant attached to a repo exposes environment variables or deployment details through tool calls, creating a path from a harmless question to sensitive infrastructure disclosure. The NHI failure mode is similar to the patterns described in the Guide to the Secret Sprawl Challenge.
- A retrieval-augmented assistant includes entire knowledge base articles with unrelated customer identifiers instead of filtering to the minimum relevant passage.
- An AI workflow uses an external enrichment service and passes prior chat turns that contained operational incident data, even though the enrichment step only required a hostname.
- A research copilot retains context across sessions and surfaces another user’s prior prompts, which is a cross-session isolation failure rather than simple bad output formatting.
OWASP’s agentic AI guidance and the 52 NHI Breaches Analysis both reinforce that data passed into an automated workflow must be treated as an access decision, not a convenience default.
Why It Matters in NHI Security
Context leakage matters because AI agents often sit between people, secrets, and systems of record. If the agent forwards too much context, it can expose service account names, API keys, ticket attachments, incident timelines, or privileged instructions to parties that never needed them. That breaks least privilege, undermines segmentation, and can create secondary compromise paths when leaked context is used to target NHIs. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes over-shared AI context especially dangerous because exposed material is often already spread across code, tickets, and CI/CD systems.
It also affects incident response. If a tool call has already forwarded confidential context, the issue is not just prompt sanitisation but token rotation, session invalidation, access review, and tool-boundary redesign. This is where zero trust thinking becomes practical: each retrieval, prompt assembly step, and connector permission must be justified. Organisations typically encounter the seriousness of context leakage only after a tool output, audit log, or vendor-side trace reveals sensitive material, at which point containment and revocation become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AGENT-03 | Covers unsafe tool use and context exposure in agentic workflows. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Context leakage often exposes secrets and sensitive NHI material. |
| NIST AI RMF | AI RMF treats over-disclosure as a governance and trustworthiness issue. | |
| NIST CSF 2.0 | PR.DS | Protecting data in transit and at rest extends to AI context payloads. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust requires explicit control over each connection that receives context. |
Treat every context handoff as an untrusted transaction and enforce connector-level least privilege.
