Agents now produce work faster than enterprise infrastructure can absorb it. The answer is not to abandon Kubernetes. It is to finish it.

Visualizing hardware-level isolation, secure sandboxing, and data flows within a massive Kubernetes environment\u200a—\u200aImage by Gemini\u00a0(AI)

Visualizing hardware-level isolation, secure sandboxing, and data flows within a massive Kubernetes environment — Image by Gemini (AI)

Oct 31, 2026 · Madkat Omega

When Git Cannot Keep Up

In May 2026, Anthropic merged about 2,500 code changes a day. By September, it merged more than 30,000. Writing code stopped being the constraint, and everything built for human speed became the constraint instead.

That is the signal every board should take from this year. Autonomous agents now generate work faster than source control, CI, security review and audit can absorb it. Organizations that rebuild those systems for machine speed will compound their AI investment; the rest will throttle it at the infrastructure layer without noticing.

This article makes one recommendation. Standardize on Kubernetes as the single production platform for agentic work, from research to robotics to operations, and harden it with a small set of open-source security tools built for exactly this problem. The rest of the piece explains why that bet is sound, what it unlocks, and what it will not fix.

Lesson one: Anthropic rebuilt the plumbing, not the ambition

When Git cracked under agent load, Anthropic did not slow its agents down. It rebuilt source control around a new assumption: almost every client is an agent or a CI job, and those are always online.

The numbers explain why. Anthropic reported roughly 25 million CI checkouts a day against a monorepo with nearly 100 GB of main-branch history, and at its peak it ran several hundred internal Git mirrors that kept drifting behind. A team of seven built a replacement called Scion, plus a code review tool called Antique, and moved the entire monorepo in five months.

Scion’s design comes down to a few moves:

  • The server holds the truth. Commits, merges, rebases, history and blame run server-side; clients stay thin.
  • Everything is an API. Many jobs query what they need without ever checking out a repository.
  • Fetch only what you touch. Checkouts are sparse and virtualized, served through tiered caches of immutable objects.

Anthropic reports cache hit rates above 99% at every tier, an infrastructure footprint 200 times smaller than its old mirrors, checkouts in seconds instead of minutes, and a 25% CI CPU capacity win. These are company-reported figures for one unusual workload, and Anthropic itself says Scion is not a general Git replacement. After publication, Anthropic also added credit to Meta’s open-source Mononoke server for many of the underlying ideas.

The human side matters as much as the architecture. Anthropic’s engineers reviewed the intent of each change rather than every line, and very often their job was to tell Claude “no.” They backed that judgment with machines: simulations of every non-trivial infrastructure interaction they had seen, plus fuzzing and rate limiting.

Why this belongs in a security conversation. Scion’s three principles map directly onto agent security:

  1. Server-side truth becomes out-of-band enforcement. The decision about what an agent may do lives outside the agent, where the agent cannot edit it.
  2. Thin clients become least privilege. An agent holds only the identity and access its current task needs, fetched on demand and expiring on its own.
  3. Executable rules replace human line-by-line review. Humans judge intent; policy, simulation and kernel enforcement check everything else at machine speed.

Anthropic expects this class of problem to become commonplace across the industry within six to 12 months. The question for a board is not whether to build a Scion. It is whether your platform will hit the same wall in security and operations, and what you will have in place when it does.

Is Kubernetes the wrong tool?

In a widely shared Level Up Coding essay, Noah Byteforge argues that agents do not fit the model Kubernetes was designed for. His case is worth taking seriously, because most of it is correct.

An agent is a single, stateful, isolated instance, not a replicated service. It sits idle for unpredictable stretches while it waits on tools, models, other agents or humans. Some agents must start in milliseconds; others run for weeks. Deployments assume interchangeable replicas, and StatefulSets assume numbered, stable sets. Neither was built for a mostly idle singleton that runs untrusted code.

