> ## Documentation Index
> Fetch the complete documentation index at: https://docs.costgraph.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Run workflows in your environment

> Run the commands a workflow's agent executes inside your own Kubernetes cluster

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

| | Where it runs |
| - | - |
| The agent's reasoning | Anthropic, which hosts the model |
| Commands the agent runs, and the files they touch | A sandbox in your cluster |
| Approvals, runs and results | CostGraph |

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](https://github.com/kubernetes-sigs/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](/costgraph/self-hosted/values#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:

```bash theme={null}
kubectl -n costgraph-agents create secret generic agent-runtime-key \
  --from-literal=key-encryption-key="$(openssl rand -base64 32)"
```

```yaml theme={null}
openshell:
  server:
    credentialStorage:
      existingSecret: agent-runtime-key
```

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.