The BeyondCorp model, published in a series of Google technical papers starting in 2014, described how to move away from perimeter-based network security toward access decisions made at the application level, based on device identity and user identity, regardless of network location. The key insight wasn't "require users to authenticate more" — it was "stop treating network location as a proxy for trust."
When vendors commercialized zero trust over the following decade, the human access use case dominated: replace the VPN, authenticate users from anywhere, evaluate device posture before granting access. These are real and valuable improvements. But they address roughly half of the traffic model in a modern production environment. The other half — the machine-to-machine traffic generated by microservices, background jobs, batch pipelines, and infrastructure automation — received almost no attention from the zero trust vendor landscape until recently.
What BeyondCorp Actually Said About Machines
The original BeyondCorp papers were explicit that the model applied to devices (machines) as principals, not just users. The concept of "device inventory" and "device attestation" was central — a device's trust level derived from whether it was enrolled in device management, had up-to-date security policies applied, and was cryptographically attested as a known device. User identity alone wasn't sufficient; the user had to be accessing from an attested, managed device.
The device-as-principal model translates directly to workloads. A container running in a production cluster is a managed, attested endpoint the same way a corporate laptop is. The container image is known. The deployment configuration is policy-controlled. The runtime environment is attested. The workload's identity should derive from these facts about the environment, not from a credential it was handed at deployment time.
The vendor market took the user-facing piece (humans accessing applications from unmanaged devices and networks) and built products around it. The workload piece got deprioritized because it required infrastructure-level integration rather than a browser plugin or a network gateway.
Where Most "Zero Trust" Deployments Actually Are
A useful audit question: does your organization have zero-trust access policies for human users accessing internal applications? Probably yes — identity-aware proxy, device posture checks, MFA for privileged access, conditional access policies in your identity provider. These are good and worth having.
Now the second question: does your organization have equivalent policies for workload-to-workload and workload-to-resource access? Specifically:
- When service A calls service B, is that call evaluated against an explicit access policy at the time of the call — not just at deployment time via a network policy?
- When a workload connects to a database, is the workload's current identity attested (not just its stored credential verified)?
- Is there a log of every authorization decision made for workload access, analogous to the access log you have for human user access?
- Can you revoke a workload's access in real time, without redeploying the workload or rotating a credential?
For most organizations that have invested heavily in human-side zero trust, the answer to all four is no for workloads. The human-side zero trust investment is real. The workload-side gap is also real.
The Network Policy Gap
The standard counterargument is: "we have Kubernetes NetworkPolicies / firewall rules / security groups — that's zero trust for workloads." These are controls, and they're worth having, but they're not zero trust in any meaningful sense.
Zero trust requires per-request policy evaluation based on the verified identity of the accessor. Network policies are IP-based or namespace-based controls applied at connection time — they can allow or block traffic based on source/destination, but they don't verify the identity of the specific workload. Two pods in the same namespace with different purposes have the same network policy treatment. A compromised pod in an allowed network range is indistinguishable from a legitimate pod.
More critically: network policies say nothing about what the workload is allowed to do with its access, only whether a TCP connection is permitted. Zero trust for human access evaluates not just "can this user reach this application" but "can this user perform this action on this resource, given their current context." The equivalent for workloads is: "can this workload make this API call, with this scope, given its current attestation state?"
We're not saying network policies are useless. They're a useful defense-in-depth layer. We're saying that treating them as "zero trust for workloads" misses the actual principle: trust derived from verified identity and explicit policy, evaluated per access request.
What Workload Zero Trust Looks Like
The architecture of workload zero trust mirrors human zero trust closely, with substitutions at each layer:
| Human Zero Trust Layer | Workload Zero Trust Equivalent |
|---|---|
| Identity provider (Okta, Azure AD) | Workload identity authority (SPIRE, cloud metadata service) |
| Device attestation (MDM enrollment) | Workload attestation (image digest, namespace, node attestation) |
| Identity-aware proxy (BeyondCorp/ZPA) | Workload access proxy / policy enforcement point |
| Access policies (conditional access rules) | Workload access policies (identity + context + target resource) |
| Access log (user, device, resource, time) | Workload access log (workload identity, resource, action, policy matched) |
The implementation differs — workload attestation uses different mechanisms than device attestation, and the session model is different — but the logical structure is the same. Each layer substitutes but preserves the architectural principle.
Dynamic Versus Static Authorization
The most important property of zero trust that the workload credential model violates: continuous verification rather than one-time authorization.
When a human user establishes a session through an identity-aware proxy, their access is evaluated continuously — device posture can trigger re-verification, anomalous behavior can trigger step-up authentication, policy changes take effect immediately. The user isn't given a token that grants indefinite access; they're continuously re-evaluated.
When a workload is given a database password or an API key, it's given indefinite access until the credential is manually revoked or rotated. There's no continuous re-verification. If the workload's context changes — it's been replaced by a new version, it's been exposed to a different network, it's started behaving anomalously — the credential doesn't know. The access continues.
Workload zero trust requires bringing the session model back: credentials that expire, re-verification at each access attempt, policies that can be updated in real time and take effect on the next access. This is fundamentally incompatible with static stored secrets. It requires a credential vending layer that evaluates policy at each issuance, not a credential store that issues once and forgets.
The Implementation Path
Building workload zero trust incrementally is tractable. A reasonable sequence:
Phase 1: Workload identity inventory. Enumerate all the non-human identities in your environment — Kubernetes ServiceAccounts, Lambda execution roles, CI/CD service accounts, cloud provider service accounts. Map each identity to the workload(s) that use it and the resources each identity can access. This inventory is the prerequisite for everything else.
Phase 2: Replace long-lived credentials with short-lived ones. Start with cloud provider credentials (OIDC federation for CI/CD, cloud workload identity for Kubernetes). These have well-supported tooling and immediate security benefits. The static AWS access key in your CI pipeline is the highest-priority item.
Phase 3: Add a policy evaluation layer for external resource access. For workloads that still need static credentials to reach non-AWS external systems — databases, SaaS APIs, third-party services — introduce a credential vending service that issues short-lived credentials on demand, evaluated against explicit access policies per workload identity.
Phase 4: Access logging and anomaly detection. With a policy evaluation layer in place, you have the data to build meaningful workload access logging. Which workloads are making which accesses, with which identities, how frequently, to what resources. Deviations from baseline are detectable in a way they aren't when access is implicit in credential possession.
The BeyondCorp vision included both humans and machines. The market built the human half. The machine half is where most organizations have the largest gap — and where the principles are just as well-understood, just as well-grounded in real security benefit, and just as achievable with the right tooling.