Three UIDs make AI agent containment workable on Linux

At a glance

What this is: This is a Linux containment pattern for AI agents that uses three UIDs, nftables, and proxy-mediated egress to keep the agent inside a kernel-enforced boundary.

Why it matters: It matters because IAM-style separation still fails if the agent shares identity with the proxy or the operator, so practitioners need process-level identity boundaries as well as network controls.

Context

A Linux containment boundary for an AI agent only works when identity, process launch, and network egress are separated. If the agent shares a UID with the proxy or the operator, the kernel cannot distinguish their traffic, so the control fails at the identity layer before it fails at the firewall.

This article is really about how AI agent authorisation becomes enforceable on a single workstation. The important question is not whether a proxy exists, but whether the agent has a distinct runtime identity that can be denied direct egress while still using a controlled exit path.

Key questions

Q: What breaks when an AI agent shares a UID with its proxy or operator?

A: The boundary breaks because the kernel can no longer distinguish the agent from the process that is allowed to reach the internet. When the agent shares the proxy UID, it inherits the proxy’s egress. When it shares the operator UID, it inherits normal desktop access. Containment only works when the agent has a distinct runtime identity that can be denied separately.

Q: Why do AI agents need proxy-mediated access instead of direct internet access?

A: Proxy mediation matters because it turns outbound traffic into a governed path rather than an open network capability. Direct internet access makes it impossible to prove whether a request came from the agent or from a more trusted process. A controlled proxy keeps the exit point stable, inspectable, and revocable while the agent remains inside the host boundary.

Q: How do security teams know whether containment is actually working?

A: They should test whether the identity can still execute privileged actions after revocation, not just whether the API call succeeded. A working containment model prevents re-escalation, blocks credential regeneration, and remains effective even when the target is polling for state changes. If any of those fail, containment is only partial.

Q: What is the difference between process isolation and network containment for AI agents?

A: Process isolation limits what the agent can execute on the host, while network containment limits where it can send traffic. Both matter, but neither is sufficient alone. A process can still exfiltrate if its egress is unrestricted, and network rules can be bypassed if the launch path does not enforce a distinct runtime identity.

Technical breakdown

Why two UIDs collapse under shared egress

A two-UID model breaks because one identity must be both the allowed exit path and the restricted process. If the agent runs as the proxy UID, it inherits the proxy’s internet access. If it runs as the operator UID, it inherits the operator’s full egress posture. Linux nftables can filter by UID, but it cannot distinguish intent inside one identity. That is why the containment problem is structural: the firewall needs a third subject to target, not a more complex rule set. The right design creates a UID that exists only for the agent process tree, so the kernel can deny outbound traffic without affecting the operator or the proxy. See the AI Agent Authorisation Guide.

Practical implication: Create a dedicated agent UID instead of trying to multiplex proxy and agent behavior through one account.

How the nftables boundary actually enforces containment

The OUTPUT chain acts as the hard boundary. Loopback is accepted first so the agent can reach the local proxy, then the operator UID and proxy UID are allowed, and finally the agent UID is limited to DNS over loopback before everything else is dropped. That order matters because nftables evaluates rules top to bottom. The model relies on the proxy being the only identity with real internet access, while the agent remains trapped inside local routing. This is the same containment logic Kubernetes NetworkPolicy applies at pod level, brought down to a single Linux host. Read Zero Trust for AI Agents.

Practical implication: Verify rule order and UID matching with test traffic before trusting the boundary.

Why the wrapper and CA bundle are part of the control, not extras

Containment is not complete if the agent cannot use the proxy cleanly. The wrapper launches the process under the contained UID and injects proxy settings plus the trusted CA bundle, so TLS interception does not masquerade as a firewall problem. That means process launch, trust store management, and egress control are one control surface. If the CA bundle is missing or stale, the agent fails at certificate validation before the network policy is ever exercised, which obscures whether containment is really working. Operationally, the wrapper turns an identity boundary into something repeatable instead of a manual shell ritual. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Treat launcher scripts and trust-store refresh as part of the containment control, not supporting documentation.

Threat narrative

Attacker objective: The objective of the failure pattern is to let the agent reach external services directly instead of forcing all egress through the controlled proxy boundary.

