Zero Trust Networking: How to Enforce It at the Cloud Workload Layer

The phrase "never trust, always verify" is commonly associated with Zero Trust, but the operative word in a networking context is enforce. Verification without enforcement is a posture recommendation. Zero Trust networking means the network itself, not a dashboard or an alert, blocks the connection if it hasn't been explicitly authorized.

That distinction matters more than it appears. A posture tool that scans cloud configurations and flags misconfigured security groups is performing verification. It is not enforcing Zero Trust at the network layer. Enforcement means the connection is blocked before it completes, regardless of what the workload's code attempts to do.

The modern formal framing of this is containment: the architectural enforcement of explicit communication policy at every workload, governing what it can reach and what can reach it, at the granularity of workload identity and protocol on every path available to it, independent of whether a compromise has been detected.

That definition is precise on purpose. "Every path" means enforcement is path-complete, it cannot be bypassed by traffic that sidesteps the inspection point. "Independent of detection" means enforcement is pre-breach, not reactive. "Workload identity and protocol" means the policy is more granular than a subnet rule, it knows which service made the request, not just which IP range it came from.

The castle-and-moat model assumed that anything inside the corporate network was trustworthy. Employees connected from office buildings, on managed devices, through firewalls that separated "trusted inside" from "untrusted outside." The model had structural logic in a world where work happened in a single location.

Three forces dismantled that logic simultaneously.

Cloud migration dissolved the interior. When workloads moved to AWS, Azure, and GCP, the "inside" became a distributed fabric across multiple provider networks, regions, and availability zones. The concept of a single corporate perimeter didn't survive the first cloud VPC.

Lateral movement became the dominant breach pattern. Attackers stopped trying to blast through perimeters. They found credentials, entered through legitimate channels, and moved laterally through flat east-west networks that perimeter tools never inspected. The breach anatomy became: valid credentials in → lateral movement across trusted interior → exfiltration or ransomware. The perimeter stopped none of it.

Hybrid work permanently extended the attack surface. Remote workers, contractors, and third-party integrations all require connectivity to sensitive systems. Extending the perimeter to cover every connection point extends the attack surface with it. What looks like a larger perimeter is actually a larger exposure.

The architectural response is Zero Trust networking: eliminate implicit trust from the network itself. Every connection, not just the ones entering from outside is verified, least-privileged, and enforced.

Zero Trust Network Access (ZTNA) is commonly used as a synonym for Zero Trust networking. It isn't. They address different problems, and confusing them leaves a significant enforcement gap open.

ZTNA solves the user access problem. When an employee or contractor needs to reach a corporate application from outside the office, ZTNA replaces the VPN with identity-verified, application-specific access. The user gets a connection to the specific application they're authorized for, not a ticket onto the entire corporate network. ZTNA operates at the user-to-application layer.

Zero Trust networking solves the workload-to-workload problem. Inside your cloud environment, your microservices, containers, databases, and AI agents communicate constantly with each other. None of those connections go through a ZTNA proxy. They move east-west, inside the cloud fabric, completely outside the scope of user-centric access tools.

The gap is structural, not a configuration failure. ZTNA tools were designed for a specific use case remote access and they deliver it well. But when 82% of breaches move through valid credentials inside the environment, the access problem is not at the edge. It's inside the network, between workloads that have never been verified against each other.

Zero Trust networking at the workload layer is what fills that gap. Every connection between a container and a database, every call an AI agent makes to an external API, every east-west hop a microservice takes all of it governed by the same principle: verify, least-privilege, enforce.

Most Zero Trust networking frameworks were designed before cloud-native infrastructure became the default. Three characteristics of modern cloud environments break the assumptions those frameworks relied on.

IP Addresses Are Ephemeral

Traditional network policy operates on IP addresses: allow traffic from 10.0.0.5 to 10.0.1.20 on port 443. In a Kubernetes cluster, a pod gets a new IP every time it reschedules. A serverless function has no persistent address at all. When you scale a service horizontally, you replace one IP with a dozen.

Any Zero Trust networking architecture that ties policy to IP addresses is broken by design in modern cloud environments. The policy doesn't stay accurate because the infrastructure it describes is constantly changing.

Agents Don't Work on Ephemeral Workloads

Some Zero Trust networking approaches deploy agents on each workload software that enforces policy at the endpoint. For long-lived virtual machines, agents are manageable. For a Kubernetes pod that lives for 30 seconds, an agent cannot be installed, maintained, or removed before the workload is already gone. For a serverless function that handles a single request, there's no persistent process to attach an agent to.

