Skip to main content
By default, the commands a workflow’s agent runs, such as reading a cloud account with its CLI, run in CostGraph’s infrastructure. With the agent runtime, they run in sandboxes inside your own Kubernetes cluster instead, so files, processes and network access stay in your network. Running workflows in your environment is an enterprise feature, set up with CostGraph. Contact your account team to enable it.

​
What runs where

The agent’s conversation still reaches Anthropic wherever its commands run: the inputs it sends to a command and the output it reads back are part of that conversation. Running in your environment keeps the command itself, its files and its network access local, not the conversation.

​
How a sandbox is isolated

Each run gets its own sandbox: a pod with its own filesystem, CPU and memory limits, and a network policy.
  • Network: a sandbox reaches only the hosts its workflow needs, and only with the requests that workflow allows. Everything else, including other services in your cluster and the cloud metadata endpoint, is refused.
  • Resources: every sandbox is created with CPU and memory limits, so a run cannot starve the workloads it shares nodes with.
  • Lifetime: a sandbox exists for one run and is deleted when the run ends.

​
Requirements

  • Kubernetes 1.29 or later.
  • A network plugin that enforces Kubernetes NetworkPolicy, for both ingress and egress. Without enforcement, sandbox network rules are accepted but not applied. On EKS, turn on network policy in the VPC CNI add-on.
  • A default StorageClass, for the runtime’s state volume and each sandbox’s workspace.
  • Permission to install cluster-wide resources: the runtime adds the Agent Sandbox custom resource definitions and their controller.

​
What gets installed

The runtime ships as the costgraph-agent-runtime Helm chart from https://charts.costgraph.ai. It installs:
  • A sandbox gateway that creates, supervises and deletes sandboxes.
  • The Agent Sandbox controller and its custom resource definitions. Leave it out with agentSandbox.enabled=false if your cluster already runs it.
Install it in a namespace of its own. Self-hosted installations can turn it on inside the self-hosted chart instead; see Other CostGraph charts. The gateway encrypts the credentials it stores with a key it generates on first install and keeps across upgrades. If you deploy with a tool that renders manifests instead of running helm install, such as Argo CD, create that key yourself and pass it in, or each sync would replace it:
The value must be exactly the output of openssl rand -base64 32. Set it once and never change it: a replaced key makes stored credentials unreadable.