How Edera Could Have Contained the Gemini Breakout

The Wall Street Journal reported that Google’s Gemini accessed three real companies while participating in a cybersecurity evaluation run by Irregular. The evaluation was supposed to operate against a fictional company in a controlled environment. That fictional company shared a name with a real company, and the agent had internet access that it was not supposed to have. Gemini went looking for the target, reached systems outside the evaluation environment, and interacted with them as though they were part of the exercise.

In one case, Gemini reportedly guessed passwords until it was authenticated successfully. In the other two, it found credentials in public repositories and used them to access protected systems. There was no reported Linux kernel exploit, container escape, hypervisor vulnerability, namespace breakout, or some new class of AI-specific exploit. The agent had a network path to real systems, found credentials those systems accepted, and used them.

Most sandbox security starts with what happens when code inside the sandbox becomes hostile. Containers rely on namespaces, cgroups, capabilities, seccomp, LSMs, filesystem controls, and the host kernel to constrain a process. VMs move the boundary underneath the guest kernel and rely on the hypervisor to separate the guest from the host and other guests. Both approaches are concerned with preventing code running inside one environment from acquiring authority over the machine underneath it or neighboring workloads.

Agents make the problem wider because they are routinely given far more than an ordinary application process. A coding or security agent may have a shell, Python, package managers, compilers, Git, browsers, cloud CLIs, Kubernetes clients, source trees, build credentials, API tokens, MCP servers, container tooling, SSH clients, and the ability to generate and execute arbitrary code. None of those things requires a sandbox escape to become dangerous if the environment already has broad network reachability and usable credentials.

A process can remain fully contained inside its own PID namespace, mount namespace, filesystem, kernel, and memory while opening a TCP connection to a production system somewhere else. In the Gemini case, the network path appears to have worked normally. DNS resolved the destination. The kernel selected a route. Traffic left the workload. The upstream network forwarded it. TLS established a connection. The destination accepted the credentials that were presented. The agent did not need to cross the runtime boundary because the runtime already had a path to the destination.

Calling all of this a sandbox problem hides several different enforcement points. The compute boundary controls what happens if the agent gets root or compromises the kernel it is running on. The network controls which destinations it can reach. Identity controls what it can authenticate as once it gets there. The files, secrets, tokens, browser state, source code, SSH material, and cloud configuration placed inside the environment determine what authority it can steal or reuse. Every GitHub token, Kubernetes client, cloud API, MCP server, deployment tool, SSH client, browser session, or internal API exposed to the agent extends that authority outside the process itself.

A workload can therefore have strong kernel isolation and still have an enormous blast radius because it has unrestricted egress and a broadly scoped credential. The reverse is also possible. A workload may have tightly restricted egress and almost no credentials while sharing a host kernel with every other workload on the node. Those are different failure paths and they need different controls.

How Edera Zones Change the Compute Isolation Boundary

An Edera zone gives the workload its own Linux kernel inside a hardware-enforced isolation boundary. The agent is not running directly against the Kubernetes node kernel. If it gets root inside the zone, abuses namespaces, manipulates cgroups, walks its own /proc, modifies the filesystem, exploits its guest kernel, or otherwise gains full control of that environment, the host kernel is still outside the zone. Other zones do not share its kernel, process namespace, memory, or filesystem.

That changes the blast radius of a compromised agent considerably. Root inside an ordinary container is still operating against the same kernel used by the host and neighboring containers. Namespaces and capabilities reduce what the process can reach, but a kernel vulnerability that crosses those controls lands in the shared kernel. With an Edera zone, compromising the kernel inside the workload does not automatically mean compromising the host kernel.

That protection would have mattered if Gemini had escaped its execution environment and attempted to move into the evaluator’s host or other workloads. The public reporting describes a different path.

If Gemini had been placed inside an Edera zone with unrestricted outbound internet access, it would still have had unrestricted outbound internet access. Edera does not convert an allowed network route into a denied one simply because the workload has stronger compute isolation.

In Kubernetes, network policy is normally enforced by the CNI or another networking layer. Depending on the cluster, that may involve eBPF programs, iptables, nftables, routing policy, virtual interfaces, service proxies, or controls outside the node entirely. Kubernetes NetworkPolicy describes the policy, but the underlying networking implementation has to enforce it.

