The Zero Trust Hub

Last time I was in San Francisco, I took a few trips in a Waymo.

At one point, the car stopped.  

Nothing had gone wrong. It wanted to pull over, couldn’t find a gap behind a row of parked cars, and made the choice to stop and lock its doors. Rider support came over the speaker to say a team was working on it.

The car found its gap a few minutes later. Support stayed on the line and told us they would keep monitoring the situation. We’d been cleared, but we were still being watched because the car had behaved oddly.

Most incident response plans in cybersecurity are built the other way round. We put real care into detection, isolation, and eradication, but then simply return to normal operations afterwards.  

That’s where Zero Trust quietly gets suspended. A workload that was just compromised, rebuilt, and released back into production is the least verified asset you own. Yet, the playbook restores its old access on the strength of a clean scan.  

The hours after recovery are when the Zero Trust mantra of “never trust, always verify” should matter most, and they’re usually the hours nobody applies it.

Everybody plans the quarantine, but nobody plans the parole

Ask a security team what happens when a workload trips a detection. You’ll probably get a canned answer: isolate, snapshot, investigate, restore from a clean image, and put it back.

Ask what happens on day two and the answers get soft. There’s rarely a number, an owner, or a defined behavior that would send it back into isolation.

Attackers know this, which is why the hours right after a restoration are some of the safest they get. The investigation is closed, and everyone believes the environment is clean. If a foothold survived the rebuild, that is when lateral movement starts again.

What a rider support agent knows about incident response

Security teams need to take a page out of Waymo’s rider support playbook. I saw them follow a four-step process when something suspicious happened with my car:

• Contain the problem by stopping, locking the doors, and calling in support
• Work out what had caused the stop
• Restore operation once support understood the cause and the fix
• Keep watching for a set period before returning to routine monitoring

Most security teams stop at step three. But that fourth step gives the team a defensible reason to close the incident.  

Zero Trust doesn’t end when the incident does

“Never trust, always verify” is easy to apply to a stranger and hard to apply to a system you spent the weekend rescuing. That workload feels vetted, and it’s just proved it can be taken.

Graduated re-entry is what Waymo does, and it’s what Zero Trust should look like at the back end of an incident.  

Bring the workload back under tighter policy than its peers and keep its segmentation guardrails narrow. Decide in advance what behavior would isolate it again, and relax the limits on a schedule rather than out of relief.  

Trust gets an expiry date and a path to renewal, which is the difference between simply recovering from an incident and building real cyber resilience.

Coming back online isn’t the end of the incident

None of this was urgent when recovery took a few days of manual work. But today, teams are now spinning up dozens of AI agents that talk to each other. Each one can be compromised, contained, restored, and put back in service faster than a change board can meet.  

Recovery is becoming automated, so the decision to trust something again is too, and it will inherit whatever assumption you left in the process.

Write that decision down while it’s still yours to make. An incident response plan that ends at restoration isn’t applying Zero Trust to the asset that needs it most, and it hands an attacker the quietest hours of the whole event.  

Waymo can teach the cyber industry a great lesson. They didn’t stop monitoring the car the moment it recovered and started moving again. And we shouldn’t consider a security incident complete when the workload comes back, either.