Zero-Trust Networking for Multi-Agent Production Systems — Service-Mesh mTLS, Network Segmentation, and the East-West Authorization Discipline

Prove each end. Permit each flow. Authorize each action. Deny everything left unnamed.

§ IFrame

The β-Trust Wednesdays have been spent closing the seams between the build and the running pod. Workload identity gave each agent a cryptographic name. Admission control gave the cluster a place to reject a workload before the kubelet pulled it. Supply-chain provenance gave the operator a record of where every running byte came from. Each of those gates inspects a workload at the moment it enters the cluster. None of them governs what the workload does once it is alive and talking to its neighbors.

The talking is where a multi-agent system spends most of its life. A routing agent calls a retrieval agent, which calls a vector store, which calls an embedding service, which reads from a model server. Five workloads, four network hops, and every hop crosses a piece of cluster network that, by default, any pod can reach. The default Kubernetes network is flat. A pod in one namespace can open a socket to a pod in any other namespace unless an operator has decided otherwise. An attacker who compromises the lowest-value workload in the cluster inherits a network position from which every higher-value workload is one TCP connection away.

This lesson governs the talking. Three named techniques carry it: mutual TLS, which proves each end of a connection to the other; network segmentation, which decides which workloads may open a connection at all; and east-west authorization, which decides what a proven, permitted caller is allowed to ask for. The spine under all three is one rule, stated once and applied at every layer: deny by default, permit by name. The same rule runs today's cert lesson on Kubernetes network policy and today's dev lesson on the browser's trust boundary. One discipline, three surfaces.

§ IIFoundations

Network traffic in a cluster runs in two directions, and the names matter because the defenses differ. North-south traffic crosses the cluster boundary: a user's request arriving at an ingress, a workload reaching out to an external API. East-west traffic stays inside the cluster: pod to pod, service to service. Perimeter security has always watched north-south. The firewall, the ingress controller, the WAF all sit at the boundary and inspect what crosses it. East-west traffic has historically run unwatched, on the assumption that anything already inside the perimeter was trusted.

Zero-trust discards that assumption. The premise is plain: location on the network grants nothing. A packet that originates inside the cluster earns no more trust than a packet from the open internet. Every connection proves its identity, every connection is checked against a policy, and the default answer to an unproven or unlisted connection is no. The phrase that names the posture is never trust, always verify, and the operational consequence is that the cluster needs three mechanisms it did not need when it trusted its own interior.

The first mechanism answers who is this. Transport Layer Security, run in mutual mode, has each side present a certificate and verify the other's. The second answers may this connection exist. A network policy names which workloads may open connections to which other workloads, and the network plane drops anything not named. The third answers may this caller do this thing. An authorization layer reads the proven identity and the requested action and returns a permit or a deny. The three stack. Identity without segmentation lets a proven workload reach everything. Segmentation without authorization lets a permitted connection ask for anything. All three together close the interior.

§ IIIMechanism

The three mechanisms compose into one sentence the operator can hold: a connection in this cluster is allowed only if both ends prove who they are, a policy permits the flow, and an authorization rule permits the action. Strip any one of the three and the sentence loses a clause the attacker walks through.

§ IVWorked Example

A fleet runs the five-workload inference path from the frame: an ingress gateway, a routing agent, a retrieval agent, a vector store, and a model server. The fleet adopts a service mesh with mutual TLS in strict mode, default-deny network policies in every namespace, and authorization policies on the two highest-value workloads. Walk a request through, then walk an attacker through.

A user request arrives at the ingress gateway over ordinary server-side TLS. The gateway terminates the public connection, authenticates the user, and opens an outbound connection to the routing agent. That connection is mutual-TLS: the gateway's sidecar presents the gateway's certificate, the routing agent's sidecar verifies it against the mesh certificate authority and presents its own in return. A network policy on the routing agent permits inbound connections from the ingress gateway's identity and from no other source. The routing agent decides the query needs retrieval and connects to the retrieval agent. Same mutual-TLS handshake, same network-policy check. The retrieval agent connects to the vector store and to the model server. Each hop proves both ends, each hop is checked against a policy that names exactly that flow, and the model server carries an authorization policy permitting the retrieval agent to call the inference route and nothing else. The request completes. Every connection it traveled was proven, permitted, and authorized.

