Leadership1 publisher3 min readPublished
Beyond Zero: Google names the agent era's default security model before anyone else can
Google's new model extends zero trust into the authorization layer, and it arrives the way BeyondCorp did: paper first, implementation data later. The vocabulary reaches auditors before the numbers do.
The Board Room · Leadership desk
What happened
- Google published Beyond Zero, a model that extends zero trust into the authorization layer so every action inside an enterprise, by a human or an agent, is authorized.
- Its first principle authorizes individual actions on specific resources instead of whole applications, across front ends, APIs and the Model Context Protocol.
- Google says industry-wide continuous authorization is early, with peer organizations and industry bodies only starting on comparable frameworks.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- precedent A named model with a promised paper series on the BeyondCorp cadence gives auditors and directors a phrase to ask questions in before most firms have written an agent authorization policy.
- exposure Any agent running on an application-scope credential is now measured against a published alternative, which turns a design shortcut into something a leader has to explain.
- constraint With evidence confined to Alphabet and no numbers attached, anyone adopting the vocabulary early is committing to a posture they cannot yet benchmark against a peer.
The durable output of BeyondCorp was not an architecture most companies copied. It was a phrase that fit in a board minute and a question an auditor could ask without understanding the plumbing. Google's own telling puts roughly a decade between the 2014 whitepaper and zero trust's status as the industry standard for good enterprise security [1][2][4]. Beyond Zero is built to travel the same way: a named model, a numbered list of five principles, and a first paper in ACM Queue that can be cited in a policy document by people who will never read it [3][11].
The load-bearing detail sits in the first principle. Authorization is evaluated per action on a specific resource rather than as broad access to an application or tool, and Google says that applies uniformly across front-end interfaces, APIs and the Model Context Protocol [5]. Naming MCP alongside the other two puts agent protocol traffic on the same footing as a human logging into a web app. It also names the thing most current agent deployments actually have: a service credential with application-scope reach, which is now the posture you have to defend rather than the posture you assumed was fine.
Worth counting what the five principles ask for. Four of them (per-action authorization, automatically enriched context, autonomous investigation, and on-demand challenges or containment) describe runtime infrastructure that has to observe and adjudicate every action as it happens [5][7][8][9][1]. One, the blend of granular static policy with dynamic controls for high-risk scenarios, describes something you can write down and inspect [6][1]. That ratio is the budget story. The written policy is cheap; the decision infrastructure that must always have context available is a platform programme, and it lands on whoever owns the call paths rather than on the security line item.
Google's hedge in that second principle is the most useful sentence in the post for anyone who has to certify a control: a fully dynamic model can be difficult to verify statically [6]. That is an admission that machine-speed authorization and auditability pull against each other, and it preserves a static artifact for the auditor to point at.
The evidence is thinner than the framing. What Google offers is early internal prototypes and deployments reported as improved access abuse detection and intellectual property protection, with no baseline and no figure attached [10][2], plus an architecture developed within Alphabet [11]. Nothing external is cited; Google says industry-wide adoption of continuous authorization is early and that peers and industry bodies are only beginning comparable frameworks [13][3]. That gap is precisely why the naming matters. When several comparable frameworks arrive, the one already published in a citable venue, with a promised series behind it on the BeyondCorp cadence, sets the terms the others get compared against [12][13].
So the practical question for leadership is not whether Beyond Zero is correct. It is whether you can answer, in these words, what any given agent in your estate is authorized to do at the level of a single action on a single resource [4].
What to watch
- Whether the promised follow-up papers carry deployment figures rather than adjectives about improvement.
- Which industry body publishes a rival continuous-authorization framework, and whether it reuses Beyond Zero's terms or competes with them.
- Whether MCP server implementations expose per-action authorization hooks, which is what makes principle one buildable outside Google.