I have not used a corporate VPN in more than ten years.
At Google, access to internal applications depends on the user and the device, not on the network. This has been the case since the BeyondCorp transition. There is no client to start and no token to type. The only time I notice the system at all is when I postpone an OS update for too long. Access then degrades quietly until I install it. That is the whole model in a single experience: trust is a property of your device and your identity, not of the network you sit in.
Yesterday Google announced the successor: Beyond Zero. I want to write down my read of it now, at the start. In 2014 almost nobody took the first paper seriously in time, including most of the security industry.
The 2014 paper
The original paper by Rory Ward and Betsy Beyer appeared in USENIX ;login: in December 2014. The PDF is still online and takes maybe twenty minutes to read. The claim: the internal network is as dangerous as the public internet, so the perimeter cannot be a boundary of trust. Google removed the privileged network entirely. All applications went behind an internet-facing proxy, in public DNS, and every request was authorized individually based on user, group, device certificate and a trust tier that changes with the state of the device.
The part most people skip is the migration, and it is the better half of the paper. Google collected netflow data from every switch, ran a simulator of the new network on every employee laptop, and moved a person only after thirty consecutive days with more than 99.9 percent compatible traffic. Nothing broke. Most of the stalled zero trust programs I have seen since skipped exactly this step.
Five more papers followed, on the proxy, the migration tooling, the user experience and the fleet. NIST standardized the model in 2020 as SP 800-207, the US government mandated it for federal agencies in 2021, and at some point every RFP had a zero trust section. I have also sat in presentations where zero trust meant, as far as I could tell, a firewall with better marketing. That is what winning looks like for an idea in enterprise IT.
Why a sequel
There is a question I now hear in almost every enterprise AI conversation: what exactly is our agent allowed to do? The honest answer in most organizations is: whatever the service account of whoever built the pilot can do. Nobody decided that. It accumulated.
Zero trust does not help here. It verifies the user and the device per request, and after that the session can do whatever the application permits. For humans that was acceptable, because humans are slow. A stolen credential in 2015 was dangerous at typing speed. A stolen credential in 2026 is dangerous at software speed, and the same is true for a legitimate agent that misreads its task.
Beyond Zero moves the decision one level down. Not “may this identity access the finance system” but “may this identity perform this specific action on this specific record, in this context.” Reading one record and exporting fifty thousand records become different authorization questions. The first technical paper is in ACM Queue, and the announcement promises follow-up papers with implementation detail, same as the original series. Deployments are internal so far. We are at the 2014 point of the curve, not the 2020 one.
AI in three roles
What makes this architecture different from everything before it: AI shows up in all three roles.
As the actor. Part of the workforce is now software. Agents hold credentials, call APIs and use the same tools employees use. An identity system that assumes a human behind every credential is wrong about a growing share of its own traffic.
As the attacker, for the speed reasons above.
And as the defender. The announcement describes risk signals that autonomously trigger investigations, and policies that fire challenges or containment directly. In practice this means the tier-one SOC analyst becomes an agent. There is no alternative at this speed. A human does not review an alert in the four seconds it takes a compromised credential to touch ten thousand records. Google’s DeepMind agent security work makes the same argument from the agent side.
The design decision I care most about: the policy core stays static. Beyond Zero is explicitly not a model where an AI judges every access in real time. Rules are granular, written down and verifiable, and dynamic controls only escalate on top of them. Google has run authorization this way at scale for a long time. Zanzibar, the system behind Drive and Calendar permissions, answers millions of checks per second from stored relationships. BeyondProd did the same for service-to-service traffic years ago.
For European deployments the static core is the decisive property. A works council or a BaFin auditor will ask how an access decision was made. “The model decided” is not an answer you can give. A written policy plus a documented escalation path is. This is also what NIS2 and DORA effectively require, and once the defender itself is an AI system, the EU AI Act will want documentation for that model too. Whoever designed this had regulated customers in mind.
Open problems
Some of this will be hard, and the announcement does not pretend otherwise. Per-action policy across thousands of applications is a governance problem before it is a technology problem; someone has to write and review these rules, and the follow-up papers owe us an answer on tooling. Context-enriched authorization has to complete in a few milliseconds or people will route around it. Automated containment will eventually freeze a legitimate agent in the middle of a quarter close, and that incident review will be interesting. And a system that enriches decisions with what an employee “should be working on” needs the data protection officer in the room from the first day of the pilot, at least in Germany.
Timing
BeyondCorp took about eight years from a magazine article to an RFP checkbox. Most enterprises have not finished implementing it and the successor is already published. I expect the adoption to run faster this time, because every serious agent deployment hits the authorization question within weeks. The architecture decisions for this are being made in 2026 and 2027, not later.
If you want a practical starting point: read the ACM Queue paper, then check what permissions your current agent pilots actually run with. In my experience the second exercise is the more sobering one.
The original BeyondCorp paper, the full series and the Beyond Zero paper are worth the time. Opinions are my own.