Now the attacker. A dependency in the routing agent carries a vulnerability, and the attacker gains code execution inside the routing agent's container. The attacker holds a real, mesh-issued certificate, because the sidecar will sign outbound connections for whatever the compromised process opens. Identity alone does not stop the attacker; the attacker has a valid identity. Segmentation does. The attacker tries to reach the vector store directly to exfiltrate embeddings. No network policy permits a flow from the routing agent to the vector store, because the design never needed one, so the packets are dropped at the network plane and the connection times out. The attacker falls back to the one flow the routing agent is permitted: the connection to the retrieval agent. That connection succeeds, because the design needs it. The attacker now tries to make the retrieval agent request a model swap on its behalf. The model server's authorization policy permits the retrieval agent to call inference only; the swap request returns 403. The attacker has been confined to exactly the capability the compromised workload legitimately held. The blast radius equals the routing agent's own permissions, and not one connection more.

Compare the same compromise on a flat network. The attacker lands in the routing agent and finds the vector store, the model server, and every other namespace one connection away, each speaking plaintext, none checking the caller. The compromise of the lowest-value workload becomes the compromise of the cluster. The difference between the two outcomes is three mechanisms and one default.

There is a cost to name honestly. Mutual TLS adds a handshake and a few milliseconds per connection. The sidecar adds memory and a process per pod. Default-deny policies break workloads the first time a forgotten flow meets production, which is why they break in staging first. The fleet pays this cost on every request for a defense that matters on the rare request that is an attack. That trade is the trade zero-trust asks the operator to make, and a multi-agent system, with its long internal call graphs and its many low-value entry points, is exactly the system where the trade pays.

§ VConnection to Prior Lessons

Three earlier β-Trust lessons compose with this one.

Workload identity (2026-05-20) issued each agent a SPIFFE identity attested at runtime. That lesson named the identity; this lesson puts it to work at the transport layer. The certificate the mesh sidecar presents on every mutual-TLS handshake is that SPIFFE identity. Identity was the noun; mutual TLS is the verb that checks it on every connection.

Admission control (2026-05-27) gave the cluster a webhook chain that runs before a pod starts. Admission governs entry; network policy governs conduct after entry. A pod admitted by the webhook is a pod the cluster agreed to run, but agreeing to run a workload is not agreeing to let it reach every other workload. The two gates ask different questions at different moments: admission asks may this exist, segmentation asks may this connect.

Supply-chain provenance (2026-06-03) closed the seam before the kubelet by proving where the bytes came from. This lesson closes the seam after the kubelet by governing where the bytes may talk. Provenance is the workload's past tense; network policy is its present tense. An attacker who slips a malicious image past provenance, perhaps through a compromised maintainer account, still lands inside the segmentation. The gates are independent on purpose, so that defeating one leaves the others standing.

The β-Trust arc now reads end to end: identity names the worker, admission decides entry, provenance records the build, and segmentation governs the conversation. Four gates, four seams, each looking at a different moment in the life of the workload.

§ VIConnection to Today's Dev + Cert Lessons

The cert lesson today is the hands-on Kubernetes form of this lesson's segmentation section. It works NetworkPolicy resources directly: the default-deny manifest, the ingress and egress selectors, and the CKS extension into Cilium's CiliumNetworkPolicy for layer-7 rules and identity-aware enforcement. Where this lesson described the discipline, the cert lesson writes the YAML that enforces it and debugs the dropped connection when a policy is too tight.

The dev lesson carries the same default-deny spine into the browser. Content Security Policy is the browser's network policy: a default-deny list of which origins a page may load script, style, and connections from, with each permitted origin named explicitly. Subresource Integrity is the browser's provenance check, refusing a script whose hash does not match the one the page authorized. The same-origin policy is the browser's segmentation, walling one origin's data off from another's script. The cluster and the browser are different machines running one idea: deny by default, permit by name, prove before you trust.

§ VIIClosing

The interior of a cluster is not a safe place that the perimeter protects. It is a network where five workloads make four hops, and every hop is a place a compromise can spread unless the operator decided otherwise. Zero-trust networking is the decision, made three times: prove each end, permit each flow, authorize each action, and deny everything left unnamed.

A flat interior tells the attacker that one foothold is the whole cluster. A segmented interior tells the attacker that one foothold is one foothold. The work between those two sentences is mutual TLS, network policy, and authorization, stacked on a default that says no. Walk the call graph; close each seam where two workloads meet; trust nothing for being inside.