Where the argument goes wrong is the conclusion. Kubernetes is not a fixed set of workload types. It is an extensible control plane: custom resources, controllers, pluggable runtimes and admission hooks exist precisely so new workload shapes can be added without replacing the engine.

The Kubernetes community has already done this for agents. In March 2026, SIG Apps introduced Agent Sandbox, a declarative API for isolated, stateful, singleton workloads. It runs each sandbox under a strong isolation runtime such as gVisor or Kata Containers, scales idle agents to zero and resumes them where they left off, and gives every agent a stable identity. Because a fresh pod adds about a second of startup overhead, a warm-pool extension hands out pre-provisioned sandboxes on demand.

The market has made the same bet. CNCF’s 2025 annual survey found 82% of container users run Kubernetes in production, and 66% of organizations hosting generative AI models use it for some or all of their inference. Your AI estate is likely landing there already.

Read generously, Byteforge’s real point is narrower and sharper: the old blueprints do not transfer. A cluster secured for stateless web services, with shared kernels, static tokens and IP-based firewalls, is not safe for thousands of agents reading untrusted content and executing generated code. That is the gap this article closes. Kubernetes is the reconciliation engine; it was never meant to be the whole security model.

Five chokepoints that stall agentic AI in production

Most enterprise agent programs do not stall on model quality. They stall when security, compliance and operations cannot prove the agents are contained, so pilots never reach production. Five chokepoints account for most of that friction.

These map closely to the industry’s own risk catalog. The OWASP Top 10 for Agentic Applications, published in December 2025, opens with agent goal hijack and tool misuse and closes with rogue agents. Every one of those risks is cheaper to contain at the platform than to chase agent by agent.

The agent-ready platform: five open-source layers

The fix is not a new platform. It is five layers added to the Kubernetes you already run, each enforced outside the agent it governs, which is Scion’s lesson applied to security.

  • Identity and delegation: Teleport Machine & Workload Identity. Each agent receives a short-lived certificate scoped to its task instead of a static key or a borrowed human login. Teleport’s identities are SPIFFE-compatible, it supports dual authorization for high-impact access, and its locks can cut off a role or bot immediately. SPIFFE/SPIRE is the fully open CNCF alternative.
  • Admission and policy: Kyverno. Every agent pod is checked before it starts. Policy strips privileges, blocks host access, and requires a sandboxed runtime and an identity, so no developer has to remember to configure them. This is the external admission control point that ties the stack together.
  • Agent runtime: Kubernetes plus Agent Sandbox. Agents run as sandboxes under gVisor, a user-space kernel that sits between agent code and the host, or Kata Containers, a lightweight virtual machine with its own kernel. Warm pools give instant starts; idle agents scale to zero and resume with their state.
  • Network: Cilium. Policy follows workload identity rather than IP addresses. Egress is restricted to approved domain names, so an agent can reach the APIs its task needs and nothing else. Pod-to-pod traffic can be encrypted, and Hubble records every flow.
  • Kernel monitoring and enforcement: Tetragon. Using eBPF, Tetragon records process, file and network activity from inside the kernel, beneath any agent. It can also enforce: a policy can kill a process or override a system call’s result in-line. Because the record is written below the agent and shipped off-cluster, a compromised agent cannot erase its own trail.

One agent task, end to end

Follow a single task through the platform and every control shows up exactly once, at the moment it matters. The agent never holds a standing credential, never shares a kernel with its neighbors, and never writes its own audit trail.

Two moments in this flow carry most of the business value. At step 5, an agent that has been tricked into contacting an unknown server is simply dropped at the network layer, and the attempt is logged. At step 6, anything irreversible (a production migration, a payment, a fleet-wide robot update) waits for a person, and the record shows which person said yes.

The kill switch: stopping the whole system at once

Byteforge is right that pausing one agent is not enough. When a multi-agent system misbehaves, the organization needs to stop all of it, revoke its authority and keep the evidence. On this platform that is one rehearsed runbook firing four independent controls.

