Zero Trust for Workloads: How to Enforce Security at the Runtime Layer of Your Cloud

For fifteen years, security teams invested in detecting threats faster. The threats got faster too. AI-accelerated attacks now outpace the speed at which detection-era tooling can respond and the interior of the cloud has remained structurally open throughout. Identity providers are in place. VPNs have been replaced with ZTNA. MFA is enforced. And yet breaches are still spreading laterally, inside cloud environments, between workloads that nobody governs.

Aviatrix's 2025 State of Cloud Network Security report found that only 8% of organizations have actually implemented Zero Trust in practice. The gap is enforcement at the layer that matters most in cloud environments: the workloads themselves.

Most Zero Trust programs are user-centric. They verify the human before granting access to an application. That's important, but it leaves a structurally different attack surface completely unprotected. Once an attacker or a compromised workload is inside your cloud environment, the connections between containers, serverless functions, VMs, databases, and AI agents are wide open. Detection tells you something happened. Containment is what determines whether it mattered.

Zero Trust for Workloads is the enforcement layer that makes containment real.

In practice, it means every workload in your environment has a verified identity, every connection that workload makes is explicitly authorized, and all traffic to and from that workload is inspected and logged. This applies to:

• Kubernetes pods and containers

• Serverless functions (AWS Lambda, Azure Functions, GCP Cloud Run)

• Virtual machines and cloud-native compute instances

• AI agents, LLM inference pipelines, and agentic applications

• Microservices, APIs, and message queue consumers

The key distinction from traditional Zero Trust Network Access (ZTNA): ZTNA secures how humans access applications. Zero Trust for Workloads secures how workloads communicate with each other. These are different problems requiring different enforcement mechanisms.

The detection era's security model was built for a world of persistent workloads, centralized traffic flows, and human-speed attacks. That world no longer exists. Three structural gaps explain why traditional tools fail and why closing them requires containment architecture, not more sensors."

The Fragmentation Gap: Enforcement that stops at the perimeter

Most ZTNA solutions use a proxy architecture: all traffic is routed through a cloud-based intermediary that verifies user identity before forwarding the connection to the application. This model is effective for user-to-application access. It does nothing for workload-to-workload traffic. When your payment service calls your fraud detection service, that connection never goes through a user proxy. It moves east-west, inside your cloud environment, completely outside the scope of your ZTNA tool.

The Runtime Enforcement Gap: Agents that can't keep pace with ephemeral workloads

Some workload security approaches rely on deploying agents on each workload — software that monitors traffic and enforces policy at the endpoint. This works reasonably well for long-lived virtual machines. It breaks immediately for modern cloud architectures. A Kubernetes pod may live for 30 seconds. A serverless function spins up to handle one request and disappears. An AI agent is instantiated dynamically by an orchestration framework. You cannot deploy, manage, or maintain agents on infrastructure that doesn't persist.

Elephant in the Room

The Ownership Gap: Policies that break when workloads move

Traditional network security policies rely on IP addresses: allow traffic from 10.0.0.5 to 10.0.0.6. In a dynamic cloud environment, IP addresses are ephemeral and meaningless. When a Kubernetes pod reschedules, it gets a new IP. When a Lambda function cold-starts, it gets a new address. When you scale horizontally, you have dozens of IPs where you had one.

Any Zero Trust enforcement that relies on IP-based identity is broken the moment your workloads start doing what cloud-native workloads do: move, scale, and restart.

Zero Trust for Workloads needs to cover every path through which a workload communicates. There are five. Most organizations protect one or two. All five are attack vectors.

1East-West: Workload to Workload

This is the primary attack path for lateral movement. East-west traffic moves between services inside your cloud environment, your API gateway talking to your application layer, your application layer calling your database, your microservices communicating through a message queue. None of this traffic crosses the perimeter. All of it is potentially dangerous if one workload is compromised.East-west enforcement requires inline inspection between every workload that verifies the identity of both parties, confirms the connection is explicitly authorized, and blocks anything that isn't.

2North-South: Workload to Internet

