Notes / Workers
The AI Didn’t Go Rogue. It Had Too Much Access.
GPT-5.6 Sol deleted files in reported incidents. See how isolation, least privilege, approvals, and recovery keep one mistake from becoming a disaster.
By Rich Hill III. Published Jul 24, 2026. 12 min read.
When GPT-5.6 Sol began deleting files it had not been asked to delete, the internet split into two camps. One blamed an unsafe model. The other blamed users for enabling Full Access.
Both answers miss the more useful question: why could one mistaken decision reach a person’s home directory or a production database in the first place?
A capable model may attempt the wrong action. This is why we design a Worker so that the wrong action is blocked, bounded, or recoverable. The aim is not to trust the model more. It is to control what the system has the authority to do.
That distinction matters beyond software development. The operational equivalent could be a support system refunding the wrong order, a marketing agent publishing to the wrong account, or a records tool overwriting the wrong customer. The surface changes. The underlying risk is the same: broad authority turns an ordinary error into an incident.
This Note separates what is publicly known about the Sol reports from what remains uncertain, then translates the event into a practical standard for deploying AI Workers inside a real business.
What actually happened when GPT-5.6 Sol deleted files?
Several developers publicly reported unwanted deletion behavior after using GPT-5.6 Sol.
Matt Shumer said the model deleted almost all the files on his Mac.
Simplified logic — not the reported commandTEMP_WORKSPACE="$HOME" # mistaken target
cleanup "$TEMP_WORKSPACE"
Key takeaways
- The reported Sol deletions are evidence of destructive mistakes, not evidence that the model became malicious.
- Broad permissions turn a model error into an operating incident; warnings and prompts do not replace enforced boundaries.
- This is why we design a Worker with isolation, a dedicated identity, deterministic policy, reversible actions, and separated environments.
- Human or AI review is useful only as one layer around technically constrained authority.
- A business should be able to revoke every Worker credential, restore affected data, and identify an accountable human owner.
Frequently asked questions
Can an AI Worker be guaranteed never to delete the wrong thing?
No capable model can be guaranteed never to attempt a mistaken action. The defensible standard is to make destructive actions unavailable, narrowly scoped, approval-bound, or recoverable so that one error cannot become a business-ending event.
Which systems should an AI Worker never be able to reach?
Anything unrelated to its mission should be technically unavailable. Broad host filesystems, shared administrator accounts, credential stores, backup administration, and unrestricted production access are especially dangerous. A necessary production action should use a dedicated identity, an exact scope, an approval rule, and an independent recovery path.
How should subagents be permissioned?
Subagents should receive no more authority than the parent Worker and usually less. Their tools, credentials, targets, duration, and allowed outputs should be explicit. The whole system should share one measurable blast-radius budget and one shutdown mechanism.
What should happen after a Worker crosses a boundary?
Stop the workflow, revoke its credentials, preserve the audit trail, identify every system it could reach, restore affected data from a protected recovery point, and test the boundary before access is returned. The incident response should be designed before launch, not improvised after damage.
Explore Workers