The redundancy is deliberate. Teleport locks terminate active sessions for the targeted roles and bots and reject new requests; Cilium removes network reach even from processes that still hold a valid credential; Kyverno stops replacements from starting; and suspended sandboxes keep their state for investigators. Short certificate lifetimes put a hard ceiling on any exposure from credentials issued before the switch was thrown.

One platform from research to robotics to operations

The strongest reason to double down on Kubernetes is that it lets one control model govern every place agents will work. Fragmenting into a bespoke runtime per domain multiplies the security reviews, the audit formats and the people who understand each one.

  • Research. Agents run long experiment loops, launch training and evaluation jobs, and write analysis code. They need GPU scheduling, mostly idle sandboxes that resume instantly, and strict isolation for generated code. Kubernetes already schedules most of this work; the agent layer simply inherits it.
  • Robotics. Simulation farms run in the data center while fleets run at the edge. KubeEdge, a CNCF graduated project since October 2024, extends Kubernetes orchestration to edge devices and lists robotics among its production use cases. The same identity and policy model that governs a lab agent can govern what a fleet update agent may push to a robot.
  • Operations. Agents that open tickets, change configuration, run migrations or respond to incidents touch systems of record. Here the identity, approval and audit layers matter most, and they are the same layers already proven in research.

The payoff is compounding. Each policy, runbook and audit query written once applies everywhere, so the cost of governing the next agent use case falls instead of rising.

Governance that Becomes Velocity

The return on this platform is not a security line item. It is the number of agent use cases the company can safely run at once, and how fast each new one reaches production.

The maturity signals are real. Kyverno, the policy engine at the center of this design, reached CNCF graduated status in March 2026, the foundation’s highest tier (CNCF). The investment is primarily people: a platform security team that owns these layers as a product for every agent builder in the company.

What this does not solve

It is important to remember what we are building. This platform contains damage; it does not make agents themselves trustworthy.

  • Intent is still hard to read. An agent working hard on a difficult task can look exactly like a compromised one: repeated access attempts, escalating permission requests, work outside its usual scope. Kernel telemetry tells you precisely what happened, not why.
  • Injection still works inside the fence. A manipulated agent can misuse any permission it legitimately holds. The defense is to scope each task so that everything it is allowed to do is survivable, and to require human approval for irreversible actions.
  • The tools have costs. gVisor trades some system-call performance and compatibility for isolation; Kata adds virtual machine overhead; eBPF tooling depends on kernel versions. Each needs testing against real workloads.
  • Some pieces are young. Agent Sandbox is still in active development, and the integration between admission control and the identity layer is something your team builds, not a product you buy.
  • The case study is vendor-reported. Anthropic’s Scion figures come from Anthropic, describe an extreme workload, and should be read as direction, not benchmark.
  • Check the identity layer’s license. Teleport’s source code is AGPLv3, but since version 16 its prebuilt Community Edition binaries are free for commercial use only at companies under 100 employees and $10 million in annual revenue; larger firms need a commercial agreement or a self-built deployment. SPIFFE/SPIRE avoids that question at the cost of more integration work.

None of these argue for waiting. They argue for treating the platform as a product with an owner, a roadmap and regular drills.

Anthropic’s lesson is that the bottleneck never disappears; it moves. Companies that move their security and operations to machine speed now will be the ones whose agents are allowed to do real work next year.

A companion project plan for platform engineers, with a reading and study path for each layer is also available. Leave a comment if interested or read the long version over on my blog https://madkatomega.blog

What happens when the tool you built to help starts making decisions in production? Some of the worst AI coding failures so far weren’t hacks. They were helpful agents doing exactly what they were allowed to do. I looked into some real world incidents in The Bounded Agent, and wrote about what it takes to give an agent real work without giving it the keys to everything. It’s a good companion to this piece if you want to know how to build those agents the right way.

Works cited

The agent-scale infrastructure case

Kubernetes and the platform

The security fabric