Every outbound call your workload makes to an external service is a potential data exfiltration path or command-and-control channel. A compromised container calling out to an attacker's infrastructure. A misconfigured function exfiltrating data to an external storage endpoint. An AI agent making unauthorized calls to third-party APIs.Egress filtering controls these outbound paths, logging every external call, blocking unauthorized destinations, and alerting on anomalous outbound patterns.

3Workload to Data

The connections between your workloads and your data stores; databases, object storage buckets, and secret managers are among the most sensitive traffic in your environment. A compromised workload that can reach your primary database without restriction is a breach waiting to happen.Zero Trust enforcement at the workload-to-data layer means your microservices get access to only the specific data stores they need, for only as long as they need it, with every access logged.

4AI Agent and Agentic Application Traffic

AI agents are a new and rapidly growing workload type that introduces unique Zero Trust challenges. They make dynamic, often unpredictable API calls to external services, other AI models, data stores, and orchestration frameworks. They can be granted broad permissions during development that never get tightened before production. AI agents must be treated as any other workload in your Zero Trust architecture: assigned a workload identity, governed by least-privilege egress policies that allow only the external services they legitimately need, with every outbound call logged and everything else blocked. Aviatrix AgentGuard provides containment architecture purpose-built for agentic workloads.

5CI/CD Pipeline and DevSecOps Traffic

Your deployment pipelines are workloads too. A compromised CI/CD pipeline is one of the most dangerous attack vectors in cloud environments. It has access to production infrastructure, secrets, and deployment keys. Zero Trust for Workloads should extend to build agents, deployment runners, and the connections they make during pipeline execution.

Elephant in the RoomMost teams implement Zero Trust on paths 1 and 2 and consider the job done. Paths 3, 4, and 5 are where the most damaging breaches actually start — because they're the least monitored and the most trusted. Your database doesn't question why your application is suddenly querying every record in the table. Your secrets manager doesn't ask why the CI/CD runner is pulling every API key. Zero Trust for Workloads makes everything question everything.

Every security architecture makes a structural bet. Chokepoint security bets that all relevant traffic will route through a centralized enforcement point. Containment architecture: Communication Governance enforces policy at every workload, every path. Here's what that difference means in practice:

Everything in Zero Trust for Workloads depends on one thing: being able to identify a workload reliably, regardless of where it's running, what IP address it has, or how long it's been alive.

Traditional network security uses IP addresses as workload identity. In cloud environments, this breaks immediately. Dynamic workload identity solves this by assigning each workload a stable cryptographic identifier derived from its attributes, what it is, what it belongs to, what it's supposed to do rather than where it happens to be sitting on the network at this moment.

With dynamic workload identity, your policies say things like: "the payment-service workload may call the fraud-detection workload on port 443", not "allow traffic from 10.0.1.5 to 10.0.1.12." The former survives infrastructure changes. The latter breaks constantly.

Zero Trust for Workloads is an enforcement posture you build progressively. Here's a practical framework aligned with how Aviatrix ZTW customers approach implementation.

1Inventory your workloads and assign identity

You can't enforce Zero Trust on workloads you don't know exist. Start by cataloguing every workload in your environment: Kubernetes namespaces and deployments, serverless functions, VMs, and AI agents. For each, define a stable workload identity the label, tag, or attribute-based identifier that will follow it through the environment.

• Map all workloads across every cloud account and region.

• Define naming standards for workload identities that match your deployment patterns.

• Identify which workloads handle sensitive data and prioritize those for immediate enforcement.

2Map workload communication paths

Before writing a single policy, observe the actual traffic. What talks to what? Which services call which APIs? Where does data flow between workloads and datastores? What does your CI/CD pipeline touch?Use your cloud provider's flow logs, a network observability tool, or Aviatrix CoPilot to build a communication map. Distinguish between expected traffic (your app calling your database) and unexpected traffic (your app calling an external IP at 2am).

3Define least-privilege workload policies

With your communication map in hand, define policies that explicitly authorize only the connections your workloads need. Start with a default-deny posture for everything, then layer in explicit allow rules for each legitimate path.

• Use workload identity not IP or CIDR as the subject and target of every policy.

• Scope policies to specific ports and protocols not "allow all traffic between workload A and workload B."

