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.
Why a coding agent can become unsafe without any attacker present
A coding agent can fail safely in the abstract and still become unsafe in practice when its plan becomes stale. If it reasons over one repository state, one dependency set, or one deployment target and then executes later without re-checking, normal change can turn a sensible action into an unsafe one. For coding agents, the problem is not only malicious prompt injection or adversarial abuse. It is also drift between intention and execution in ordinary engineering workflows.
That matters because coding agents are often used for routine tasks that look low risk: refactors, test fixes, dependency updates, cleanup scripts, or infrastructure changes. Those are exactly the tasks where people tend to relax scrutiny and let the system move quickly. The result is that the control gap is created by process, not by an attacker. NIST’s NIST AI Risk Management Framework is relevant here because it treats trustworthy AI as a lifecycle problem, not a single prompt problem. In practice, many teams discover unsafe agent behaviour only after the environment has changed between plan and execution, not during the initial analysis.
The key security implication is that an agent can preserve logical consistency while still acting on invalid assumptions. A build may change, a branch may move, a file may be edited by another developer, or a cleanup command may target a broader scope than the agent originally inspected. When the harness does not force fresh confirmation, the agent can carry forward a now-wrong plan and still look confident.
How coding agents become unsafe in normal development workflows
The unsafe condition usually appears when the agent is allowed to separate reasoning from action. A coding agent might inspect code, form a plan, and then execute a sequence of edits or commands after some delay. If the harness does not require a fresh read of the relevant state at execution time, the agent is operating on assumptions that may already be obsolete. That is why the risk is not limited to adversarial misuse. It is a control problem around verification, scope, and timing.
In practice, the failure mode often shows up in one of three ways. First, the agent acts on a changed repository state and modifies the wrong lines or files. Second, it runs a command whose blast radius is larger than intended because the surrounding context has shifted. Third, it completes a valid action against the wrong target, such as deleting, overwriting, or redeploying something that looked correct when planned but no longer is. The underlying issue is that the agent lacks a hard re-validation step at the point of execution.
- Plan stale, action current: the environment changed after planning.
- Scope drift: the command remains syntactically valid but becomes operationally broader.
- Context loss: the agent no longer has the exact state needed to justify the action.
That is why harness design matters as much as model capability. A coding agent needs explicit checkpoints for re-reading state, confirming destructive scope, and rejecting silent carry-over of earlier assumptions. The same principle is reflected in the OWASP OWASP Top 10 for Agentic Applications 2026, which focuses on agentic control failures, not just prompt content. Where teams skip those checks, the system can remain technically obedient while becoming operationally unsafe.
This guidance breaks down when the task is genuinely stateless or the action is fully constrained by an external guardrail that re-validates every step before execution.
Where routine commands hide the biggest reliability gap
Tighter agent autonomy often increases speed, but it also reduces the number of moments where a human or harness can notice that the world has changed, requiring teams to balance throughput against verification overhead.
That tradeoff matters most with routine commands because routine work attracts less review. A developer is more likely to inspect a scary delete request than a familiar formatting change, dependency bump, or local cleanup command. Yet those routine actions can still become unsafe if the target moved, the branch advanced, or the command expanded beyond the intended scope. The risk is less about obvious destruction and more about normalised trust in low-friction actions.
There is no universal consensus that every agent action needs the same level of re-checking. The practical rule is to distinguish between commands that are reversible and tightly scoped, and commands that can touch shared state, production assets, secrets, build artefacts, or deployment paths. If the action can create durable impact, the harness should require fresh confirmation from current state rather than relying on the earlier plan alone. The MITRE ATLAS adversarial AI threat matrix is useful as a complementary lens when the same execution path could later be abused by an attacker, but the unsafe condition here exists even before any adversary enters the picture.
Where this guidance breaks down is in environments that do not expose enough state to let the agent re-check meaningfully, because then the problem shifts from control design to tool design.
Risk and Threat Considerations
The material risk is operational and trust-related: a coding agent can make harmful changes by acting on stale context, even when no attacker is involved. That creates exposure in repositories, build pipelines, deployments, and cleanup jobs where the environment can change between planning and execution.
Failure mechanism: the agent forms an action plan from one snapshot of state, then executes later without a mandatory refresh or scope confirmation. Recognised mechanisms include stale assumptions, race conditions, command overreach, and unchecked carry-forward of earlier context.
Impact: incorrect code changes, unintended deletion or overwrite, broken deployments, wider-than-intended system changes, and loss of trust in automation because the agent appears confident while acting on outdated information.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN — Govern | Addresses AI lifecycle governance and trustworthiness under changing conditions. |
| Recommendation — Apply GOVERN to require fresh state validation before an agent executes impactful code changes. | ||
| OWASP Agentic AI Top 10 | A2 — Unsafe Tool Use | The core issue is an agent using tools after its context has gone stale. |
| A5 — Improper Output Handling | Unchecked agent output can become unsafe when it is executed without verification. | |
| Recommendation — Constrain tool actions so the agent rechecks scope and target state before each execution. Validate generated commands and edits before execution when output can alter real systems. | ||
| MITRE ATLAS | ATLAS — Adversarial Threat Matrix | Supports analysis of how agentic execution paths can later be abused or escalated. |
| Recommendation — Map agent execution paths to ATLAS techniques and harden the steps that can be abused. | ||
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Unsafe agent actions often arise from uncontrolled changes to software and deployment state. |
| Recommendation — Use CIS 4 to enforce checked, approved, and scoped changes for agent-driven modifications. | ||
Practitioner Guidance
What to prioritise: Treat re-validation as a control requirement for any action that can change shared state. The first question is not whether the agent is smart enough, but whether the harness forces it to prove the target is still the target immediately before execution.
Decision rule: If the action touches production, shared repositories, secrets, or irreversible infrastructure state, require a fresh state read and an explicit scope check. If it is purely local and easily reversible, the review burden can be lighter, but it should still not rely on a stale plan.
What practitioners underestimate: Routine commands are often the most dangerous because they are least reviewed. Teams usually design controls around dramatic failures, then miss the gradual erosion of safety in normal developer workflows.
Practitioner takeaway: The real safety boundary is not “attacker present” versus “attacker absent”; it is whether execution is still justified by the current environment at the moment the agent acts.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
