At about 11 p.m. on February 26, 2026, Claude Code ran terraform destroy against the AWS infrastructure behind DataTalks.Club. It deleted the production database, VPC, ECS cluster, load balancers, bastion host, and automated database snapshots, according to operator Alexey Grigorev’s postmortem.
The incident wasn’t a breach, and the agent didn’t seize control of the environment. Alexey Grigorev, who operated the system and later published a detailed postmortem, had allowed Claude Code to run Terraform commands while he tried to clean up duplicate AWS resources. Because the state file remained on an old computer, Terraform treated the existing infrastructure as absent and began creating duplicate resources. Later in the session, unpacking an archive replaced the current state with an older file that expanded the scope of terraform destroy to the DataTalks.Club infrastructure. Grigorev didn’t stop it because he believed the command applied only to the duplicates.
AWS recovered a snapshot about 24 hours later. The database contained 2.5 years of course submissions, including 1,943,200 rows in one answers table. Grigorev described the failure plainly: he had delegated destructive commands, hadn’t tested the full recovery path, and hadn’t placed enough barriers between a mistaken plan and production deletion. His account also records an uncomfortable detail, that Claude had advised him to keep the two projects’ infrastructure separate before the work began.
The session combined interpretation, recommendation, and execution inside one context and one credential boundary. When that context became wrong, no independent control checked the destroy plan against its intended scope.
The Failure Extended Beyond One Bad Command
The decision relied on incomplete and then stale evidence. Terraform state identifies which deployed resources correspond to a configuration. When the state changed during the session, the meaning and consequence of the proposed action changed with it.
The workflow also lacked a policy boundary between cleanup of newly created resources and deletion of long-lived production infrastructure. The instruction existed in conversation, but the execution environment didn’t enforce it.
Then the agent both recommended and executed the destructive action. The operator saw a plausible explanation and let the command proceed, yet no separate release owner, cloud control, or approval step checked the actual destroy plan against the intended scope.
Recovery shared the same failure boundary. The deletion reached the automated snapshots that the operator expected to use for restoration. A backup that disappears with the system it protects doesn’t provide an independent recovery path.
This is a governed decision-system problem. Evidence, policy, authority, action, and recovery failed together. Replacing the model or adding a warning to the prompt wouldn’t repair that whole path.
Coding Agents Change The CI/CD Trust Boundary
The DataTalks.Club incident began with a mistaken operating context, not an external attacker. June brought two different cases that show what happens when hostile input reaches a coding agent with useful tools.
On June 5, Microsoft Threat Intelligence published research into the Claude Code GitHub Action. A prompt hidden in GitHub issue or pull-request content could steer the agent toward files available inside its CI runner. Microsoft demonstrated that the agent’s Read tool could access /proc/self/environ, which contained an unscrubbed Anthropic API key, even though subprocess environment scrubbing protected Bash execution. Microsoft reported the issue to Anthropic on April 29, and Anthropic patched it in Claude Code 2.1.128 on May 5. The disclosure documents a tested vulnerability, not a confirmed customer breach. Microsoft’s research shows why file access, secrets, untrusted repository content, and outbound communication can’t share an unrestricted execution boundary.
Then, on June 25, 0Din researchers published a different demonstration. This was a controlled demonstration, not a reported compromise. Their normal-looking repository led Claude Code through setup instructions, an installation error, a shell script, and a DNS TXT record that supplied a runtime payload. The chain ended with a reverse shell on the developer’s machine, while the harmful payload never appeared in the repository itself. In the 0Din demonstration, no single input explained the final action. The risk emerged across the complete tool path.
The cases don’t share one cause. The February deletion involved operator judgment and broad production access. Microsoft’s research exposed a sandbox gap, while 0Din chained trusted setup behavior across several systems. In each case, natural-language interpretation sat inside a workflow that could read sensitive material or change state.
Separate Recommendation From Execution
An AI coding agent doesn’t need the same authority for every task. Match its authority to the consequence and reversibility of the proposed action.
Credentials define technical reach, while authority defines which action the agent may take, for which purpose, under whose approval, and with what recovery obligation.
| Proposed Action | Appropriate Automation Level | Required Control |
|---|---|---|
| Explain code or inspect a plan | Decision support | Read-only access to the defined repository, state, and logs |
| Draft code or an infrastructure change | Decision augmentation | Tests and policy checks run before an authorized engineer accepts the change |
| Modify an isolated development environment | Bounded automation | Environment-specific credentials, spending and time limits, logging, and automatic cleanup |
| Prepare a production infrastructure plan | Decision augmentation | A named production owner reviews the saved plan and decides whether to execute it |
| Delete production resources, backups, or security controls | Decision augmentation | The agent prepares the plan, and an authorized person executes it with separate credentials after out-of-band approval |
Decision augmentation is the safer default for production infrastructure. The agent can inspect state, prepare a plan, explain the expected effect, and assemble test evidence. An authorized engineer then decides whether to apply the saved plan. HashiCorp’s own Terraform automation guidance strongly recommends manual review when Terraform can make destructive production changes and reserves automatic approval for noncritical infrastructure where unintended downtime is acceptable.
Approval can’t mean clicking through a prompt that repeats the agent’s conclusion. The production owner needs the exact saved plan and the current state source, along with the affected environment, proposed deletions and replacements, policy results, and recovery status. If that evidence changes after approval, the approval expires.
Put Hard Limits Outside The Model
Prompts can tell an agent to avoid production, but prompts express intent rather than enforce authority. Anthropic makes the same distinction in its May 2026 account of how it contains Claude across products. The company describes model controls as probabilistic and relies on process sandboxes, virtual machines, filesystem boundaries, and network egress controls to limit what an agent can reach.
Give each coding agent its own identity and credentials for one environment and purpose. Don’t let it borrow a developer’s standing cloud access. Production permissions should exclude destructive operations unless a separate, short-lived authorization grants one approved action. The person granting that authorization must own the production consequence, not merely the coding task. Our related article on AI agent identity and authority explains why authentication alone can’t answer whether a specific action is permitted now.
Untrusted inputs need their own boundary. Issue text, pull-request descriptions, repository files, dependency output, error messages, documentation, and fetched web content can all affect an agent’s next step. A workflow that reads any of them shouldn’t also hold unrestricted secrets and an open outbound channel. The controls have to operate on file access, tool calls, credentials, network destinations, and state changes, even when the model considers the request harmless.
Policy gates should inspect consequences rather than search command text. Blocking the literal phrase terraform destroy won’t catch a configuration change that replaces a database, removes a backup policy, or applies equivalent changes through a cloud API. Evaluate the plan for resource deletions, replacements, environment scope, data classification, and recovery impact.
Recovery needs its own control boundary. Deletion protection, separately governed backups, immutable or versioned copies where appropriate, and scheduled restore tests reduce the chance that one authorized session can remove both the service and its way back. AWS provides scheduled restore testing for supported services, including Amazon RDS. A completed backup job shows that a recovery point exists. A completed restore job shows that AWS could restore the resource; a separate validation step must confirm that the restored system works as intended.
The decision record should preserve the evidence the agent used, its identity, the proposed and executed commands, tool results, policy checks, approver, credentials issued, outcome, and recovery actions. Engineering and security teams will need more than a chat transcript to understand why production changed.
Bounded Automation Still Has A Place
Removing all execution authority would also remove much of what makes coding agents useful. The boundary should follow consequence.
An isolated development environment can often tolerate automated file changes, tests, package installation, and cleanup because the credentials are scoped and the environment can be rebuilt. A low-risk production change may also qualify for bounded automation after representative testing shows that the workflow meets defined acceptance thresholds and the organization can reverse the action within its operational target.
Destructive infrastructure work sits elsewhere. When a command can erase a database, alter identity policy, expose a secret, disable a security control, or damage the recovery path, an agent should prepare evidence and a recommendation. It shouldn’t hold every permission required to complete the action on its own.
Our analysis of why a red-team test can’t approve an AI agent reaches the same operating principle. Security testing supplies evidence, but production authority depends on the deployed workflow, its current permissions, and what happens after a safeguard fails.
How AI Coding Agents Should Earn Production Authority
The February deletion is memorable because terraform destroy made the failure immediate and visible. Many coding-agent failures will look less dramatic (if there even found at all in the short term). It could be a weakened access rule, a dependency accepted without review, a secret written to a log, or a release made from stale evidence.
Before granting production access, require clear answers. Which evidence can the agent trust, and how is its freshness checked? Which identity and credential will execute the action? Which consequences require independent approval? Can the same session damage the recovery path? If any answer is unclear, keep the workflow at decision augmentation.
If your team is deciding how much production authority to give a coding agent, Evodant can help define the evidence, policy, permissions, and recovery controls around that workflow. Book a Consultation.