The result is a Zero Trust networking architecture with coverage gaps: the workloads your agents can reach are governed; the rest serverless, managed services, containers at high scale, AI agents instantiated dynamically are completely uncovered.

The Explosion of AI and Agentic Workloads

AI agents introduce a new workload type that Zero Trust networking frameworks weren't built to handle. An AI agent makes dynamic, context-driven decisions about what APIs to call, what data sources to query, and what external services to contact. Those decisions happen at runtime, without human review of each individual call.

A compromised or misconfigured AI agent with broad network permissions is one of the highest-risk workload types in a cloud environment. It can exfiltrate data, call attacker-controlled endpoints, or escalate privileges across connected services and every connection looks legitimate because the agent itself is legitimate.

Zero Trust networking for AI workloads requires the same identity-verified, least-privilege enforcement applied to every other workload type: explicit policy for which services the agent can reach, enforced at the network layer independent of what the agent's code attempts to do.

Zero Trust networking is a claim many architectures make. Evaluating whether a given architecture actually delivers it requires asking testable questions. Any architecture claiming to enforce Zero Trust at the network layer must demonstrate all five of the following properties.

1. Path-complete. Enforcement governs every communication path available to a workload including paths that bypass centralized inspection points. An architecture that inspects traffic routed through an appliance but misses intra-VPC traffic, pod-to-pod communication, or serverless-to-managed-service calls does not deliver path-complete enforcement.

2. Identity-aware at L7. Policy operates at the granularity of workload identity and application protocol, not IP addresses and ports. "This Kubernetes pod is permitted to call this database API" is identity-aware. "Traffic from 10.0.0.5 to 10.0.1.20 is permitted" is not, it breaks the moment the pod reschedules.

3. Detection-independent. Enforcement holds before, during, and after a breach, without requiring that the breach first be detected. 82% of 2026 intrusions use valid credentials through legitimate channels. When the attacker presents a valid credential, detection produces no signal. Only enforcement that was in place before the credential was stolen can limit what the attacker can reach.

4. Compute-model agnostic. Enforcement reaches every workload type, virtual machines, containers, serverless functions, managed services, partner virtual private clouds without requiring an agent installed on each. Any architecture that requires an agent inherits a coverage gap wherever an agent cannot run.

5. Universally propagated. A single policy change enforces across providers, regions, and clusters within subseconds. An architecture that requires touching multiple appliance configurations to update policy across a multicloud environment is not universally propagated, it is fragmented.

Use these five properties as an evaluation framework. Ask every vendor in your environment to demonstrate each one. Document what they cannot deliver. That gap is where your Zero Trust networking program is incomplete.

Three categories of architecture make claims on Zero Trust networking. Each fails on a different subset of the five properties.

Centralized network firewall vendors - including Palo Alto Networks, Check Point, Fortinet, and Cisco, offer cloud deployments of their appliance-based inspection platforms. These architectures enforce policy on traffic that is steered through the appliance. Traffic that doesn't route through the appliance, intra-VPC traffic, pod-to-pod communication, serverless function calls to managed services is ungoverned. The architecture fails path-complete enforcement, compute-model agnosticism, and universal propagation. Policy lives on the appliance, not at the workload.

Posture and vulnerability management platforms - including the CNAPP category broadly, deliver excellent visibility into cloud misconfigurations, vulnerability exposure, and risk scoring. They do not deliver enforcement. A CNAPP tool cannot block a connection. It can flag a misconfigured security group on the next scan. By the time the scan runs, any connection exploiting that misconfiguration has already completed. Posture without enforcement fails all five testable properties of a containment architecture from an enforcement standpoint.

Agent-based microsegmentation vendors - including Illumio and Guardicore, enforce policy on workloads where an agent can be installed. For long-lived virtual machines, this works well. The model breaks for containerized workloads at scale, for serverless functions, and for managed services that don't support third-party agents. The coverage gap isn't a configuration problem. It's built into the architecture: agent-dependent enforcement is compute-model limited by definition.

The evaluation framework is neutral. It doesn't ask which vendor has better marketing. It asks which architectural properties each approach can demonstrate. The vendor who can demonstrate all five is delivering Zero Trust networking. The others are delivering a subset of it.

Zero Trust networking is an enforcement posture you build progressively. The following framework reflects how organizations with mature cloud environments approach it, starting with visibility, moving to least-privilege policy, and expanding coverage one controlled step at a time.

Step 1: Inventory Workloads and Map Communication Paths

You cannot enforce Zero Trust networking on workloads you don't know exist. Start by cataloguing every workload in your environment: Kubernetes namespaces and deployments, serverless functions, virtual machines, AI agents, and third-party services. For each, map the actual traffic: what talks to what, which services call which APIs, where data flows between workloads and data stores.

