Context manipulation is the practice of shaping what an AI agent believes about its current situation by controlling the information surrounding its task, rather than issuing it a direct command. Where a prompt injection says "do this," context manipulation says nothing directly at all. It just makes sure the agent's context window contains a fabricated ticket history, a misleading document, a stale but confident-looking status update, so that when the agent reasons about what to do next, it draws the wrong conclusion from information that looks entirely legitimate. It's a subtler attack than most people picture when they think about agent security, and it's also harder to catch, because nothing in the interaction looks like an instruction being overridden.
Context is bigger than the current prompt
In an agentic workflow, "context" includes retrieved documents, prior conversation history, tool outputs, memory entries, and system state pulled in from wherever the agent's framework assembles it. Every one of those components is a candidate for manipulation, and an attacker only needs to control one of them convincingly to shift the agent's overall picture, even while every individual piece of the conversation looks unremarkable on its own.
Fabricated status and history
A common pattern injects false state: a document claiming an approval already happened, a ticket history implying a refund was already promised, a calendar entry suggesting a meeting authorized a change that never actually occurred. The agent doesn't need to be tricked into breaking a rule. It just needs to believe the rule's precondition has already been satisfied, and it'll proceed as though everything is in order.
Selective omission works as well as fabrication
Manipulating context doesn't always mean adding false information. Sometimes it means making sure the agent never sees the piece of context that would have triggered a different, more cautious decision, a policy update, a flagged account, a prior denial. If an attacker can control which documents get indexed or which records surface in a retrieval step, they can shape an agent's decision just by curating what it has access to at decision time.
Why this is different from a single injected instruction
A directly injected instruction is a discrete event you can, in principle, detect and block at the input layer. Context manipulation is distributed across multiple pieces of seemingly ordinary information, assembled by the system's own retrieval and memory logic, which means there's often no single malicious-looking artifact to flag. The manipulation lives in the combination, not in any one document.
Defending the assembly step, not just the inputs
Because context gets assembled from multiple sources before the agent ever reasons over it, a meaningful defense checks the assembly step itself: are retrieved documents from trusted, access-controlled sources, is stale information being refreshed rather than silently trusted indefinitely, does the system cross-check high-impact claims (an approval, an authorization) against a source of record rather than accepting them from whatever document happened to surface. This shifts some of the defense burden from "detect the attack" to "reduce how much unverified material reaches the agent's context in the first place."
Long conversations make context harder to audit
The longer a conversation or task runs, the more context accumulates, and the harder it becomes for anyone reviewing the session afterward to identify exactly which piece of information led the agent to a particular conclusion. A manipulated fact introduced early in a long session can influence a decision made much later, well after the original context has scrolled out of easy view, and a reviewer scanning only the final exchange will miss it entirely. Retaining the full context history in a form that's actually reviewable, rather than only the final turns, matters specifically because context manipulation attacks are designed to work quietly over time rather than in a single obvious moment.
Where TELEON fits
Because context manipulation ultimately needs to produce a real action to matter, enforcing policy at the tool-call boundary gives teams a backstop that doesn't depend on catching the manipulation in the context itself: a claimed approval or authorization can be checked against actual policy state at the moment of action, regardless of what the agent's context appeared to show. TELEON's audit trail also helps reconstruct, after an incident, exactly what context the agent had at the time of a disputed decision.
Reducing exposure to context manipulation at the source, access-controlling retrieval, refreshing stale data, cross-checking claims against a system of record, is application and data-architecture work that has to happen upstream of any gateway.
A short checklist
- Access-control what documents and records can enter an agent's retrieval pipeline.
- Cross-check high-impact claims, approvals, authorizations, against a system of record.
- Refresh time-sensitive context rather than trusting stale information indefinitely.
- Review what gets omitted from context, not only what gets included.
- Enforce final-action policy checks that don't rely solely on the agent's context.
- Capture and retain the full context an agent had at the time of a key decision.
- Test scenarios where context is fabricated or selectively incomplete, not just direct injection.
Context manipulation succeeds precisely because it doesn't look like an attack. It looks like the agent doing exactly what it's supposed to do with the information it was given. That's why the fix isn't sharper instruction-following, it's making sure the information reaching the agent, and the checks applied before it acts on that information, deserve the trust the agent is putting in them.