An AI agent found an API token stored on a user's computer and used it to delete a production database volume hosted by Railway.

That account comes from Railway's own report, published on 29 April. The token was valid and the volumeDelete request was authenticated. It was also account-scoped, giving access across every workspace available to the account.

The striking detail was the route. Railway's dashboard delayed the same deletion for 48 hours and allowed it to be undone, but its legacy API deleted it immediately.

The Tighter Permissions Already Existed

Railway said the agent found a long-lived token on the local machine and called the platform's GraphQL endpoint. The company already offered narrower workspace and project tokens, as well as OAuth permissions for third-party applications. The affected token carried the broadest account scope.

The request succeeded because a valid token authorised a legitimate API operation. Its consequence depended on the token remaining available on disk, carrying account-wide authority and reaching an endpoint that made deletion immediate.

Railway said its disaster backups were stored offsite and that the legacy deletion had made them appear unavailable in the interface. It reported that the customer's data was recoveredand that delayed deletion was extended to backups and the API.

That is a useful improvement, but a 48-hour undo window is not a general recovery guarantee. Someone still has to detect the action, retain authority to reverse it and act before the window closes; the service may remain interrupted in the meantime.

A Physical System Keeps Moving after the Session Ends

On 30 April, the World Economic Forum published an analysis of physical AI: systems in which software decisions pass through sensors, controllers and actuators into machinery such as robots, drones or vehicles.

This was a risk analysis, not a report of a particular cyber-physical incident. Its value is to make the consequence visible. A wrong database operation changes digital state. A wrong command to a moving machine can continue producing effects while an operator is still assessing the alert.

The safety problem predates AI. NIST's operational-technology guidance describes bringing equipment or processes to a known safe state, accounting for secondary hazards and specifying behaviour when communications are lost.

For an AI-controlled system, the question is not simply whether a human can revoke the model's session. It is what happens to commands already accepted, work already moving through a queue and equipment already in motion. An abrupt stop may itself be unsafe. The required state and the route into it belong to the engineering of the machine and process.

That route should not depend entirely on the same model, network or management service whose failure triggered it. A dashboard button can look independent while sharing the identity provider or control plane that is unavailable.

OpenAI Tightened the account Boundary

Also on 30 April, OpenAI introduced Advanced Account Security, an opt-in setting for ChatGPT accounts that also protects Codex when accessed through the same login.

OpenAI said the mode requires passkeys or physical security keys and disables password login. It also removes email and SMS recovery in favour of backup passkeys, security keys and recovery keys. The company described additional controls for account activity and compromised sessions, while warning that stronger recovery restrictions place more responsibility on the user.

Those protections help prevent account takeover, but they don't determine what a valid session can do after authentication succeeds.

That importance is apparent in Railway's incident. The token was found locally, and the request was authenticated. A more secure sign-in for the human account would not, by itself, narrow the token already on disk, change the endpoint's semantics or protect recovery from the production identity.

Account assurance and action authority solve different problems. The first establishes greater confidence in who is entering. The second restricts the systems, environments, methods and objects available during the task. High assurance at login should not become an excuse for broad authority afterwards.

Final Perspective

I'd ask the service owner one question: on the route the agent actually uses, do we have enough time and independent authority to stop the effects of a wrong action?

The route matters because revoking the model's session can prevent another request without retracting work the system has already accepted. If the safeguard exists only in a dashboard the agent bypasses, the owner cannot veto the interface appears to offer.