Cloud flow logs, network observability tooling, and the Aviatrix Workload Attack Path Assessment all give you this visibility. The goal is a communication map that reflects what is actually happening in your environment, not what you think your architecture diagrams describe.

Step 2: Assign Workload Identity

Once you know what workloads exist, assign each a stable identity that survives the infrastructure changes that invalidate IP-based policy. In Kubernetes environments, this is pod labels and namespace metadata. In cloud accounts, it is resource tags, Lambda ARNs, and service account identifiers.

Workload identity is the foundation on which all policy is written. "The payment-service workload is permitted to call the fraud-detection service on port 443" is a policy that survives a deployment rollout, a pod reschedule, and a horizontal scaling event. "Traffic from 10.0.0.5 to 10.0.1.20" breaks the moment the infrastructure moves.

Step 3: Define Least-Privilege Workload Policy

With your communication map and workload identity model in place, define the minimum set of connections each workload legitimately needs. Start with default-deny: every workload is denied all connections unless explicitly permitted. Then layer in allow rules for each legitimate path.

Prioritize the highest-risk paths first: workload-to-database, service-to-secrets-manager, AI agent egress to external APIs, and CI/CD pipeline access to production infrastructure. These are the paths most commonly exploited when a workload is compromised.

Policy should be scoped to specific protocols and ports, not "allow all traffic between workload A and workload B." Broad allow rules recreate the flat network trust model Zero Trust networking is designed to replace.

Step 4: Enforce Inline, Without Agents

Policy enforcement needs to happen inline, intercepting each connection as it is made, before it completes, not after. This is the point at which agent-based approaches fail for modern cloud architectures and where an agentless, network-layer enforcement model is essential.

Enforcement at the network fabric level operates between workloads, not inside them. The enforcement mechanism doesn't require installation on each workload, has no compatibility dependency on container runtimes or function execution environments, and survives the lifecycle of even the most ephemeral workloads.

Step 5: Monitor, Adapt, and Continuously Verify

Zero Trust networking is not a one-time configuration. Workloads change. New services are deployed. Traffic patterns evolve. Policy needs to keep pace.

Every workload connection accepted and denied, should be logged with workload identity, timestamp, destination, protocol, and the policy decision applied. Deviations from baseline traffic patterns, a workload calling a service it has never reached, a data store receiving unusual query volumes are observable signals that warrant investigation.

Continuous verification means the policy is active and enforced at all times, not at the moment of configuration. The enforcement holds whether or not an active breach has been detected.

These three terms are frequently used interchangeably. They describe meaningfully different approaches.

Network segmentation divides a network into broad zones, DMZ, production, development and controls traffic between them with firewall rules at the zone boundary. It reduces the Blast Radius of a breach from "the entire network" to "the compromised zone." Zones are coarse; a compromised workload in the production zone can still reach every other workload in that zone.

Microsegmentation applies granular policy at the workload level, typically enforcing rules on individual hosts or containers. Agent-based microsegmentation vendors operate at this layer. The model delivers finer-grained controls than zone-based segmentation but inherits the agent-dependency coverage gap for ephemeral and agentless workload types.

Zero Trust networking is the architectural outcome that both segmentation approaches aim for, but neither fully delivers. Zero Trust networking requires enforcement at workload identity granularity, on every path, independent of detection. Microsegmentation is a technique. Zero Trust networking is the standard the technique is measured against.

An architecture that delivers microsegmentation on virtual machines but has no enforcement on serverless functions, managed services, and AI agents is doing microsegmentation. It is not doing Zero Trust networking. The distinction matters because the unprotected workload types are exactly where modern breaches operate.

AI agents represent the fastest-growing and least-governed workload category in enterprise cloud environments. They make dynamic API calls to external services, access sensitive data stores, and operate with privileges granted during development that rarely get tightened before production.

The Zero Trust networking requirement for AI workloads is identical to the requirement for any other workload: workload identity, explicit least-privilege policy, inline enforcement at the network layer. The urgency is higher because the risk profile is different.

AI workloads are often highly privileged. They need access to sensitive data to function. They are frequently ephemeral, instantiated by an orchestration framework on demand. And they are rapidly deployed - AI development cycles outrun security review. The combination of high privilege, ephemeral compute, and fast deployment velocity is exactly the profile that makes Zero Trust networking most critical.

When an AI agent's dependencies are compromised through a poisoned package, a supply chain attack, or an injected prompt that redirects its behavior, the network path the agent is permitted to reach determines the Blast Radius. An AI agent with least-privilege Zero Trust network policy can only reach the services its policy explicitly permits. The attacker controls the code, but they do not control the network fabric.

