An agent that can be redirected by text in a web page, email, tool result or peer message will pursue the attacker’s goal with its own permissions, across many steps.
- Treat everything the agent reads as untrusted data, and keep the user’s goal and constraints outside the context the model can edit.
- Authorize each action against the original user’s intent and permissions, not the agent’s current plan.
- Require confirmation for actions that change goals, involve new parties or have high impact, and log plans and actions for review.
Guides on this site
Contain prompt injection at the application boundary
Assume retrieved content can influence model output; enforce data access and consequential actions in components the model cannot authorize for itself.
Constrain MCP and multi-agent trust boundaries
Validate each connection and delegated action without treating a token for another service, a tool description, another agent or a state handle as authority.
Sandbox model-generated code and computer-use agents
Run the code an agent writes, and agents that drive a browser or desktop, inside a boundary built for hostile code: a disposable runtime with no secrets and no default network, hard resource limits, and a person in front of every side effect.
Defend agent memory and context against poisoning (OWASP ASI06)
OWASP ASI06 Memory & Context Poisoning: how an instruction or false fact saved once in agent memory, conversation summaries or a retrieval store steers later sessions, users and agents, and the write, scope, provenance, expiry and recovery controls that contain it.
Practice
- Enforce retrieval and tool boundaries across crashes · Local project
- Run model-generated Python in a locked-down container · Local project
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.