Standalone Edera environments have the same separation. Traffic from a zone crosses a Xen virtual interface into the host networking stack. The host can then use nftables or another policy mechanism to decide where that traffic may go. If the host forwards that traffic to the internet without restriction, the zone can reach the internet. If traffic from that interface is limited to an evaluation subnet, an internal proxy, a particular resolver, or a defined destination set, the agent sees only those destinations.

For a security agent, I would not start with unrestricted egress. If the simulated target occupies a known CIDR, allow that CIDR. If DNS is needed, expose the resolver required for the exercise. If package installation is necessary, use an internal mirror or artifact proxy or allow the exact package endpoints required. If the agent needs GitHub, decide whether it needs the whole public service, one organization, a read-only mirror, or a handful of repositories.

A security agent is deliberately built to enumerate, probe, authenticate, exploit, and pivot. Giving that workload a default route to the public internet means relying on the model to decide which destinations are in scope. That is a policy decision the network can enforce much more reliably.

If the test target is 10.40.0.0/16, traffic to unrelated public address space can simply be denied. If the test genuinely needs selected external services, those destinations can be added. The node having a route to something does not mean every agent running on that node needs the same route.

The same applies inside the cluster. An agent operating against one namespace does not automatically need the Kubernetes API server, kubelet endpoints, node-local services, cloud metadata, every service CIDR, internal databases, and unrestricted internet access. Each of those routes adds something the agent can interact with without crossing the compute isolation boundary at all.

Why Leaked Credentials Bypass Runtime Isolation

The credential cases have to be handled separately because a runtime boundary does not make a valid credential invalid.

If an agent finds a bearer token and can reach the service that accepts it, the receiving service generally sees a valid bearer token. It does not know or care whether the request came from Gemini, curl, Python, a browser, or somebody typing commands manually. Possession of the credential is the authority.

Long-lived static credentials make this worse because they are portable. Once copied, they can be replayed from another process, another host, another cloud, or another network until they expire or somebody revokes them. The sandbox that originally contained the credential can disappear completely while the credential continues to work.

This is why I would rather build agent environments around workload identity than keep adding static secrets to them. SPIFFE and SPIRE provide one way to do that. A workload can receive an SVID after SPIRE attests the workload against configured selectors and registration policy. The identity can be short lived and associated with that workload rather than represented by a reusable string sitting in an environment variable or checked into a file.

We have been integrating SPIFFE and SPIRE with Edera zones so workloads can receive identity associated with the environment they are running in. The current implementation is still early, so this is not a claim that SPIFFE somehow fixes leaked credentials. It does give services a way to make authorization decisions based on workload identity instead of treating possession of a static token as sufficient proof.

If an agent finds somebody else’s credential in a public repository, the ideal outcome is that the credential either cannot be replayed from that environment or does not provide useful authority on its own. Short-lived workload credentials, mTLS, audience restrictions, tightly scoped authorization, and service-side policy all make that possible depending on the system.

Credential lifetime should also match the lifecycle of the agent environment. If a sandbox exists for twenty minutes to perform one task, handing it credentials that remain valid for six months makes very little sense. The same goes for scope. A GitHub token used to read one repository should not quietly grant administrative rights across an organization. A Kubernetes service account used to inspect one namespace should not carry cluster-wide permissions. A cloud credential issued for one service should not inherit the policy of a human administrator.

Why Root Inside the Sandbox Should Have Limited Value

I do not think a useful coding or security agent can depend on root inside the sandbox never happening. These workloads need to install packages, compile code, start processes, bind ports, run tests, create filesystems, launch browsers, start databases, modify system configuration, and occasionally exercise operating system behavior that was not anticipated when the environment was created.

Trying to make every one of those operations safe with an expanding collection of seccomp filters, Linux capability rules, namespace restrictions, privileged helpers, and exceptions becomes harder as the agent becomes more capable. I would rather give the agent significant freedom inside an environment where owning that environment does not also mean owning the platform.

The host runtime socket should not be mounted into the agent. The host filesystem should not be visible unless a specific workflow requires it. Cloud metadata should not be reachable simply because the node can reach it. Node credentials, kubelet credentials, cluster-admin kubeconfigs, SSH keys, CI tokens, and production service credentials should not be inherited from the machine running the sandbox.