The March 2026 LiteLLM supply chain incident demonstrated this concretely. A poisoned dependency harvested cloud credentials from Python environments across approximately 36% of cloud deployments. Customers with workload-level Zero Trust networking enforcement in place had their AI workloads operating under policies that did not permit outbound connections to attacker-controlled endpoints, the credential exfiltration path did not exist at the network layer. The compromise reached the workload and stopped there.

Zero Trust networking is not just an architectural best practice; it’s becoming a regulatory requirement.

NIST SP 800-207 defines Zero Trust Architecture across seven pillars. The Network and Environment pillar explicitly requires identity-based segmentation and enforcement of least-privilege communication paths between workloads, not just at the perimeter. The Workload pillar requires runtime protection and access control for every application component. NIST 800-207 does not describe a perimeter firewall deployment as a Zero Trust network architecture.

CISA Zero Trust Maturity Model 2.0 (ZTMM) provides a four-stage maturity model across five pillars. Reaching the Optimal stage on the Network pillar requires automated, dynamic least-privilege policy enforcement at the workload level, with continuous monitoring and real-time policy adjustment. Organizations still operating with static security-group rules and zone-based firewalls are typically at the Initial stage.

The Zero Trust Executive Order (Executive Order 14028, as extended and updated) directed federal agencies to implement Zero Trust network architectures by 2024 and continues to drive enterprise adoption in regulated sectors. The practical effect is that regulated industries, financial services, healthcare, federal contractors, defense industrial base, face compliance requirements that map directly to the five testable properties of a Zero Trust network architecture.

Zero Trust networking that delivers all five properties simultaneously addresses the core network and workload requirements across NIST 800-207, CISA ZTMM, PCI-DSS 4.0, HIPAA 2025, DORA, and NIS2. The controls are not separate frameworks stacked on top of each other, they converge on the same architectural requirements.

Aviatrix built the Cloud Native Security Fabric to deliver Zero Trust networking at the layer where cloud workloads actually communicate: inline, at every virtual private cloud boundary, across every cloud, without agents or code changes. The platform applies workload identity and least-privilege policy enforcement to every east-west and north-south workload connection in real time.

SmartGroups: Workload Identity, Not IP Addresses

The Aviatrix Distributed Cloud Firewall uses SmartGroups to resolve workload identity from cloud-native metadata: Kubernetes pod labels, namespaces, cloud resource tags, Lambda ARNs, and service account identifiers. Policy is written against workload identity, not IP addresses. When a pod reschedules, a function cold-starts, or a service scales horizontally, the policy follows the workload automatically without any rule updates.

This is the architectural equivalent of replacing "allow traffic from 10.0.0.5 to 10.0.1.20" with "the payment-service workload is permitted to call the fraud-detection service on port 443" - a policy that means something to the business and survives infrastructure changes.

Distributed Cloud Firewall: Enforcement at the Workload, Not at a Chokepoint

The Aviatrix Distributed Cloud Firewall enforces Zero Trust network policy at the virtual private cloud boundary - where egress and east-west traffic actually move, not at a centralized appliance that traffic must be steered through. Every workload in every virtual private cloud starts in a default-deny state. Permitted paths are explicitly added as the policy is built.

The enforcement model is path-complete by design: because the Policy Enforcement Point sits at the virtual private cloud boundary rather than at a centralized appliance, it governs traffic that would otherwise bypass a chokepoint inspection model, intra-VPC east-west traffic, serverless-to-managed-service calls, and lateral movement paths that fork before reaching a centralized inspection point.

WebGroups: Defined Egress Destinations for AI and Cloud Workloads

For north-south enforcement, Aviatrix maintains WebGroups - managed, auto-updated lists of permitted egress destinations for LLM providers, vector databases, model context protocol gateways, embedding services, and cloud provider APIs. A workload permitted to reach a defined WebGroup can connect to approved destinations. It cannot reach attacker-controlled endpoints or unauthorized external services, even if the code running inside the workload has been compromised.

WebGroups eliminate one of the most common Zero Trust networking gaps: broad egress permission. Most cloud workloads are granted outbound internet access to handle dependencies and API calls. WebGroups replace "allow all outbound traffic" with "allow outbound traffic to these specific, verified destinations."

AgentGuard: AI Agent Discovery and Containment

Aviatrix AgentGuard discovers every AI agent running across virtual machines, Kubernetes clusters, and serverless functions, including shadow agents and unauthorized deployments that security teams don't know exist. It maps the LLMs, tools, and data sources each agent connects to, builds a risk profile for each deployment, and enforces Zero Trust network policy on every agent's network communication path.

