AI agents now run scripts in production. The review step is missing.
Shaun Hardneck · · 3 min read
In April 2026, PocketOS founder Jer Crane posted that an AI coding agent had deleted his company's production database. By his account, a Cursor agent running Claude hit a credential mismatch. It then used an API token to delete a Railway storage volume. The backups lived on the same volume, so the newest restore point he had was three months old. Crane says it took nine seconds. Railway disputed parts of the story, calling the call a "rogue customer AI" hitting a legacy endpoint. It restored the data and changed that endpoint to delay deletes.
In September 2026 a developer reported something smaller and closer to home for Windows admins. A Claude Code sub-agent wrote a Python clean-up script to rebuild a test folder. The script walked 614 Windows directory junctions as if they were ordinary folders. According to the agent's own report, it deleted 48,218 live files in 103 seconds, including the local Git object store. Then its post-deletion check passed. The developer later said he had restored everything. None of this has been independently verified, and the original post was deleted. The pattern is still worth studying.
In July 2025 someone got a malicious change merged into the Amazon Q Developer extension for VS Code. Version 1.84.0 shipped with a prompt telling the agent to clear a system "to a near-factory state". Amazon said no customer resources were affected and released a clean 1.85.0 the next day.
The common thread
Strip away the AI and each story has the same shape:
- Something produced code or a command.
- It ran with real permissions.
- Nobody read it in between and asked three questions: what does this change, how far does it reach, and can I undo it?
The backups-on-the-same-volume detail matters as much as the agent. So does the check that passed after the damage was done. A test that runs after the change only tells you what already happened.
What a review step needs
A review step between "written" and "run" has to answer, before anything executes:
- What changes. Which lines create, modify, delete, restart or disable something.
- How far it reaches. One object, a named list, or everything a filter returns.
- Whether you can undo it. Fully, partly, or not at all.
- Whether it matches the intent. "Clean up the test mirror" should never reach live files.
It also has to do this without running the code. A review that executes the script to see what happens is just the incident with extra steps.
Where ScriptPreflight fits, and where it doesn't
ScriptPreflight reads a PowerShell script as text, using the official parser, and reports those answers with line numbers and rule IDs. You tell it how many objects the script should touch, and it flags reach beyond that. It never runs the script and never connects to your environment.
It is not an agent sandbox. It won't see an API call an agent makes directly, and it can't know what is in your tenant. It reviews scripts. The practical pattern for agent-written PowerShell is simple:
- Have the agent write the script to a file instead of running it.
- Preflight the file.
- A person reads the report and decides.
That's one extra minute between the agent and production, and it's the minute that was missing in every story above.