The prevailing architectural pattern in agent runtimes—co-locating the orchestrator, tool executors, and the LLM backend process on the same host network stack—presents a significant, and often overlooked, lateral movement risk. A compromised model backend, whether through prompt injection or a dependency exploit, immediately gains the ability to perform network reconnaissance and initiate outbound connections to attacker-controlled infrastructure, potentially exfiltrating data or fetching secondary payloads.

Isolating the model backend into a dedicated network namespace is a fundamental containment step. It transforms a network breach from a host-level event into a namespace-local one. Below is a practical implementation sequence, moving from manual inspection to integration into a service manager like systemd.

First, we can create and enter a new network namespace to verify isolation. This is a foundational test.

```bash
# Create a persistent namespace
sudo ip netns add model-backend-ns

# Enter the namespace and inspect. No interfaces except loopback.
sudo ip netns exec model-backend-ns ip addr list
```

The namespace is now an empty network container. To provide controlled egress (if required for the model's API dependencies), we must establish a virtual Ethernet (veth) pair, placing one end in the new namespace and the other in the host's root namespace, then apply routing and Network Address Translation (NAT).

```bash
# Create veth pair: `veth-model` (host side) and `veth-ns` (namespace side)
sudo ip link add veth-model type veth peer name veth-ns

# Move the `veth-ns` end into the isolated namespace
sudo ip link set veth-ns netns model-backend-ns

# Configure IP addresses
sudo ip netns exec model-backend-ns ip addr add 10.100.1.2/24 dev veth-ns
sudo ip addr add 10.100.1.1/24 dev veth-model

# Bring interfaces up
sudo ip netns exec model-backend-ns ip link set veth-ns up
sudo ip link set veth-model up

# Enable IP forwarding on host and setup NAT masquerade for outbound traffic
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -s 10.100.1.0/24 -j MASQUERADE

# In the namespace, set the default route via the host-side veth IP
sudo ip netns exec model-backend-ns ip route add default via 10.100.1.1
```

For production integration, the service unit for your model backend must be launched within this namespace. With systemd, this is achieved using the `NetworkNamespacePath` directive, referencing the namespace via its path in `/var/run/netns`. First, make the namespace persistent by bind-mounting it.

```bash
# Ensure the netns directory exists and bind-mount the namespace
sudo mkdir -p /var/run/netns
sudo touch /var/run/netns/model-backend-ns
sudo mount --bind /proc/1/ns/net /var/run/netns/model-backend-ns
```

Then, a systemd service file snippet would include:
```ini
[Service]
NetworkNamespacePath=/var/run/netns/model-backend-ns
# ... other restrictions like PrivateTmp, CapabilityBoundingSet
```

Critical considerations:
* This configuration provides outbound connectivity only. For true network segmentation, you must implement egress filtering on the host using `iptables` rules on the `veth-model` interface or `nftables` to restrict destinations to only allowed API endpoints (e.g., OpenAI, Anthropic).
* Combine this with other Linux security primitives for a defense-in-depth posture:
* A tight `seccomp-bpf` filter to limit syscalls like `connect`, `socket`, and `accept`.
* Dropping all capabilities (`CAP_NET_RAW`, `CAP_NET_ADMIN` are especially dangerous).
* Mount namespaces with read-only views for model weights and configuration.

The final architecture ensures that even if the model process is fully compromised, its ability to pivot to other internal services or call out to arbitrary external hosts is mechanically constrained by the kernel's network stack isolation.

Sara