AI agents are workloads. AgentGuard treats them exactly that way: assigned a stable workload identity, governed by least-privilege policy, with all outbound calls filtered and logged.

Agentless Enforcement Across Every Workload Type

Aviatrix enforcement is fully agentless. The Policy Enforcement Point operates at the virtual private cloud level - a sidecar at the virtual private cloud, not at the pod or host, applying service-mesh-pattern enforcement to the VPC boundary. No agent deployment. No agent maintenance. No compatibility dependency on container runtimes or serverless execution environments.

One Policy Enforcement Point per virtual private cloud scales linearly. The same architecture that governs a single Kubernetes cluster governs a distributed multicloud estate of hundreds of virtual private clouds without re-architecture.

Cross-Cloud Policy Consistency

Aviatrix enforces the same workload identity model and the same least-privilege policies across AWS, Azure, GCP, and OCI from a single control plane. Cloud native security tools use different policy models and don't communicate across providers. A change in policy that should apply to all environments requires touching multiple provider-native configurations separately. The Aviatrix model makes policy cloud-agnostic: one rule, universal propagation, enforced everywhere within subseconds.

"We can't put agents on everything." You don't need to. Agentless network-layer enforcement covers every workload type, including the ones your agent-based tools can't reach. If agent coverage is the gap in your Zero Trust networking program, the right answer is to remove the agent requirement from the enforcement architecture, not to accept the coverage gap.

"Our policies will break constantly as workloads change." Policies written against workload identity don't break when infrastructure changes. The policy that governs "the payment-service workload" remains valid through a pod reschedule, a scaling event, or a deployment rollout. IP-based policies break constantly because IPs change constantly. Workload identity doesn't.

"We can't afford the latency of inline enforcement." This is a legitimate concern for enforcement architectures that route traffic through a centralized inspection appliance. Aviatrix enforcement operates at the virtual private cloud boundary via kernel-level processing, per-packet classification runs at approximately 5 microseconds, policy propagation completes in approximately 500 milliseconds without a dataplane reload. The performance impact is designed to be operationally invisible.

"We need to prove Zero Trust networking is working to our auditors." Continuous enforcement logging through Aviatrix CoPilot generates timestamped, machine-readable records of every policy decision: every accepted connection, every blocked attempt, every anomaly. That's the audit evidence chain compliance frameworks require, generated continuously, not assembled manually before each audit cycle.

"Zero Trust networking feels like a project that will take years to complete." It doesn't have to start that way. Aviatrix enforcement supports monitor-before-enforce mode: visibility without blocking, so you can observe what your traffic looks like before writing a single blocking rule. Start with your highest-risk virtual private cloud, watch the traffic for a defined window, then promote to enforcement. One virtual private cloud at a time. Back-out is a single setting flip.

Zero Trust networking is not a product you buy or a framework document you file. It is an architectural posture: every connection is verified, identity-driven, and enforced at the network layer, not detected after the fact.

Cloud environments have raised the stakes. Lateral movement lives inside the network, invisible to perimeter tools. IP-based policy breaks constantly in dynamic infrastructure. Agents can't reach the workload types most likely to be exploited. And detection-dependent models miss 82% of intrusions because valid credentials produce no anomalous signal.

The architecture that answers all of this enforces policy inline, at every workload, using workload identity rather than IP addresses, across every compute model, without requiring detection to trigger enforcement. That's what Zero Trust networking looks like when it's built for cloud environments, not retrofitted from the data center era.

Aviatrix is pioneering the Cloud Native Security Fabric — the architecture the Containment Era requires. The Cloud Native Security Fabric governs every workload communication path across every cloud, every VPC, every Kubernetes cluster, and every serverless function, from a single policy plane. One rule. Universal propagation. Enforced at the workload, not at a chokepoint. Trusted by more than 500 of the world's leading enterprises. For more information, visit aviatrix.ai.

1. NIST SP 800-207, Zero Trust Architecture — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

2. CISA Zero Trust Maturity Model 2.0 — https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf

3. Aviatrix 2025 State of Cloud Network Security Report — https://aviatrix.ai/resources/

4. Zscaler VPN Risk Report 2025 — https://www.zscaler.com/blogs/security-research/new-vpn-risk-report-56-enterprises-attacked-vpn-vulnerabilities

5. IBM Cost of a Data Breach Report 2025 — https://www.ibm.com/reports/data-breach

6. Aviatrix Threat Research Center — The Cascade (March 2026) — https://aviatrix.ai/learn-center/the-containment-era/the-cascade/

7. Executive Order 14028, Improving the Nation's Cybersecurity — https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/