1. Entry occurs when the operator launches an AI agent through a wrapper that assigns it a contained UID and local proxy path.
2. Escalation is prevented only if the agent cannot inherit the proxy UID or the operator UID, because either path would restore broad egress.
3. Impact is the ability to confine the agent’s outbound traffic to loopback and proxy-mediated requests instead of unrestricted internet access.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Three-UID containment is a governance model, not a shell trick. The article shows that the real control is not the proxy itself but the identity separation that makes proxy mediation enforceable. When the agent, the proxy, and the operator are forced into distinct runtime identities, the kernel can make a meaningful allow or deny decision. That is the difference between policy and containment, and practitioners should treat the UID boundary as the security primitive.

Runtime identity collapses if the agent can impersonate the exit path. The proxy needs direct internet access because it is the controlled exit, but that assumption fails if the agent shares the same UID. This is a classic assumption collapse: least privilege was designed for a stable subject, yet the agent and the proxy become indistinguishable at the kernel boundary. The implication is that identity governance must model process identity, not just user identity.

Zero trust for AI agents starts at the host boundary. The article’s model is a local example of continuous verification, but the interesting part is that verification is happening through runtime separation, not a login event. If the operator can launch agents without a distinct contained identity, the control is already weakened. The practitioner conclusion is that agent authorisation has to begin before network access exists, not after the agent is already running.

Wrapper-based launch control is the difference between a lab pattern and an operable control. The nftables rule set is necessary, but it becomes maintainable only when the launcher, sudoers carve-out, and CA bundle are managed as one governed path. That makes the boundary auditable and repeatable across workstations. Practitioners should read this as a lifecycle problem: the agent must be created, run, refreshed, and rolled back under the same containment model.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Zero Trust for AI Agents

What this signals

Identity-bound egress is the real control point for workstation agents. Once an agent can only move through a separately governed proxy path, the programme shifts from generic endpoint hardening to explicit runtime authorisation. That is the practical lesson for teams piloting local AI tooling: if you do not control the identity that launches the agent, you do not control the agent.

Agent containment only scales when launch, trust, and rollback are managed together. A wrapper, a CA bundle, and a reversible firewall table are not separate hygiene tasks. They form one operating model that determines whether local AI agents remain auditable, supportable, and safe to remove when the workflow changes.

70% of organisations grant AI systems more access than they would give a human employee performing the exact same job. That pattern explains why workstation-level agent containment matters now: the default failure mode is over-access, not under-access, and the fix has to start at issuance time.

For practitioners

• Define a dedicated agent UID Separate the agent process from both the operator and proxy identities so the firewall has a unique subject to deny. See the Agentic AI Identity Guide.
• Enforce loopback-only agent egress Use nftables OUTPUT rules that accept loopback, allow the proxy UID, and drop all non-DNS traffic from the agent UID.
• Launch agents only through a wrapper Require a controlled launcher that sets proxy variables, trust store paths, and the contained UID before any agent process starts.
• Test containment with explicit probes Run separate checks for operator access, proxy access, direct agent failure, and agent success through the proxy before declaring the boundary valid.
• Script rollback as part of installation Automate teardown of the nftables table, wrapper scripts, sudoers exception, and service state so the control can be removed safely.

Key takeaways

• The core risk is structural: if an AI agent shares identity with the proxy or operator, the firewall cannot enforce a meaningful boundary.
• The article’s model proves that containment depends on a distinct agent UID, loopback-only reachability, and a proxy that acts as the only exit path.
• Practitioners should operationalise the boundary as a launch-and-teardown lifecycle, not as a one-time firewall change.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Guide

Key terms

• Agent containment: Agent containment is the set of boundaries that prevent an AI agent from reaching data, tools, or systems beyond its intended scope. In practice, it combines sandbox isolation, network restrictions, credential limits, and policy enforcement around runtime action.
• Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.
• Loopback proxy boundary: A containment pattern where the agent can only communicate with a local proxy over loopback and cannot reach the internet directly. This creates a controlled exit path that can inspect, permit, or deny traffic before it leaves the host.
• UID separation: The practice of assigning different Linux user IDs to the operator, the proxy, and the agent so that kernel-level policy can distinguish their traffic and privileges. For agent containment, UID separation is the mechanism that makes per-process egress control possible.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.