Notifications
Clear all
Topic starter
06/09/2026 6:21 pm
TL;DR: A coding agent can act on a fact that has already changed, with stale context driving destructive outcomes even when every step looks ordinary, according to Backslash Security. The finding matters because AI coding agents are only as safe as the harness checks around them, and re-reading at the moment of action becomes the real control.
NHIMG editorial — based on content published by Backslash Security: When your coding agent acts on a fact that has already changed
Questions worth separating out
Q: What breaks when a coding agent loses context during a long session?
A: The agent can start optimising for the wrong goal, repeat tool calls, or produce code that fits the local test but violates the broader requirement.
Q: Why do agent approval gates miss runtime risk?
A: Approval gates usually inspect the command or request, not the environment value that command resolves to when it runs.
Q: How should security teams handle context changes in coding agents?
A: They should force a fresh read whenever the agent crosses a branch, file, or environment boundary, and again immediately before any destructive or privileged action.
Practitioner guidance
- Enforce last-mile re-reading for mutable values Require the agent to re-read any file, branch, or configuration value immediately before it writes or executes against it, especially when that value can change between turns.
- Expose command resolution before approval Make the agent state the resolved target, environment, or secret source in plain text before a privileged command is approved so reviewers can evaluate what the command will actually hit.
- Separate source reads from destination writes with explicit checks Add harness logic that compares the value the agent consumed with the object it is about to modify, rather than only checking whether the destination file changed since it was read.
What's in the full report
Backslash Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Measured batch-by-batch drift results across Claude Sonnet 5 and Opus 5 in the cleanup, config, host, and secret scenarios
- The exact harness setup, branch-switch sequence, and control-run design used to separate genuine drift from baseline behaviour
- The recovery pattern where Opus re-read state at action time and avoided or reversed the production wipe in several runs
- The full FAQ spread on why auto mode, model size, and approval rules did not remove the underlying gap
👉 Read Backslash Security's analysis of stale context in coding agents and production risk →
Coding agents and stale facts: where harnesses still fall short?
Explore further
06/09/2026 6:21 pm
Stale context is now an identity control problem, not just a model quality problem. When an AI coding agent acts on a value that has already changed, the failure sits in the governance layer between read, decision, and execution. That is the same structural issue identity teams face when access decisions are made on stale lifecycle data. The practitioner takeaway is that runtime validation has to sit inside the control path, not after the fact.
A question worth separating out:
Q: When does a coding agent become unsafe even without an attacker?
A: It becomes unsafe when the world changes after the agent has already formed its plan and nothing in the harness forces it to re-check. That can happen during normal development, deployment, or cleanup work. The risk is highest when the command is routine, because routine commands get less scrutiny than obvious destructive ones.
👉 Read our full editorial: Coding agents fail when facts go stale between read and action
