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.
At a glance
What this is: Backslash Security shows that coding agents can execute destructive actions when the context they trusted has gone stale between read and write.
Why it matters: IAM, PAM, and NHI teams should treat agent harness design as a governance problem because stale context can turn routine automation into unintended privilege use or destructive change.
Context
A coding agent is only as reliable as the facts its harness gives it at the moment it acts. When a branch switch, file edit, or rotated secret changes the world after the read, the agent may still proceed on stale context and produce destructive outcomes.
This is an identity and governance problem as much as a developer productivity problem. The same gap affects machine identities, delegated access, and agentic AI systems that rely on text snapshots of state rather than live re-validation before execution.
Backslash Security’s experiment shows that the risk is not limited to obvious prompt injection or malicious instruction. The ordinary workflow itself can become unsafe when the execution layer never re-checks the assumption that justified the action.
Key questions
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. Context loss also weakens governance because the system can no longer preserve policy intent across the full execution path. That is why context-window utilisation should be monitored as a control signal.
Q: Why do branch switches and file edits create risk for coding agents?
A: Because those changes can alter the meaning of a previously read value without the harness announcing it. The agent keeps reasoning from the old description, so a command that looked safe when read can become destructive by the time it runs.
Q: How can security teams tell when an agent workflow is becoming unsafe?
A: Look for sessions where private data, untrusted input, and an external communication path all appear in the same task. That combination signals that the agent can be steered from routine work into leakage or misuse. The useful indicator is not model quality, but whether the workflow can support risky action convergence.
Q: Should organisations treat tool-calling agents as part of identity governance?
A: Yes, when those agents can trigger real actions in enterprise systems. At that point they behave like governed non-human identities with a limited operational scope. Identity governance should cover their permissions, review cadence, test coverage, and revocation path before the agent reaches production.
Technical breakdown
Why stale context breaks coding agent decisions
A coding agent splits into a model that reasons and a harness that executes. The model is stateless between turns, so it only knows what the harness last read back into context. If a file, branch, or environment value changes after that read, the model still reasons from the old snapshot unless the harness refreshes it. That is why a command can be syntactically correct and still target the wrong database, secret, or config value. The failure is not intelligence, it is time lag between observation and action.
Practical implication: re-read any value that can change before the write or command that depends on it.
Where harness checks stop short
Some controls compare a file against the version it was originally read from, but only when the same object is being rewritten. That means cross-file actions, branch changes, and commands that resolve dynamically can slip through because no single stale value is being overwritten. If the agent reads db.conf and writes reset_db.sh, or reads a secret and writes a deploy script, the mismatch is not automatically visible to the guardrail. The safety problem sits in the gap between source and destination, not in either file alone.
Practical implication: validate the resolved target, not just the command or file path shown to the agent.
Why approval is not enough for agentic execution
Approval gates usually judge the command, not the runtime state the command will touch. A developer can approve ./reset_db.sh without seeing whether it will clear dev or prod at execution time. In agentic systems, the meaningful control point is the state resolution step immediately before action. That is where a branch checkout, environment change, or secret rotation needs to be re-confirmed. Without that re-validation, the approval becomes a signature on a stale assumption rather than a decision on current reality.
Practical implication: require a fresh state confirmation immediately before destructive or privileged actions.
Threat narrative
Attacker objective: The practical objective is not a human attacker’s theft, but an unsafe automated action that changes production state, weakens controls, or exposes secrets.
- Entry begins with a normal read of configuration or environment state that the agent treats as current.
- Credential or state drift occurs when the branch, secret, host, or auth flag changes after that read without the harness announcing it.
- Impact follows when the agent acts on the stale value and wipes production data, disables authentication, or embeds a retired secret into a live script.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Stale context is the real trust boundary for coding agents. The important control is no longer just who can trigger an agent, but whether the agent’s picture of state is still true when it acts. That shifts governance from prompt safety to execution-time verification. Practitioners should treat every stateful action as a live trust decision, not a one-time approval.
Harness design determines whether agentic workflows are governable at all. A stateless model fed by stale context will confidently act on outdated facts, even when each individual step looks ordinary. That means the control plane must own freshness, re-validation, and state-aware guardrails. For teams governing AI-assisted development, this is a design requirement, not a tuning issue.
Agentic execution creates a new form of governance debt: read-time assumptions outlive their validity. The article’s key concept is not model hallucination, but stale-assumption drift, where the value that justified an action no longer exists by the time the action runs. That is directly relevant to NHI and agentic AI security because delegated systems often act on cached authority or cached state. Practitioners should make freshness a first-class policy attribute.
Approval workflows need to move from intent checking to state checking. Traditional change review assumes the request remains stable long enough to be assessed. In agentic systems, the request may still be valid while the underlying target has changed completely. That means governance has to evaluate resolved destination, active branch, current host, and live secret state before execution. Practitioners should redesign approvals around runtime truth, not static intent.
This pattern also exposes an identity boundary failure. When a coding agent writes to a production system using stale context, it is effectively exercising delegated non-human authority without current verification of the target. That makes the problem relevant to NHI governance, workload identity, and agentic AI controls. Teams should classify these agents as governed identities with freshness requirements, not just tooling.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Read next: Agentic AI Security Guide
What this signals
Stale-assumption drift: coding agents do not need a malicious prompt to become unsafe; they need a world that changes after the read and before the action. That makes freshness a control objective in its own right, especially where agents can touch production systems, secrets, or identity-bound workflows.
For teams running agentic development workflows, the practical question is whether the harness re-validates state at execution time or merely preserves a history of what was true earlier. If the answer is the latter, the workflow is relying on stale authority and should be treated as a governance gap rather than a productivity shortcut.
For practitioners
- Require runtime re-reading before privileged actions Make the agent re-read any file, branch, host, or secret that can affect the command immediately before it writes or executes. Treat stale reads as invalid input, not as a warning condition.
- Confirm resolved targets, not just commands Show the actual environment, database, or key the command will resolve to before approval, so reviewers see the live target rather than the nominal script name.
- Reset agent context after branch switches Force a fresh session or a mandatory state refresh after checkout, pull, or any environment change that can alter the meaning of previously read values.
- Block cross-file writes that inherit stale values Add guardrails for cases where a value is read from one file and written into another, because same-file modified-since-read checks do not catch that drift.
Key takeaways
- The core risk is not model rebellion but stale context, where an agent acts on a snapshot that no longer matches the machine.
- The article’s examples show how routine changes such as branch switches, rotated secrets, and config edits can lead to destructive outcomes.
- The decisive control is execution-time re-reading of the live target, not approval of the command in the abstract.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article shows agents acting on stale auth and environment state before execution. |
| NHI-07 — Long-Lived Secrets | Rotated-out secrets being reused reflects poor lifecycle control over credentials. | |
| Recommendation — Revalidate identity and target state before any privileged agent action. Rotate and re-issue secrets so agents never act on stale credential values. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The issue is delegated agent authority acting beyond the freshness of its last verified state. |
| Recommendation — Constrain agent privilege to the exact state validated at execution time. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about how permissions and target access can drift between read and action. |
| Recommendation — Tie permissions to live context checks before executing sensitive agent commands. | ||
| MITRE ATT&CK | TA0006; TA0040 — Credential Access; Impact | Stale secrets and destructive writes map directly to credential abuse and operational impact. |
| Recommendation — Map stale-secret and destructive-write scenarios to TA0006 and TA0040 in threat detection. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret rotation and reuse are central to the article’s failure mode. |
| Recommendation — Apply IA-5 to enforce rotation and immediate invalidation of stale authenticators. | ||
Key terms
- Stale Assumption Drift: The condition where a system makes a decision based on information that was true when read but false when acted on. In agentic workflows, this is a governance problem because the execution layer may preserve intent while the target state has already changed.
- Harness: The harness is the layer of instructions, policies, and approval logic wrapped around an AI agent. It is where organisations try to constrain behaviour, but it only works if the rules are explicit, current, and enforced outside the model itself.
- Execution-Time Re-Validation: A control pattern that forces a system to confirm live state immediately before it acts. It reduces the risk of acting on stale data, especially where branches, secrets, hosts, or permissions can change between the initial read and the final command.
- Context Decay: Context decay is the loss of decision-quality information between the moment a finding is discovered and the moment it is acted on. In dynamic cloud and identity environments, asset ownership, privilege, and exposure status can change so quickly that stale findings create governance error.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps security and IAM practitioners build controls for delegated systems that act on live state.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org