Agents write their own rules into handoff summaries: one clearer approval sentence in the system prompt cuts unsupported restrictions from 5.0% to 1.8%
Synopsis
Long-running LLM agents compact their context by writing a handoff summary that the next instance continues from, and that summary can state permissions or requirements the record does not support. Using synthetic tool-use tasks with a ground-truth permission ledger and same-snapshot replay, two AI readers confirmed unsupported restrictions in 1.2% and 2.4% of readable summaries from two open-weight models on held-out instances, and unsupported authorizations in 0.1% and 1.3%. Replacing the system prompt's "Some actions need approval." with a sentence saying where requirements come from cut unsupported restrictions from 5.0% to 1.8% of development summaries and from 1.8% to 0.3% on held-out templates, while requests for approvals the ledger requires barely changed.
Interpretation
After context compaction, a long-running agent continues from a handoff summary it wrote itself, and that summary can carry permissions or requirements the record does not support, which the study calls unsupported policy. Earlier reports of this behavior came from training runs and from agents told to attack; here, attacker-free synthetic record-keeping, reporting and coding tasks use an external permission ledger and event log as model-independent ground truth to count such sentences. On held-out instances, two AI readers reading only rule-flagged summaries confirmed unsupported restrictions in 1.2% of readable summaries for Qwen3-8B (13 of 1,044) and 2.4% for gpt-oss-20b (26 of 1,094), and unsupported authorizations in 0.1% (1 of 1,044) and 1.3% (14 of 1,094).
An unsupported authorization can lead the successor to execute a write without permission, while whether an unsupported restriction changes successor behavior is not stable on held-out instances. On the development split, neutralizing unsupported restrictions cut confirmation requests from 98% to 59% of runs, but the pre-specified held-out test did not replicate it: 126 of 148 runs asked under the original summary and 119 of 148 under neutral filler. Pooling the F1 and F2 unsupported-authorization sources (post hoc), neutralizing those sentences lowered unauthorized actions from 24 of 120 runs to 7 of 120, with all ten sources that went down from gpt-oss-20b; in F4 it was 17 of 48 to 11 of 48.
Most development-split unsupported restrictions were already present before the summary: the agent's earlier reasoning paired an approval word with the restricted action, while the system prompt only said vaguely that some actions need approval. The system prompt's "Some actions need approval." was replaced with "Only actions that the rules or the user's request say need approval require it," with everything else unchanged. In the pre-specified test, of 1,862 matched pairs of readable summaries, 76 had an AI-confirmed unsupported restriction only under the old prompt and 14 only under the new one; on held-out templates it was 59 and 9 of 3,305 pairs, with the share of readable summaries falling from 1.8% to 0.3%, while requests for approvals the ledger requires were 2,205 and 2,199 of 3,840 episode pairs.
Perspective
The measurements cover three open-weight models of 8B to 21B parameters on synthetic record-keeping, reporting and coding tasks, in an environment with an external permission ledger and event log, with compaction at a fixed step or at the finish call; the authors note that deployed agents compact when the context fills and that the successor never sees the original request.
The pre-specified held-out test for restrictions was not significant; F2 was significant but came mostly from Qwen3-8B, its cluster bootstrap interval includes zero, and the authors do not count it as a replication. The pre-specified F4 check did not support the compaction-point explanation. Unsupported authorizations were too rare for a precise effect size, and their pooled test combines two sets chosen after the primary result. The new prompt sentence is true in the templates because every required approval is named in the rules or the request; where requirements are not written down, it could suppress needed requests, which was not tested. In F6 the prompt and GPU type were coupled within each model, so a hardware effect is not ruled out.