• Include time-bound policies for CI/CD and AI agent traffic that should only run during specific windows.

• Start with your highest-risk paths: workload-to-database, service-to-secrets-manager, AI agent egress.

4Enforce inline, without agents

Once policies are defined, enforcement needs to happen inline, intercepting and verifying each workload connection as it's made, not inspecting it after the fact. This is where agent-based approaches fail for ephemeral workloads and where Aviatrix ZTW's agentless model is essential.Agentless enforcement works by operating at the network layer rather than the endpoint layer. The enforcement mechanism sits between workloads not on them, so it doesn't require installation, maintenance, or compatibility with every workload type you run.

Critical Issue "Agentless" doesn't mean invisible or unaccountable. It means enforcement operates at the network layer, independently of your workloads and independently of whether a breach has been detected. This is containment: the policy holds before, during, and after a compromise. Every connection is verified. Every unauthorized path is blocked. Detection isn't a prerequisite for enforcement. The difference is you're not managing agent deployments across thousands of ephemeral pods or debugging why an agent couldn't start on a particular function runtime.

5Monitor, adapt, and prove enforcement continuously

Zero Trust for Workloads is not a one-time configuration. Your workloads change constantly, new services get deployed, existing ones get refactored, traffic patterns shift. Your enforcement posture needs to keep pace.

1. Log every workload connection, accepted and denied with workload identity, timestamp, and policy applied.

2. Alert on deviations from baseline traffic patterns. A workload calling a service it has never called is worth investigating.

3. Review and tighten policies regularly. Over-permissive rules accumulate if you don't revisit them.

4. Generate audit-ready reports, compliance teams need continuous evidence that controls are enforced, not just configured.

Kubernetes and containerized environments

Kubernetes is the canonical example of why traditional security tools fail for workloads. Pods are ephemeral. Namespaces are logical boundaries that don't correspond to network segments. Services communicate across namespaces constantly. IP addresses rotate with every scaling event.

Zero Trust for Workloads in a Kubernetes environment means every pod has a stable identity, every inter-namespace connection is explicitly authorized, and every connection attempt that violates policy is blocked inline before it can be used for lateral movement.

Serverless and event-driven architectures

Serverless functions are among the most difficult workloads to secure because they have no persistent state, no fixed IP, and often no agent support. They're also increasingly common entry points for data exfiltration, a misconfigured Lambda function with overly broad egress permissions can exfiltrate data to an external endpoint with no one watching.

ZTW's agentless enforcement covers serverless functions natively: each function instance is identified by its workload attributes, its outbound calls are filtered against egress policy, and every invocation is logged.

AI agents and agentic applications

AI agents introduce a new dimension of workload security risk. Unlike a traditional microservice that calls a predictable set of APIs, an AI agent makes decisions dynamically and those decisions can result in unexpected API calls, data access, or outbound connections that no human explicitly authorized.

Treat AI agents as workloads, not users. Assign them a workload identity. Define least-privilege egress policies that allow only the external services they legitimately need. Log every outbound call. Block everything else. The autonomy of the AI decision-making layer does not mean its network access should be autonomous.

Ransomware prevention and lateral movement blocking

Ransomware spreads by moving laterally through environments with flat east-west connectivity. A compromised container calls an adjacent service. That service calls a database. The database credentials get exfiltrated. The encryption starts.

Zero Trust for Workloads interrupts this chain at the first lateral hop. If your payment service doesn't have an explicit policy to call your HR database, that connection is blocked even if the payment service is fully compromised. Blast radius becomes a structural property of the architecture - limited before the incident, not managed during the response.

Compliance: PCI-DSS, HIPAA, FedRAMP, SOC 2

Every major compliance framework increasingly requires evidence of runtime enforcement, not just policy documentation. PCI-DSS requires microsegmentation of cardholder data environments. FedRAMP references NIST 800-207's Zero Trust requirements. HIPAA requires access controls on workloads that handle protected health information.

Aviatrix ZTW generates continuous, machine-readable logs of every workload connection accepted and denied by providing the audit-ready evidence these frameworks require without a manual reporting sprint before every audit.

