Harnesses and Sandboxes Will Keep Multiplying. Your Governance Should Not.

Two pieces of infrastructure now sit under almost every agent that does real work. The harness drives the agent: it runs the model loop, picks the tools, and holds the keys. The sandbox contains it: it decides what the agent's code can touch on the machine it runs on. Together they write and run code, call models, and act on your company's APIs, often hundreds at a time, with no person reading each step.

Both are multiplying, and both are good at what they do. Neither one was built to govern what the agent does next.

The harness drives the agent. The sandbox contains it. Governance belongs at the one place every agent shares: the way out.

Still on the Laptop, Increasingly Everywhere Else

Many agents still run on a developer's laptop, as coding assistants, with a person in the loop who reads every suggestion before anything happens. That is not going away. But more and more of the work now runs on its own, in a harness, inside a sandbox.

This is not a migration from one to the other. It is a continuum, and every point on it is growing.

The same company has a developer pairing with an assistant in an editor, a platform team running framework agents on Kubernetes, a business unit that bought a platform with its own harness and its own sandbox, and a model vendor hosting agents on its own stack.

In an earlier post I argued that the agent framework wars are over and everyone won: multi-framework is the destination. It's not a temporary state. The same is now true of harnesses and sandboxes together. Harnesses come from the model labs, the agent frameworks, the cloud providers, and the coding tools your developers already use. Sandboxes come from cloud platforms, from Kubernetes, from the chip vendors, from the model labs themselves, and from developers' own machines. New ones are announced all the time, and every one of them is good at something.

Every Harness and Every Sandbox Brings Its Own Rulebook

Each one also has its own idea of how to keep an agent in line.

Harnesses govern from the inside. Each one decides which tools an agent may call, where its keys are kept, and what gets logged, and each one decides differently. A permission written for one harness means nothing to the next.

Sandboxes govern from the outside. One sandbox manages secrets for you and lets allow rules override deny rules. Another works the other way around: deny always wins, so the same policy means two different things depending on where it runs. A third writes policy in YAML and enforces it with OPA. And most sandboxes let traffic out by default. In one public comparison of 38 sandboxes on GitHub, awesome-ai-coding-sandboxes (August 2026), only 7 deny outbound traffic unless you say otherwise.

None of this is wrong. Each one enforces what it can see. A harness sees the agent's loop. A sandbox sees the machine. Neither one sees the whole call: which system it reaches, on whose authority, with which key, and at what cost.

Fragmentation Is Where the Gaps Hide

The trouble starts when you run more than one of each, and you will. Your developers use one harness on their laptops and another in the cloud. Your platform team builds internal agents on a framework and runs them on Kubernetes. A business unit buys a platform that brings its own harness and its own sandbox. A model vendor hosts agents on a stack of its own. As harnesses and sandboxes multiply, so do agents: dozens, then hundreds, across every combination.

Each combination comes with its own rulebook, its own way of handling keys, its own log, and its own idea of what "allowed" means. That is fragmentation. And fragmentation is where the gaps hide.

After an incident, someone will ask four questions:

1. Reach. What could this agent reach?
2. Credentials. Whose keys did it use?
3. Cost. What did it cost?
4. Approval. Who approved it?

With four different setups, you get four answers to each. Four allowlists, written by four teams. Keys copied into four kinds of environments. Four budgets, if there are budgets at all. And four logs, some of which disappear with the sandbox that wrote them.

This is already happening. This year, two model labs, Anthropic and OpenAI, described agents that reached systems they should not have. Not by breaking the sandbox, but through network paths that were left open, or explicitly allowed. And in an Okta survey of security leaders in July 2026, only about a quarter said they could cut off a rogue agent within minutes. Now multiply that by every harness and every sandbox you run.

You Cannot Standardize the Harness or the Sandbox. You Can Govern the Way Out.

The instinct after an incident is to standardize: one harness, one sandbox, one team that approves them. It will not hold. Teams pick what fits the job, and they should. The coding tool that makes a developer twice as fast, the framework the platform team already knows, and the platform a business unit bought for its workflow are all good decisions on their own terms. A policy that depends on everyone choosing the same harness and the same sandbox is a policy of wishful thinking.

So look at what they all have in common instead. Whatever harness drives the agent, and whatever sandbox contains it, every model call, every tool call, and every API call has to leave.

They all share one way out.

That is where governance belongs. Not another harness. Not another sandbox. One door, where every agent's outbound calls are governed the same way, whatever it is built with and wherever it runs. The sandbox lets the agent reach that door and nothing else, and package registries and source control can go through the same door or sit on a short, reviewed list of their own. Everything the harness does on the agent's behalf outside the box becomes a call through the door, so one configuration governs every combination.

In the harness and platform post we drew the line between the harness and the platform, and listed a single egress point as part of the minimum platform layer for any team starting with agents. Sandboxes make that egress point easier to enforce, not harder: they can already control what leaves the box. Point that control at one door, and the door can decide the rest.

One Door, One Answer to Each Question

This is what Traefik Hub was built for. Its Triple Gate Pattern puts an AI Gateway in front of models, an MCP Gateway in front of tools, and an API Gateway in front of your APIs, under one set of policies. Put it at the way out, and each of the four questions gets a single answer, the same answer whatever the harness and whatever the sandbox.

Reach: policy is written about the task, not the harness or the machine. Each call carries a short-lived identity naming the agent and its task, and policy decides from the task. A support agent can issue a $50 refund. A $5,000 refund is refused at the door. A code-review agent, running the very same code, cannot refund anything at all. Changing what a support agent may do is a policy change, not a harness change and not a sandbox rebuild.

