--- title: "Agents don't fit Kubernetes, and three more problems still open" description: Katelyn Lesse, head of platform at Anthropic, lists the engineering problems multiagent systems create. Infrastructure built for stateless pods, identity and consent for agents acting on a human's behalf, isolation when thousands of agents run untrusted code, and a kill switch that can stop a whole system at once. Notes on her article and her sandboxing post, and where my own fleet stands on each. date: 2026-10-26 tags: AI agents, multiagent systems, agent identity, agent security, infrastructure --- Kubernetes was built for stateless, replicated apps. An agent is the opposite: one isolated, stateful instance that sits idle for hours, then wakes up and waits on a tool, a model or a person. That mismatch is the first of four problems Katelyn Lesse, head of platform at Anthropic, says software engineers have to solve before multiagent systems can be trusted with serious work. The other three: who an agent is and what it may do, how far a compromised agent's damage spreads, and how to stop a whole system at once. Her [article](https://x.com/i/article/2114537761030230016) went up on X on October 26. It's short, and it opens on the engineers she sees going through an identity crisis as the job changes. Her answer isn't comfort. It's a list of work. I run 17 agents on a Mac mini and I'm moving one of them into a sandbox on an old Dell, so at the end I hold my own fleet against her four. ## From a chat to thousands of agents Her account of how we got here is quick. Agents started as chats with a human in the loop. Then models got better at running longer on harder problems, and agentic systems moved to the cloud. Then models got better at working together, and people built basic multiagent systems: an orchestrator that spawns subagents for a task, or agents given jobs other than executing, "like grading or advising or dreaming". Now some teams are building systems for serious research, discovery and hardware design. Her picture is thousands of agents, persistently working towards an outcome. That's where the new problems show up, and she names four. Infrastructure for burstier workloads. Authentication and authorization, so agents can be identified, work together, take the actions they should and be kept from the ones they shouldn't. Security and isolation for untrusted code and content. And monitoring, with the ability to stop a system "when it's veering into the wrong territory". Models will keep getting better, she says, and these systems will become really powerful. Whether the world trusts that power to cure diseases instead of causing harm is on the engineers who build the plumbing.

  1. 1A chat

    A human in the loop, one question at a time

  2. 2Long runs

    Harder problems, longer runs, so the agent moves to the cloud

  3. 3Orchestrators

    Subagents spawned per task; others grade, advise or dream

  4. 4Thousands

    Persistent agents on research, discovery and hardware design

The problems she namesInfrastructureIdentity and accessSecurity and isolationMonitoring and halting

Her four stages, drawn as agents: the yellow square is the human, the blue ones are agents. The grid in the last stage stands for thousands.
## Agents don't fit Kubernetes The software industry has been building on Kubernetes, which was designed for stateless, replicated apps, or for stable, numbered sets of stateful pods. Agents are "isolated, stateful, single-instance workloads". They go idle for arbitrary stretches between bits of work. They spend most of their life waiting: on tools, on model inference, on other agents, on a human. Each of those shapes wants something different from the machine underneath. Some workloads need fast startup. Some need to stop burning compute while they wait. Some need a crazy scale. She points at AI infra companies building new filesystems and sandboxing offerings, and at the Google team building Agent Substrate as a new runtime, and says there's a ton left to figure out. My fleet is a small version of the idle problem. Seventeen OpenClaw agents live on one Mac mini, each behind its own Telegram bot, and most of them do nothing until a message arrives. Forge, my open-source contribution agent, is the other shape: a worker starts for one issue, clones a repository, runs its tests and is gone. Neither looks like a replica set.

What Kubernetes was built for

Replicas

Stateless, replicated, interchangeable

Or a stable, numbered set of stateful pods

Always on

vs

What an agent is

One instance

Isolated, stateful, single instance

Idle for arbitrary stretches

Waiting on tools, the model, other agents, a human

One agent's dayworkwaiting

She namesAI infra companies building new filesystems and sandboxing offerings, and the Google team building Agent Substrate as a new runtime.

The day is schematic: she gives no durations, only the shape. The square is where the agent is right now.
## Who did that, you or your agent Authentication, identifying the agent that took an action, is the easier half. The microservices world already built and hardened the pieces: workload identity, short-lived certificates instead of static keys. People are starting to apply them to agents. Authorization is "much more wide open". Most agents today work on behalf of a human and use that human's identity and credentials to reach systems and take actions. The first problem hides inside that sentence: on the receiving system, nothing says whether the human or the agent did it. The deeper one is consent. If a multiagent system works for weeks, how does the human meaningfully approve what their agent can do? Auto-approval of tool calls helps, she says, but at scale the permissioning has to go deeper than that. Then the part even less solved: agents with their own identity, and agents working together. How does an agent trust another agent that asked it for something? I know the first problem from the receiving end. Every pull request my agents open is authored by me, as far as GitHub knows. In my own repositories, the one trace that a session did the work is a session id in an HTML comment in the PR body. And my first try at scoping what an agent may do taught me how thin that layer is: a deny rule in my gateway config matched nothing for a month, and an agent that was supposed to be locked out of my finance app was offered all 13 of its tools. I wrote that up in the [note on AI coworkers in Slack](/notes/ai-coworkers-slack-agent-identity.html), where MintMCP gives every agent an identity of its own.

Audit logauthor: meme, or the agent?

  1. 1WhoThe action lands under the human's identity. Nothing says the agent did it.
  2. 2ConsentA system that works for weeks: how does the human meaningfully approve what it may do?
  3. 3IdentityAgents with an identity of their own. Even less solved.
  4. 4TrustHow does an agent trust another agent that asked it for something?

The easier halfAuthentication can borrow workload identity and short-lived certificates from microservices.

The chain is every agent I run today. The four rows are her list of what authorization still has to answer.
## One compromised agent is a blast radius Over the past few months, she writes, and especially the past couple of weeks, vulnerabilities have surfaced faster than the industry can patch them, much of it in core software that many systems rely on. Put thousands of persistent agents on top of that software, writing untrusted code and reading untrusted content, and every unpatched vulnerability gets more dangerous. Her ask to engineers is to get creative about hardening the kernels, browsers, runtimes and common libraries those agents run on. Multiagent systems add a twist. A compromised agent can pass injected instructions to the agents it works with, and those instructions can end up in memory, where future agents trust them by accident. So the question becomes blast radius: when the first agent falls, how much of the system is at risk? Her answer is isolation. Agents should take their actions from strongly isolated, sandboxed execution environments. She wrote the longer version in September, in [Secure agents: architecture and sandboxing](https://www.katelynlesse.com/blog/secure-agents-architecture-and-sandboxing), and it's the most practical page on the subject I've read. Split the brain from the hands. The harness, the session state and the credentials live outside the sandbox, on infrastructure you trust, and the sandbox is just a tool the agent uses to run code. When code in the sandbox needs an external service, the request leaves through an egress proxy that adds the credential on the way out, scoped to that one destination. The sandbox can hold a placeholder that the proxy swaps for the real key. Her line on the alternative, everything in one box: "Your kill switch is basically inside the thing you're trying to kill." The sandbox itself then needs four settings. Isolation, from weakest to strongest: containers, which share the host kernel and shouldn't be a security boundary for untrusted code; a user-space kernel like gVisor; microVMs like Firecracker, each with its own kernel behind the CPU's virtualization hardware, her pick for most teams; and full VMs or dedicated hosts for regulated work. Sandboxes should be ephemeral, "cattle instead of pets", with hard limits on time and resources. Egress should deny by default behind a proxy, with an allowlist of hosts and HTTP methods and DNS closed; install the dependencies at the start of the session, then lock the network before the agent starts working. And the logs of tool calls, commands and network access go somewhere the sandbox can't reach, next to a kill switch that works mid-session. That's close to what I built for Forge's workers in my [sandbox inside the sandbox](/notes/openshell-sandbox-inside-a-sandbox.html): the key inside the sandbox is a placeholder that OpenShell's proxy swaps on the way out, and the workers get a second fence with one door, a relay with a host allowlist.

Agents sharing one environment

It spreads

Injected instructions pass to its peers

They end up in memory for future agents

vs

Each agent in its own sandbox

It stays one

The blast radius is one agent

The proxy adds the key on the way out, one destination at a time

Her four isolation levels, weakest to strongest

  1. Containers

    Share the host kernel. Not a boundary for untrusted code.

  2. User-space kernel

    gVisor: its own kernel, in software.

  3. MicroVMs

    Firecracker: its own kernel behind the CPU's virtualization. Her pick.

  4. Full VMs

    Or dedicated hosts, for regulated work.

Her ruleSplit the brain from the hands. "Your kill switch is basically inside the thing you're trying to kill."

The spread is her description drawn, not an incident. The ladder is from her September post; the heights only order the four levels.
## A kill switch outside the thing it kills The last set is the one she calls hard. We need to know these systems are heading in a positive direction, and to catch them and cut them off when they're not. Concretely: OpenTelemetry tracing across agents, with the guarantee that an agent can never modify its own trace or another agent's. And kill switches that monitoring can trigger, that truly stop the whole system at once and cut off its credentials. The hard part isn't the switch. It's knowing when to hit it. "Well-intentioned persistence to solve a problem can look a lot like maliciousness." Her example: repeated attempts to reach a domain that isn't on the allowlist. I've seen that ambiguity from both sides. Forge's workers run strangers' install scripts and test suites behind a relay that allows a short list of hosts. If a test fetches a fixture from a host I never listed, the relay refuses it, and refuses the retry. From outside, that worker and an exfiltration attempt write the same log line. The other side: when I stopped using Hermes this summer, my kill switch was revoking its Telegram tokens. By September 14 both of its gateways were crash-looping, retrying tokens that no longer worked. Persistence, not malice, and from the logs alone you couldn't tell.

The ambiguous case

One readingA test suite fetching a fixture from a host nobody listed

The otherAn agent trying to send something out

Her words"Well-intentioned persistence to solve a problem can look a lot like maliciousness."

The spans and the five retries are schematic. The two readings under them are the whole problem: same log, different story.
## Where my fleet stands on the four She closes the article for the engineers who think their skills won't matter: these problems are wide open, and "you and your skills can be the difference". So, honestly, mine. Infrastructure: one Mac mini, 17 agents, idle most of the day. No scheduler, no fast start, nothing to scale. It works because the fleet is small. Identity: everything runs as me. The agents use my accounts, and their pull requests are mine on GitHub. Two of them, Nova and Spark, have their own Slack accounts in a workspace just for agents, which is the first piece of an identity. Agent-to-agent trust hasn't come up yet: Telegram doesn't deliver one bot's messages to another, so my agents can't talk to each other there. Isolation: partial. Forge's workers run in srt, a sandbox runtime on macOS Seatbelt, and on the Dell they'll run in a Landlock cage inside OpenShell, with the keys outside. Every other agent runs its tools on the host, which is OpenClaw's default and the empty row in my [note on NVIDIA's five parts](/notes/hope-isnt-security-enterprise-agents.html). Monitoring and halting: the weakest row. Meterlex prices every session, but that's a meter, not a trace, and nothing joins one agent's actions to another's. There is no kill switch. Stopping an agent means stopping its gateway or revoking a token, by hand. Forge has a budget of $5 a day, and its Hermes profile on the Dell has a hook that sees every tool call before it runs. That's the closest thing I have to a switch.
  1. InfraOne Mac mini, 17 agents, idle most of the day. No scheduler, nothing to scaleOne mini
  2. IdentityEverything runs as me; the PRs are mine on GitHub. Nova and Spark have Slack accounts of their ownMine
  3. IsolationForge's workers in srt, then a Landlock cage in OpenShell with the keys outside. Everyone else on the hostPartly
  4. HaltingMeterlex meters, nothing traces. No switch: a gateway stopped or a token revoked, by handNot yet

Weakest rowThere is no switch. Forge's $5 a day and a tool-call hook are the closest I have.

My own setup on October 26, read against her list. The last row is the one I'd fail first.
## Read it Her article is a few screens long, and it's written for engineers rather than for buyers. Read it for the four headings, then her September post for the sandbox settings, because that one you can act on this week. If you want more: - [The new set of problems for engineers to solve](https://x.com/i/article/2114537761030230016), Katelyn Lesse, October 26, 2026 - [Secure agents: architecture and sandboxing](https://www.katelynlesse.com/blog/secure-agents-architecture-and-sandboxing), her September post on splitting the brain from the hands - [Hope isn't security: the five parts of an enterprise agent](/notes/hope-isnt-security-enterprise-agents.html), NVIDIA's version of the same list, with OpenShell - [A sandbox inside the sandbox](/notes/openshell-sandbox-inside-a-sandbox.html), Forge's workers behind a relay in OpenShell - [AI coworkers in Slack need their own identity](/notes/ai-coworkers-slack-agent-identity.html), MintMCP's agents, each its own principal - [What breaks when an AI agent runs a real business](/notes/what-breaks-when-an-agent-runs-a-business.html), four months of an agent persisting at the wrong thing If you run more than one agent, pick the row you'd fail first and tell me which. Mine is the kill switch, and I'd like to hear from anyone who has built one that stops a whole fleet and cuts its credentials in one move.