Approving the feature leaves many decisions unresolved: Which credentials can the agent use? Where can it send source code? How much can it spend, and when should it stop trying? On a laptop, those decisions may be buried in local configuration and the engineer’s existing credentials.
An engineer who has to approve every command is still doing the supervision the agent was supposed to reduce. The company needs those decisions settled and enforced before the engineer steps away.
We already version and review our build pipelines and infrastructure definitions. Agent environments and operating rules need the same treatment. The runtime image, dependencies, access policies and limits should be defined in code, reviewed and applied consistently. That makes agent execution part of the software delivery process instead of another workflow that depends on one engineer’s laptop. Kubernetes gives platform teams a way to provision those environments and enforce their policies.
Give the Agent a Place to Work
The engineer reviews the plan, approves it and hands the session to a managed sandbox provisioned from the reviewed environment definition. The sandbox receives the required project files, and the agent can continue after the engineer disconnects.
For this assignment, the agent runs under a dedicated workload identity, separate from the engineer’s login. A Kubernetes service account provides its cluster identity; access to repositories and external tools requires scoped credentials or configured trust relationships. The platform grants only the permissions needed for the repository, test environment and tools, uses short-lived credentials where supported, and records which engineer approved the run.
Network policies restrict incoming and outgoing traffic, while additional egress controls can limit which external services the sandbox can reach. Runtime, retry and spending limits prevent an unattended assignment from consuming resources indefinitely.
Kubernetes NetworkPolicy depends on a networking implementation that enforces the rules. Spending limits need enforcement in the agent system or inference gateway; a CPU limit does not cap an external model bill.
The Kubernetes SIG Apps Agent Sandbox project gives platform teams a way to manage these environments and their lifecycles. It also supports configurations that use isolation runtimes such as gVisor and Kata Containers. Provisioning and cleanup become the platform team’s responsibility.
Within those limits, the agent can install approved dependencies, modify the code and run tests. The engineer does not need to supervise every shell command.
Decide Where the Code Goes
The agent now sends part of the repository to a model. Where did that code just go? The request may contain existing routes, test failures and details of internal services. Isolating the workspace does not determine who receives that information.
Open-weight models give enterprises a choice about where inference runs. When a model meets the quality requirements of the task, the enterprise can serve it on infrastructure it controls. It can decide where the code is processed and which services may access it. An external frontier model provider may still be appropriate for some work, provided the data and destination are approved.
The workspace and inference service are separate workloads. Tools, coding work and tests may run primarily on CPUs, while a shared model service uses GPU capacity. Kubernetes can operate both. Large models may need several GPUs with sufficient memory and a fast interconnect; each approved location must provide a suitable deployment rather than relying on spare GPUs scattered across providers.
An enterprise should be able to change models or infrastructure providers while keeping the same restrictions on where its code and data can be sent.
Logs, traces and metrics need the same treatment. Keeping inference private accomplishes little if prompts and tool outputs are then exported through a tracing service. The enterprise must decide where those records go and who can read them.