Credentials: the agent never holds the key. Traefik Hub adds the provider key on the way out. There is no model key in the harness, the sandbox, or the environment to leak, and a tricked agent has nothing to print. At most the agent holds a short-lived token that works only at the door, and on runtimes that can attach it outside the sandbox, not even that.

Cost: a cap for every agent, checked on every request. Give each agent a dollar cap on its model calls, priced from Traefik Hub's price list. Traefik Hub checks it on every request, not in a report the next morning. Calls already in flight can finish; once the budget is spent, the next call is refused, so a runaway loop ends as a refused call. Tools and APIs get rate limits.

Approval: who the agent acted for, on whose authority, on the record. The token on every call comes from your identity provider, and with token exchange it names the user who delegated the task as well as the agent. Traefik never mints authority; it checks it, on every call. And every call lands in a tamper-evident log with signed checkpoints, outside the sandbox, where the agent cannot reach it and where it outlasts the sandbox that made the call.

The harness drives the agent. The sandbox contains it. Traefik Hub decides what it may do on the way out.

Two Runtimes, One Policy, No Model Keys in the Box

Take two very different sandbox runtimes, E2B microVMs and NVIDIA OpenShell™. Run the same agent in each, let each sandbox reach only Traefik Hub, and connect one identity provider:

• Policy follows the task, not the code. Agents running the same code get different answers at the door, because each token names a different task.
• No model key enters any sandbox. Traefik Hub adds the key on the way out, so there is nothing in a sandbox's files or environment to leak.
• The runtime changes and the governance does not. The same policy and the same identity provider give an agent the same decisions on either runtime.
• The door is the only way out. Each sandbox can reach Traefik Hub and nothing else, so a direct call to a model provider fails.
• Every call leaves a record. Each call is logged with its agent, task, and decision, outside the sandbox that made it.

Swap the runtime, and the governance stays where it is: at the door. For a step-by-step deep dive on one of these runtimes, see The Governance Playbook for NVIDIA OpenShell™.

Nothing in the Agent Changes

Platform teams get freedom. Pick each harness and each sandbox for what it is best at, and change your mind later, without rewriting policy or building yet another custom proxy. Developers keep the tools they already use.

Security teams get one place to govern from. One allowlist instead of one per setup. No model keys in any harness or sandbox. One policy to change, and every agent follows. One audit log that outlasts every sandbox.

Getting there is three steps:

1. Point your agents' egress at Traefik Hub. Make it the one address the sandbox can reach.
2. Connect your identity provider, so each task carries a short-lived identity naming the user, the agent, and the task.
3. Write policy about the work your agents do, not about the harness they are built with or the machine they run on.

No new harness, no new sandbox, and no change to the agent.

The Question for Every Platform Leader

The question is not which harness or which sandbox wins. It is where governance lives when both keep changing.

Harnesses and sandboxes are going to keep multiplying, and that is fine. Let them. Your governance does not have to fragment along with them. Build your agents with any harness. Run them in any sandbox. Let them all go out through one door, and govern every call there.

To see it end to end, watch our video Governed Agent Harnesses and Sandboxes with Traefik Hub below, or talk to our team about running it against your own harnesses and sandboxes.

Frequently Asked Questions

Our harness already has guardrails and an auth plugin. Why is that not enough?

It works for one harness. The problem surfaces when the second and third arrive, built by different teams, each with its own plugin configured differently, and each running in a different sandbox. At that point there is no single place to answer which agents may call a given system. Keep the harness's guardrails for what happens inside the loop, and enforce what leaves at one door keyed on the agent's identity and task.

My sandbox already has egress rules. Why is that not enough?

An egress rule decides where traffic may go. It cannot decide what the agent may do when it gets there. A rule can allow a payments API; it cannot tell a $50 refund from a $5,000 one, or a support agent from a code-review agent running the same image. Keep the sandbox's egress rule, and point it at one door that can make those decisions.

Does this mean we have to standardize on one harness or one sandbox?

No. That is the point. Standardizing harnesses and sandboxes is a multi-team, multi-quarter negotiation that the market will keep reopening. Standardizing the way out is one infrastructure decision, applied uniformly. Once the door is consistent, consolidating harnesses or sandboxes becomes optional rather than urgent.

What about coding assistants on developers' laptops?

They are part of the same continuum, and the question is the same: which calls leave, and who decides. On a laptop there is often no sandbox to force calls through the door, so endpoint or network controls do that job. Once routed, a laptop's model, tool, and API calls get the same policy, the same handling of keys, and the same record as an agent in a cloud sandbox.

Does putting governance at the door add latency?

A little: one extra hop per call, small next to the model round trip behind it. The latency that matters in an agent comes from the model and the harness's loop, and that is where to optimize it. The door is built for correctness and for a record you can trust.

Is this another gateway to run?

It is the gateway you already need for models, tools, and APIs, placed where every agent's calls already pass. The alternative is not zero gateways. It is one partial gateway per harness and per sandbox, each configured differently.

Which harnesses and sandboxes does this work with?

The pattern needs very little from either. From the harness, it needs the agent's calls to go to an address you choose, which harnesses commonly support through a base URL setting. From the sandbox, it needs outbound traffic limited to one address, and ideally a way to attach the agent's token outside the sandbox.

NVIDIA and NVIDIA OpenShell are trademarks and/or registered trademarks of NVIDIA Corporation in the U.S. and other countries. Traefik and Traefik Hub are trademarks or registered trademarks of Traefik Labs. Kubernetes and OPA are trademarks or registered trademarks of The Linux Foundation. Anthropic, OpenAI, Okta, E2B, and GitHub are trademarks or registered trademarks of their respective owners. Other company and product names may be trademarks of the respective companies with which they are associated.