How Kern Isolates an AI Agent
The engineering behind a structural boundary: Linux process isolation, a network firewall, and how even trusted domains can be used maliciously.
In the last post I argued that an autonomous agent needs a structural boundary: enforcement outside the agent, not rules in its prompt. Kern implements that boundary in three layers: who the agent is on the host, where it can send data, and what it may send to an allowed destination.
Who: Linux process isolation
Each Kern host is a single-tenant AWS EC2 instance. Its operator is the trusted administrator. Kern's admin API and runtime manager run as kern-admin, while the agent's harness CLI runs as a separate, least-privileged user calledkern-agent.
The important split is between Kern's administrative machinery and everything the agent controls. Every script, shell, and service the agent starts remainskern-agent. Linux applies that uid to process and filesystem checks, so launching another program cannot create new authority.
Inside its own home, the agent owns its files and processes. Outside it, the agent has no sudo, database role, or privileged group membership. It cannot modify Kern's code, configuration, network policy, proxy certificates, or admin API.
The agent still needs to call a few host services, and Unix sockets can easily become a shortcut around user isolation. Each socket is owned by the service account that creates it, and filesystem permissions keep the agent away from private endpoints. Services intentionally exposed to the agent read the caller's uid from kernel peer credentials and treat every request as untrusted input.
The result is an agent that can work without permission prompts inside its own home, but has no authority over the machinery enforcing its boundary.
Where: Network firewall
Kern exposes two outbound paths. Open-ended direct network access goes throughkern-proxy. Packaged tool actions use kern-tools, which holds credentials outside the agent, restricts operations, and can wait for human approval.
kern-agentNo direct internet accessDirect network calls
kern-proxyChecks destinations, requests, and messagesTool actions
kern-toolsAudited internet paths and approval rulesA uid-scoped Linux firewall enforces that split. kern-agent has no direct internet or DNS route. General network calls can reach only the loopback proxy, while tool actions cross a controlled service interface. If the proxy stops, direct network calls stop with it rather than falling back to an unfiltered route. Tools continue through their separate service.
When the agent makes an HTTPS request, it connects to Kern's proxy rather than directly to the destination. That gives the proxy a chance to decide whether the request should proceed before anything leaves the host.
The proxy enforces an operator-managed allowlist of destinations. It checks each requested domain against that policy before DNS. That ordering is easy to overlook, but it matters: a DNS lookup is already an outbound message. An agent could encode a secret in<secret>.attacker.example without ever opening a connection. If the requested domain is not on the allowlist, or the policy is unavailable or invalid, the request stops there.
Once a domain is allowed, the proxy presents a certificate signed by Kern's local CA, which the agent environment trusts. It can then inspect each HTTP request and WebSocket message before forwarding it over a separate, verified TLS connection to the real server. An allowed domain therefore does not become a blind encrypted tunnel.
The proxy also checks where that domain resolves and connects only to publicly routable addresses. Without this check, an allowed hostname could point to loopback, the cloud metadata endpoint, or a service inside the VPC. The agent could then use the proxy as a route back into private host infrastructure.
A new host starts with no allowed domains. The first domain an operator will naturally want to allow is an AI provider; for Codex, that is api.openai.com. It sounds like a simple exception, but this one domain is surprisingly tricky to allow safely.
What: Request-level policy
Allowing api.openai.com lets Codex run inference, but it also opens other doors. OpenAI's API offers live web-search and page-fetch tools, which let the agent ask OpenAI's servers to fetch an arbitrary page. In my testing, OpenAI passed the requested URL parameters and data through unfiltered. That turns a connection intended for inference into a direct exfiltration path.
Kern does not solve this by blocking search altogether. Its OpenAI guard reads every HTTP request body and client WebSocket message, blocks live search and page-opening capabilities, but allows cached web search. The agent can query content OpenAI has already indexed without causing a new request to an agent-chosen site. Kern configures the harness not to request blocked features, but does not rely on its cooperation. The proxy remains the enforcement point.
The second path opened by api.openai.com is exfiltration into someone else's OpenAI account. The operator may accept OpenAI's data policy for the configured account, but an agent could obtain a token for a different account, perhaps one controlled by an attacker. It could then send data or upload files that the other account owner can retrieve. Kern prevents this by pinning the approved account and requiring both the account-id header and the bearer token's account claim to match. Copying the approved header while using a foreign credential is still denied.
Kernel firewalldirect access blocked
nftables blocks the agent uid from direct internet and DNS access. Direct network calls can reach only the local proxy.
Domain policyallowed domain or 403
The proxy loads the current allow list for every request. A missing domain, invalid policy, or database failure denies the request.
HTTPS inspectionrequest visible
After the domain is allowed, the proxy terminates HTTPS with a certificate from Kern's local CA. It later establishes a separate verified TLS connection upstream.
Request guardallowed request or 403
Service-specific rules cross-check the OpenAI account header and bearer-token claim, then inspect HTTP bodies and WebSocket messages for features that could contact a live external site.
DNS resolutionpublic address only
Only now does the proxy resolve the approved host name, and only to a publicly routable address. A denied host never reaches DNS.
Upstream connectionaudited upstream
The proxy opens a separate verified TLS connection and logs the policy decision for audit.
The layers work together
No single check creates this boundary. Linux identity limits who agent-controlled code can become. The firewall and proxy control where it can connect. Request guards control what it can send through an approved destination. Each decision is made by machinery the agent cannot modify. That lets Kern give the agent maximal autonomy inside its workspace while trusting the boundary around it.
Kern still trusts the Linux kernel, the host administrator, and the external providers it connects to. This design does not claim to contain a kernel privilege-escalation exploit or a compromised provider, for example if OpenAI itself is breached. The code is open if you want to inspect it at github.com/infiloop2/kern. The next post follows the internet boundary further: how Anthropic, Amazon Bedrock, and GitHub need their own request controls, and when Kern exposes a packaged tool with a human approval layer instead of giving the agent a general network path.