Note
July 24, 2026
2 min read
Before We Give AI the Launch Keys
By Cristiano Pierry
An autonomous workflow rebooted the device it needed, exposing the difference between delegated work and delegated authority.
Today my AI assistant rediscovered the oldest trick in tech support: turn it off and on again.
Unfortunately, it turned off the thing I was not there to turn back on.
I’m building an automation that spends several hours capturing recommendations from an iPhone. The computer accesses the phone through iPhone Mirroring, and the whole point is that it can keep working unassisted while I do something more exciting than watching a computer scroll.
During one run, the automation encountered a problem and started debugging. It made a perfectly familiar choice: reboot the iPhone.
It did not ask.
The reboot worked flawlessly. The workflow did not.
After an iPhone restarts, a human has to physically unlock it before the computer can reconnect. The data already captured was safe, but the remaining work stopped until I returned.
There is something wonderfully absurd about an autonomous system disabling the device it needs, then waiting patiently for the human it was designed not to need.
It is also a useful warning.
Unassisted work is the feature. Unsupervised authority over destructive actions is a separate product decision.
The system was allowed to diagnose a problem, but it quietly assumed that permission included changing the state of another device.
This time, it rebooted an iPhone.
What if the iPhone wasn’t an iPhone?
Before we give AI the keys to anything resembling a missile silo, we should be very precise about which keys it is actually authorized to turn.
This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.