Runtime context poisoning is an attack that corrupts the information an AI agent uses while making decisions during execution. In practice, malicious prompts, tool outputs, memory entries, or retrieved data can steer an agent toward unsafe actions, data leakage, or policy bypass. It is a live integrity risk in agentic AI systems.
What runtime context poisoning changes in an AI agent
Runtime context poisoning is dangerous because the agent is acting on live, decision-shaping context rather than static code alone. If an attacker can alter what the agent sees at execution time, they can influence planning, tool use, content generation, and guardrail decisions without changing the underlying model.
The core security problem is integrity. The poisoned input may arrive through a prompt, a tool response, a memory record, or retrieved content, but the effect is the same: the agent reasons over compromised context and may treat malicious instructions as trusted state.
Common poisoning sources during execution
Runtime poisoning can enter through several channels, and each one changes the agent’s behaviour in a slightly different way. Prompt injection can reframe the task, tool output can smuggle instructions, memory entries can persist bad assumptions across sessions, and retrieval can surface deceptive or stale material at the moment of decision.
That mix makes the issue harder than ordinary input validation. The problem is not only whether the content is “malicious” in a general sense, but whether it is allowed to shape the agent’s next action at runtime.
For that reason, memory handling and cross-session isolation matter as much as prompt hygiene. NHIMG’s AI Agent Memory Security Guide is a useful companion for understanding how poisoned or shared memory can distort agent behaviour.
Why poisoned context is especially dangerous
Unlike a one-off input error, poisoned runtime context can steer an agent into unsafe actions that look internally consistent to the system. That can include leaking secrets into a tool call, bypassing a policy check, selecting the wrong resource, or amplifying a false assumption through later steps in the workflow.
The danger increases when the agent has tool access or can chain decisions across multiple turns. A single compromised context element can cascade into broader data exposure, privilege misuse, or business-process manipulation if the agent treats it as authoritative.
One practical way to frame the problem is that the attacker is targeting the agent’s decision substrate, not just a message field. MITRE’s adversarial AI threat matrix and OWASP’s Agentic AI Top 10 both treat memory manipulation, context poisoning, and related agent abuse patterns as first-class threats.
Detection and control boundaries
Defending against runtime context poisoning depends on drawing sharp boundaries around what the agent may trust, retain, and reuse. Systems should distinguish user content, tool output, retrieved content, and internal policy or system instructions so that a poisoned source cannot silently gain higher authority inside the execution flow.
Telemetry also matters. When an agent behaves unexpectedly, investigators need enough logging to reconstruct which prompt fragments, tool outputs, memory objects, and retrieved passages influenced the action. Without that evidence trail, it is difficult to prove whether the failure was a model error, a workflow bug, or an injected context payload.
Because many agentic systems are built from connected services, runtime context poisoning should also be viewed alongside broader runtime and transport controls. NIST SP 800-190 offers a useful runtime-security lens for containerised AI services, while the MCP authorization specification shows why audience-bound tokens and no token passthrough matter when agents depend on external tools.
How organisations should think about post-exposure review
When poisoning is suspected, the key question is not only what the agent did, but what it saw before it did it. A useful review traces the execution path backward through memory, retrieval, tool responses, and any human-authored prompts that may have been blended into the live context.
That review often reveals whether the compromise was transient or persistent. A bad prompt may disappear after the run, but a poisoned memory object, cached retrieval item, or reused context fragment can keep influencing later decisions unless it is removed or rewritten at the source.
For broader governance and threat modelling, the same issue appears in the OWASP Agentic AI Top 10, the CSA MAESTRO agentic AI threat modeling framework, and the NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where integrity monitoring, auditability, and access restriction need to be coordinated.
Risk and Threat Considerations
Runtime context poisoning is high risk because it turns the agent’s own decision-making environment into the attack surface. The attacker does not need to replace the model, only the context that the model trusts long enough to act on it.
Failure mechanism: Malicious prompts, tool outputs, memory entries, or retrieved records are accepted into the live reasoning context, where they alter planning, override intent, or steer the agent toward unsafe actions.
Impact: The agent may leak sensitive data, bypass policy, misuse tools, or propagate false instructions across later steps and sessions, creating both immediate and persistent compromise.
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 MITRE ATLAS address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI06 — Memory & Context Poisoning | Defines poisoning of agent memory and context during execution. |
| Recommendation — Separate untrusted runtime context from policy and monitor for memory and retrieval poisoning. | ||
| MITRE ATLAS | ATLAS — Adversarial AI Threat Framework | Covers prompt injection, context poisoning, memory manipulation, and agent abuse techniques. |
| Recommendation — Map observed runtime poisoning patterns to adversarial AI techniques and hunt for injected context sources. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Runtime poisoning investigations depend on logs that reconstruct what influenced an agent decision. |
| AC-6 — Least Privilege | Limits the damage when poisoned context steers an agent toward unsafe tool or data access. | |
| SI-7 — Software, Firmware, and Information Integrity | Runtime poisoning is an integrity failure affecting the information the agent uses to decide. | |
| Recommendation — Log prompt, retrieval, memory, and tool events so poisoned context can be traced after execution. Restrict agent tool and data permissions to minimise the blast radius of poisoned context. Apply integrity checks to retrieved and stored context before it can influence agent actions. | ||
Practitioner Guidance
Why practitioners should care: Treat runtime context as a governed security boundary, not a passive message buffer. The practical challenge is deciding which content may influence the agent, how long it may persist, and what provenance is required before it can affect execution.
What to watch for: Reused memory, ambiguous retrieval, tool output that contains instructions, and any workflow where untrusted content can be blended with system guidance are all signs that poisoning resistance is too weak. If the agent can act on it, the context needs the same scrutiny as any other trusted control plane input.