Zero trust
An access architecture that stops treating the network as a security boundary. There is no “inside”: every request is authenticated and authorized on its own merits, using device state, identity and context rather than where the packet came from. Google’s 2014 BeyondCorp papers are the canonical statement, written after the company concluded a corporate network perimeter was not something it could defend google-beyond-zero.
This is the spoke’s fourth layer. system-hardening reduces what an attacker can use, the SOC shortens how long they go unnoticed, CVD shortens how long a fix takes to spread — access architecture governs what a credential is worth once someone holds it.
The granularity ratchet
The interesting motion in this idea is where the decision gets made, and it keeps getting finer:
- Network — are you on the corporate LAN or the VPN? (What zero trust replaced.)
- Session — is this user, on this managed device, in this posture, allowed into this application? (BeyondCorp.)
- Action on a resource — may this actor perform this operation on this object, right now, given current context? (Beyond Zero.)
Each step trades evaluation cost for blast-radius reduction. Coarse checks are cheap and let a compromised session do everything that session could do; fine-grained checks cost a decision per call and confine the damage to the calls the attacker can justify.
Why agents force the question
A human with stolen credentials works at human speed and leaves a legible trail. An agent holding the same credentials issues thousands of calls a minute across APIs and tool protocols, and it is supposed to — that’s the product. Two consequences follow. Session-level authorization becomes nearly meaningless, because one approved session now covers an unbounded and unpredictable set of actions. And the authorization decision has to happen at the same speed as the calls, which is why the model arrives bundled with automated investigation and containment rather than as a policy document.
The tool-call layer is the new choke point: Beyond Zero explicitly authorizes at the level of API
and MCP calls, the same protocol surface ../agentic-tooling-wiki
tracks as agent plumbing and ../game-engines-wiki records reaching inside editors. Every one of
those integrations is an access path a defender now has to reason about.
What the request actually carries (added 2026-08-05)
“Every request is authenticated on its own merits” is an architecture statement; something has to be in the request. mTLS is one answer — an X.509 certificate presented at the transport layer, refused before the application sees the connection — and vaultls is what running it looks like below the diagram: a CA on a mounted volume, PKCS#12 bundles handed to users, expiry emails, and a revocation list served to anyone who asks.
Two things follow for the ratchet above. mTLS sits at the coarse end — it decides whether you may connect, not what you may then do, so it sets up the identity a per-action policy engine argues about rather than replacing one. And the credential is long-lived by construction, which inverts the usual worry: a session token’s problem is that it can be stolen, a client certificate’s problem is that taking it back means publishing a CRL and hoping verifiers read it (certificate-lifecycle-management).
The unresolved part
Nothing in this corpus says what fine-grained authorization costs — in latency, in policy authorship, or in the false denials that make people route around it. Zero trust’s own history is instructive: the concept dates to 2014 and the host-hardening baseline didn’t change because of it. Architectures arrive faster than estates adopt them.
Related
google-beyond-zero · mutual-tls · certificate-lifecycle-management · vaultls · defensive-security · system-hardening · security-operations-center · synthesis