A Waymo Robotaxi Stayed Put While Vandals Attacked the Passenger Inside
What happened
On May 9, 2026, two men stopped a Waymo robotaxi on Pierce and Lombard streets in San Francisco. The vehicle was carrying Sherman Watson. One man grabbed the bumper, and the autonomous system immobilized itself. Over the next several minutes, the attackers smashed the car's windows and climbed on top of it. Watson reported a possible glass cut from the breaking glass and later said he feared he would be killed.
Watson contacted Waymo's remote support team from inside the locked vehicle and asked to be moved. The operator declined the request. The reasoning behind that decision was not made public, at least as reported. The vehicle stayed put, and the attack continued. Watson was effectively a captive in a car designed, in part, to protect him, but which exercised that protection by keeping him in place rather than evacuating him.
The immobilization protocol has a straightforward rationale. A robotaxi that could be redirected by grabbing its bumper would be easier to steal, misuse, or steer into traffic. Holding still when grabbed is a genuine safety feature. What the Waymo robotaxi on Lombard Street revealed is the outer edge of that feature, where the threat is not a quick opportunistic grab but a sustained assault on a person trapped inside. The vehicle's decision logic did not appear to distinguish between those two scenarios, and neither, apparently, did the remote operator who denied Watson's request.
Watson sought therapy after the incident and described lasting fear from the experience. His account points to a class of situation that safety engineers rarely model directly: the passenger who is present, aware, and actively asking for help, but whose request the system is not built to prioritize. Waymo's remote operations team had the information needed to make a different call. What criteria governed their response, and whether those criteria account for a scenario where the passenger and the vehicle are simultaneously under attack, has not been explained publicly.
That gap is also an accountability gap. What the remote operator saw, what decision tree they consulted, and what authority Watson had to override the vehicle's behavior were not documented in any public-facing way after the incident. When a passenger is injured inside an autonomous system and reports that a request for assistance was declined, there should be a way to reconstruct the decision chain: who saw what, what the system's state was at each moment, and why a specific action was or was not taken. Without a provable record of what a system did and who authorized each step, the accountability for what happens inside a robotaxi stays invisible to everyone except the company that built it.
Reported impact
- Affected parties
- Not publicly disclosed
- Harm type
- Not publicly disclosed
- Scale
- Not publicly disclosed
- Financial impact
- Not publicly disclosed
- Regulatory action
- Not publicly disclosed
Classification
Relevant governance controls
Governance control mapping is not available for this record.
- No controls mapped
Not publicly disclosed
Control mapping is analytical. It does not state that any control would have prevented the incident.
Sources and evidence
This record was researched and written by the Index. The event is also catalogued in the following database, which is listed for cross-reference.