Without real enforcement at the workload layer, Zero Trust remains a well-intentioned framework rather than an operational reality and containment remains an aspiration rather than an architectural property. Aviatrix Zero Trust for Workloads (ZTW) is the enforcement layer of the Containment Platform: delivering pervasive, agentless communication governance across every workload communication path, independent of whether a compromise has been detected, without requiring changes to your applications, your cloud architecture, or your existing workflows.

Agentless by design

ZTW enforces Zero Trust at the network layer, not the endpoint layer. There's no agent to deploy, no agent to maintain, no agent compatibility to manage across your container runtimes. Enforcement works for Kubernetes pods that live for 10 seconds, Lambda functions that execute once, and AI agents that are instantiated dynamically by an orchestration framework.

Dynamic workload identity, not IP addresses

Every workload in your environment gets a stable identity derived from its attributes, what it is, what namespace it belongs to, and what tags it carries not its IP address. Policies follow workloads through scale events, reschedules, deployments, and migrations. IP changes are invisible to the policy engine.

Inline east-west enforcement

ZTW inspects every workload-to-workload connection inline, at the point of communication, not in a log review after the fact. Every hop is verified against policy. Unauthorized connections are blocked before they can be used for lateral movement. Every accepted and denied connection is logged with full workload identity context.

Egress filtering for north-south and workload-to-internet traffic

Every outbound call from your workloads to external APIs, third-party services, or the internet is filtered against egress policy. Data exfiltration paths and command-and-control channels are blocked before data leaves your environment. AI agent calls to unauthorized external services are blocked inline.

Cross-cloud consistency - AWS, Azure, GCP, OCI

ZTW enforces the same workload identity model and the same least-privilege policies across every cloud in your environment. The same policy that governs your Kubernetes pods in AWS applies to your serverless functions in Azure and your VMs in GCP from a single control plane, without rewriting rules for each cloud's native security model.

CoPilot visibility and Wiz integration

Aviatrix CoPilot provides runtime visibility over workload traffic flows, anomalies, and gateways across clouds with audit-ready logging for compliance. The Wiz partnership surfaces and prioritizes workload security findings so your team acts on the highest-risk issues rather than drowning in undifferentiated alerts.

We can't put agents on everything You don't need to. Agentless enforcement at the network layer covers every workload type, including the ones your agent can't reach. If agent deployment is the reason your workloads aren't protected, the answer is to remove the agent requirement, not to carve out exceptions. Agentless also means detection-independent: enforcement operates regardless of whether a breach has been detected, not only when an agent is alive and reporting.

Our policies would need constant updates as workloads change Policies tied to workload identity rather than IP addresses survive infrastructure changes automatically. The policy that says "payment-service can call fraud-detection on port 443" remains valid through reschedules, scaling events, and deployments. You update policies when the business logic changes, not every time a pod restarts.

We can't afford the latency of inline enforcement This is a real concern with some enforcement architectures that route traffic through centralized inspection points. ZTW's inline enforcement operates at the network fabric level, not through a traffic hairpin to a central proxy. The performance impact is designed to be negligible for production workload traffic.

We already have a CWPP and CNAPP - why isn't that enough? CWPPs and CNAPPs detect and alert. They are not inline enforcement tools, they observe and report after the fact. Detection tells you something happened. Containment is what determines whether it spreads. ZTW enforces policy at the connection level, blocking unauthorized traffic before it can be used for lateral movement. Detection after the fact does not prevent blast radius from expanding. Inline enforcement does.

What if we get breached before we finish rolling out enforcement? Containment architecture is detection-independent, enforcement holds before, during, and after a compromise without requiring a breach to have been detected first. The policy governing what your payment-service can reach doesn't wait for an alert to fire. It's enforced at every connection, continuously. Partial rollout still limits blast radius structurally on every workload it covers.

We need to prove it's working to auditors This is one of the most underrated requirements in Zero Trust programs. CoPilot's logging gives you continuous, timestamped, machine-readable records of every policy decision every accepted connection, every denied attempt, every anomaly. That's the evidence chain auditors want, generated automatically, not assembled manually before each audit.