Dynamic context risk

The security risk created when a GenAI system’s behaviour changes as prompts, documents, memory, and tool results change. It matters because control failure may appear only after launch, when runtime context alters what the system can see, say, or do.

Expanded Definition

Dynamic context risk describes a moving security condition in GenAI systems where the effective risk profile changes as runtime inputs change. That includes prompts, retrieved documents, memory, tool outputs, conversation history, and any permissions attached to the agent or application. In practice, the model may remain unchanged while the surrounding context changes the system’s behaviour, making the risk state harder to predict than in a static application flow.

This term is most useful when examining agentic or retrieval-augmented systems, because the security impact depends less on a single prompt and more on the full context chain that influences reasoning and execution. The concept aligns well with the governance emphasis in the NIST Cybersecurity Framework 2.0, especially where organisations need to identify, protect, detect, and respond to changing operational conditions. Definitions vary across vendors on whether dynamic context risk is a distinct control category or simply a way to describe runtime exposure. The most common misapplication is treating it as a static design-time issue, which occurs when teams assess only the base model and ignore how live context alters tool use, output quality, and privilege exposure.

Examples and Use Cases

Implementing controls for dynamic context risk rigorously often introduces orchestration overhead, requiring organisations to weigh improved safety against reduced responsiveness and higher monitoring cost.

• An internal support agent is safe during testing, but after being connected to a knowledge base it begins surfacing sensitive records that were never visible in the test environment.
• A financial assistant uses long-term memory to personalise responses, but stale memory causes it to repeat outdated instructions that conflict with current approval rules.
• A coding agent receives a benign prompt, then a tool result containing attacker-controlled text changes its next action path and expands the blast radius of a compromised workflow.
• A retrieval-augmented system pulls in documents from mixed-trust sources, and the context shift changes the model’s answer quality and compliance posture from one session to the next.
• An identity workflow exposes a non-human identity with excessive permissions, and the agent’s runtime context turns a low-risk query into an unauthorised action path.

For teams building AI controls, the key issue is that context becomes part of the attack surface. Guidance on runtime trust boundaries in OWASP guidance for large language model applications helps explain why prompt content, memory, and tool output should be treated as separate trust zones. The same system can be low risk in one session and materially higher risk in the next if its context changes.

Why It Matters for Security Teams

Dynamic context risk matters because it can defeat controls that assume a stable application state. Traditional security reviews often focus on code, endpoints, and known privileges, but GenAI systems can shift behaviour based on retrieved content, conversation history, and external tools. That makes threat modelling harder and increases the chance that security, privacy, or compliance failures appear only after deployment. In agentic environments, the issue becomes sharper because the system may not only generate text but also act, which means context changes can translate directly into execution changes.

Security teams should treat context boundaries as governance objects, not just engineering details. The AI governance perspective in the NIST AI Risk Management Framework is helpful here, and so are runtime-focused approaches such as OWASP’s LLM application guidance and the SLSA framework for supply chain trust in software components that feed context. The practical goal is to know which inputs can change system behaviour, which of those inputs are trusted, and how rapidly exposure can escalate when those assumptions break.

Organisations typically encounter dynamic context risk only after an agent has retrieved the wrong data, invoked the wrong tool, or exposed a sensitive action path, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why does Model Context Protocol create identity risk for enterprises?
• How should security teams use context-based authentication in high-risk environments?
• When does context-based provisioning create more risk than it reduces?
• When does dynamic secret management create more risk than it reduces?