To keep a long run inside the context window, the agent compresses its own memory. Old messages get replaced by a model-written summary, so the run can continue.
A summary is a compression written by a model, from content the model does not fully control. Two things can go wrong with that, and both are quiet.
A summary is a decision about what the agent keeps knowing
Compression is not neutral. When the summariser replaces twenty messages with a paragraph, it decides what survives into the next step and what the agent effectively forgets. Most of the time that is fine: it drops small talk and keeps the task.
The failure is when the thing dropped is safety-relevant. Consider a run where, at step 3, the agent correctly refused to do something, or set a constraint: "the user is not authorised for bulk deletes, so I will not run one." Twenty steps later the context is summarised. If that refusal does not make the summary, the model continues from a version of history where it never happened. The boundary it set is gone, not because it was overridden, but because it was compressed out.
The agent did not change its mind. It lost the memory of having made one.
A refusal set at step 3 is dropped by the summary at step 20. The model continues as if it never happened.
An attacker can aim at the summary
That failure is bad by accident and worse on purpose. Because the summariser reads the run's content, and that content includes untrusted tool results and retrieved chunks, an attacker with a foothold in that input can influence what the summary keeps and drops.
The move is not subtle to describe. Flood the context with plausible filler after a malicious action, and a length-driven summariser is more likely to compress the malicious step into a single bland line, or out entirely. The evidence of what happened gets summarised down to nothing, while the run continues on the clean-looking summary. The attacker is not hiding from your logs. They are hiding from the model's own working memory.
The second risk: the log and the view diverge
Here the storage-versus-presentation split, which is good design, has a security consequence worth naming.
The events are the immutable record. The compressed contents are what the model actually saw and acted on. Those are now two different things, on purpose. That is exactly what you want for an audit trail: the full history survives even as the view is trimmed.
The consequence to hold: what your log shows is not what the model reasoned over. An investigator reading the events sees the complete run. The model made its decision from a summary that may have omitted a step in the events. Neither is wrong, but they are not the same, and confusing them leads an investigation astray, "the log clearly contained the warning" when the model, reasoning from the summary, never saw it.
Keeping compression honest
The controls keep the summary from dropping what matters, and keep the two views reconcilable.
| Control | What it protects |
|---|---|
| Never summarise safety-relevant events | A refusal, a boundary, a failed auth check is pinned in context, exempt from compression |
| Preserve a structured spine, not just prose | Keep the list of actions taken and constraints set, verbatim, alongside the prose summary |
| Record what each compression dropped | The events log notes "summarised steps 3-20", so a gap is visible, not silent |
| Bound compression by content, not only length | A step that took an irreversible action is not eligible to be compressed away |
| Reconcile the log against the view in review | An investigation reads both the events and the summary the model actually saw |
| Alert on heavy compression before a sensitive action | A run that summarised aggressively right before acting deserves a second look |
Pin safety-relevant events, keep a structured spine, and record what each compression dropped.
The first row is the load-bearing one. A small allow-list of event types that can never be summarised, refusals, boundaries, authorisation results, means the agent's working memory always contains the constraints it set, no matter how much else gets compressed. Compression stays a tool for saving space, not a way to launder away the very facts that keep the agent safe.
What this touches
For the frameworks, this sits across the MAESTRO Agent Frameworks and Monitoring layers. The dropped- safety-fact case maps to T1 Memory Poisoning, which the pack scopes to short-term memory as well as long, and compressing away a constraint is manipulating short-term memory to alter a decision. The log-versus-view divergence maps to T8 Repudiation and Untraceability, since it undermines a clean account of what the agent actually reasoned over. In the OWASP Agentic Top 10 the anchors are ASI06 and, for the traceability side, ASI08 and ASI09.
On the regulatory side, framed as scope rather than a citation: this lands in record-keeping and decision traceability, obligations across GCC rulebooks, which assume the record and the basis for a decision line up. An agent that decided from a summary its own log does not fully reflect is a traceability gap those rules already govern, even though they pictured a person reading a file rather than a model reading a compressed view. Which obligations apply depends on your regulator and architecture, and that mapping is an advisory estimate until someone checks it properly.
The part worth keeping
Compression is necessary. A long run overflows the window without it, and the storage-versus- presentation split that makes it safe is good engineering. Nothing here argues against summarising.
The point is that a summary is a decision about what the agent keeps knowing, and some facts are too important to let a length heuristic drop. Pin the safety-relevant ones, keep a verbatim spine of actions and constraints, and remember that your complete log is not what the model saw. Do that and compression saves space without quietly editing the agent's understanding of its own run.