Zero-trust is not a network configuration — it's an architectural philosophy

When Google published the BeyondCorp research papers between 2014 and 2018, the security community read them as a network architecture paper — move access controls from the perimeter to the device and user, verify every request explicitly. That reading is accurate but incomplete. The deeper point is that zero-trust isn't a configuration applied to a network. It's a design philosophy that has to propagate through every layer of a system. An architecture that deploys BeyondCorp at the presentation layer and then runs agents with broad IAM permissions, stores encryption keys in a shared key ring, and logs to a mutable database hasn't implemented zero-trust. It's implemented zero-trust's marketing brochure while preserving exactly the implicit trust assumptions zero-trust was designed to eliminate.

Zero-trust replaces the perimeter assumption with three operating principles. Never trust, always verify — every request is authenticated and authorised regardless of origin, including requests from inside the system. Least privilege — every principal, human or service account or agent, is granted exactly the permissions its function requires, no more. Assume breach — every component is designed as if its neighbours may be compromised, because at production scale, some of them will be.

What makes these principles architectural rather than procedural is that they're enforced structurally — a property that can't be bypassed without a code change, which requires a review, which creates a record. Across a four-layer GCP architecture, each layer boundary carries its own dedicated enforcement mechanism that operates independently of the application logic above it:

A compromised agent in the orchestration layer cannot exfiltrate data from the intelligence layer — VPC Service Controls block the API call regardless of the agent's permissions. A compromised service cannot rotate its own encryption keys; those live in Cloud KMS with Workload Identity-bound access. The enforcement doesn't depend on the component above it behaving correctly.

The starting point for understanding why this matters is what BeyondCorp replaces. In a traditional network, being on the corporate VPN was treated as a meaningful security signal — pass the authentication boundary once, and subsequent internal requests were trusted without further verification. That assumption has three failure modes that became increasingly consequential as infrastructure moved to the cloud: lateral movement (an attacker inside the perimeter moves between services without re-authenticating, because the internal network is effectively flat), insider threat (a legitimate user can access services they have no business reason to touch, because the control is the network boundary rather than the service itself), and the impossible perimeter problem (in a hybrid or cloud environment, there is no coherent "inside" — data lives in object storage, compute runs on managed services, and the network perimeter that traditional security relied on has no natural location in that topology).

BeyondCorp's response, implemented through Identity-Aware Proxy, moves access control to the application layer, evaluated on every request based on user identity and device posture rather than network segment. The access token is short-lived, not cached, and re-evaluated on each request. The architectural consequence: being inside the VPC confers nothing. Trust is re-established at every boundary crossing, and the question for any architecture claiming zero-trust is not whether it has security features. It's whether those features make the compliance claim true in the absence of human vigilance.

Further reading: Ward, R. et al. (2014–2018). BeyondCorp paper series. Google Technical Infrastructure. · Google Cloud, VPC Service Controls & Workload Identity documentation. · NIST SP 800-207, Zero Trust Architecture (2020).