Many container escapes become serious because the workload finds another piece of host authority after gaining control inside the container. A writable host mount exposes the host filesystem. A Docker or containerd socket can allow the process to create more privileged workloads. A broadly privileged Kubernetes token turns local code execution into control-plane access. A cloud metadata endpoint may provide cloud credentials. An unrestricted internal network may expose management systems that were never intended to be reachable from the workload.

None of those paths requires defeating hardware isolation if the authority has already been passed into the environment.

An Edera zone changes the compute side of this by putting another kernel boundary underneath the workload. Networking, mounts, credentials, devices, APIs, and external tools still have to be designed with the same care.

How Project Lunchbox Isolates Long-Lived AI Agent Workloads

Project Lunchbox deals with the kind of workload we are actually starting to run for agents. These are not always ordinary stateless application pods. They may live for hours, maintain a workspace, install software dynamically, run browsers, execute user-generated code, create child processes, modify their own environment, and need to be snapshotted, forked, discarded, or recreated as the agent works.

Running those environments with the Edera runtime gives each sandbox its own kernel instead of another set of namespaces on the Kubernetes node kernel. If the agent corrupts its userspace, destroys the filesystem, executes malicious code, or gains root inside the guest, the failure remains inside the zone unless another explicitly granted path lets it reach something outside.

Snapshotting and forking are useful here because the workspace state and the platform authority do not have to be the same thing. An agent can start from a known environment, install packages, build software, modify files, execute arbitrary code, and then throw the environment away. Another branch of the workflow can start from the same snapshot without those environments sharing a kernel or process namespace.

The networking and credential configuration still follows each environment. Forking a secure sandbox into ten copies while giving every copy unrestricted internet access and the same production token creates ten environments with the same authority. The lifecycle machinery does not make bad policy disappear.

How I Would Build This Evaluation Environment

For something like the Irregular test, I would assume from the beginning that the agent may misunderstand the target, follow a malicious instruction, execute hostile code, find a secret it was never supposed to find, or decide to connect to a system nobody intended it to reach.

The agent would run in its own hardware-isolated zone with its own kernel. The zone would not get ambient access to the host filesystem, host runtime sockets, node credentials, cloud metadata, or unrelated cluster services. Its network view would be constructed for the exercise instead of inherited from whatever the node happens to reach.

Egress would start being denied. The simulated company infrastructure would be explicitly allowed. DNS would go through the resolver intended for the test. Required source repositories, package mirrors, artifact stores, or external APIs would be permitted individually. If the exercise genuinely required public internet access, I would still prefer that traffic to pass through a controlled proxy or other enforcement point where destinations can be restricted and logged.

Credentials would exist for the duration and scope of the evaluation. Kubernetes access would use a service account restricted to the required resources and namespaces. Cloud access would use short-lived workload credentials with minimal policy. Repository credentials would be read only unless the exercise explicitly required writes. MCP servers would be reviewed based on the authority of the operations they expose, because an innocuous-looking tool call can represent a very privileged action behind the server.

I would also collect evidence at the enforcement points rather than depend on the agent transcript to explain what happened. DNS requests, denied connections, successful egress, SVID issuance, authentication failures, API authorization decisions, attempts to reach metadata endpoints, and traffic toward management networks give a much cleaner account of what the environment actually allowed.

If Gemini resolved the real company that shared the fictional company’s name, egress policy could prevent the connection from ever leaving the test environment. If it found a credential in a public repository, workload-bound authentication and authorization could prevent that credential from carrying useful authority into another environment. If it exploited the guest kernel, the host would still sit behind the zone boundary. If it destroyed the environment entirely, the environment could be discarded and rebuilt.

I do not want the security of an agent platform to depend on the model remembering that a company is fictional, correctly deciding whether a credential is in scope, or voluntarily refusing to connect to an address the infrastructure already allows it to reach.

Gemini appears to have reached real systems because the infrastructure gave it a path to them. Edera could have provided the compute isolation around that agent, but containing this class of failure also requires the network, identity, credential, data, and tool boundaries to be enforced independently. If one of those is left wide open, the agent does not need to escape the sandbox to do damage somewhere else.