From Sandbox to Cluster: What Bridges an AI Agent's Validated Code to a Governed Deployment

Key points:

• An agent sandbox (E2B, Daytona, Vercel Sandbox) proves code runs. It has no RBAC, promotion model, IAM binding, or change record.
• A deployment is governed when seven conditions hold: identity, scope, policy, provenance, secret isolation, human approval, reversibility.
• GitOps and IDP APIs bridge the gap under audit; a CI job works if you own the governance, and raw kubectl should never reach production.
• With Qovery, the agent deploys to a preview environment in your own AWS, GCP, Azure, or Scaleway account or existing cluster, and a human gates production.

What bridges an AI coding agent's sandbox-validated code to a governed deployment on your own Kubernetes cluster is a deployment control plane with environment-scoped RBAC, policy checks, secret injection, and an audit log - the sandbox validates correctness, the control plane grants authorization. The agent hands over an artifact and an intent. The control plane decides whether the change is allowed, where it lands, and how to undo it.

A sandbox tells you the code runs. It tells you nothing about whether it is allowed to run.

Teams wiring Claude Code, Cursor, or Codex into delivery usually nail the sandbox step, then bridge to the cluster with a kubeconfig in an environment variable. Here is the better map.

What does a sandbox like E2B, Daytona, or Vercel Sandbox actually prove - and what does it not prove?

An agent sandbox proves one thing: the AI coding agent's code executed and its tests passed inside an isolated, disposable machine. It proves nothing about identity, permissions, network boundaries, cost, or whether the change may reach users. That is by design, and these products do their job well:

• Vercel Sandbox runs untrusted or agent-generated code in Firecracker microVMs, each with its own filesystem and network (Vercel docs). Sessions are capped at 45 minutes on Hobby and 24 hours on Pro, at most 8 vCPUs and 16 GB on Pro (Vercel Sandbox limits). Firecracker itself boots in under 125 ms with under 5 MiB overhead per VM (Firecracker).
• Daytona advertises sandboxes "spinning up in under 90ms from code to execution" for running AI-generated code (Daytona docs).
• E2B gives each agent "a fast, secure Linux VM created on demand" (E2B docs).

None of them claims to be a deployment platform, and fast starts with hard session caps are exactly right for an execution layer. A green run against mocks still says little about IAM denials, security group rules, connection pool limits, or migration locks on a real Postgres.

The code deserves scrutiny too. Veracode found 45% of AI-generated code samples failed security tests across more than 100 LLMs (Veracode), and 46% of developers actively distrust AI tool accuracy (Stack Overflow 2025).

The sandbox answers "does it work?". The deployment control plane answers "who approved this, where did it land, and can we undo it in 60 seconds?"

Why can't the AI coding agent just run kubectl apply against the cluster?

It can, and that is the risk: a kubeconfig turns every hallucinated or prompt-injected manifest into a live production change. The Kubernetes audit event names a credential, not the agent run, the prompt, or the human behind it, and RBAC has no verb for "only if a human approved it".

• Blast radius. Kubernetes RBAC grants verbs like create, patch, and delete, with no way to say "this one app, this one environment, this one time".
• Non-repudiation. Kubernetes auditing records what happened, when, who initiated it, and on what (Kubernetes docs). "Who" is a user or service account. The agent session, prompt, ticket, and approving human are absent.
• Drift. Direct applies diverge from Git within hours and break reconciliation, review, and disaster recovery.
• Prompt injection. OWASP ranks prompt injection LLM01:2025 and Excessive Agency LLM06:2025. Every GitHub issue or dependency README your agent reads can carry instructions, and a cluster credential turns them into changes.

The right interface exposes intent-level verbs over an API (deploy this app to this environment, roll back), never infrastructure verbs (patch this Deployment, read this Secret). Read-only by default, write as an explicit, revocable opt-in. That default matters more for a non-deterministic caller than for a human.

You can harden kubectl with narrow Roles, Kyverno or OPA Gatekeeper, and short-lived certs. It works, but you are now building an approval system and a policy library yourself, and you still lack the "who approved this" record.

What does a governed deployment actually require? A seven-item checklist

A deployment is governed when seven conditions hold at the same time: identity, scope, policy, provenance, secret isolation, human approval, and reversibility. Miss any one and you have automation, not a governed deployment, whether the actor is a human or an agent.

1. Identity. Every action is attributable to a named actor, human or agent, holding its own credential. Never a shared robot token.
2. Scope. Permissions are per project and per environment, so a credential that can deploy to preview physically cannot touch production.
3. Policy. Checks run before rollout: verified provenance, no :latest tags, resource limits set, no privileged containers. Kyverno (CNCF graduated on March 16, 2026, per CNCF) and OPA Gatekeeper are the usual enforcement points.
4. Provenance. The artifact traces back to a commit and a build. SLSA Build L2 requires a hosted build platform with signed provenance; L3 adds isolated runs and signing secrets unreachable by build steps (SLSA v1.0). Sign images with cosign, which logs signatures in Sigstore's Rekor transparency log (Sigstore docs).
5. Secret isolation. The agent never reads production secrets. The control plane injects them into the workload at runtime.
6. Approval. Promotion to production is a recorded human gate, not a side effect of a merge.
7. Reversibility. Rollback to the last good revision in under a minute, plus a complete, queryable change history. DORA tracks this as failed deployment recovery time (DORA).

My verdict: an agent sandbox satisfies zero of the seven. A CI pipeline you wrote yourself satisfies maybe four. GitOps and an IDP can satisfy all seven.

What are the four real options for bridging an agent sandbox to your own Kubernetes cluster?

Four bridge patterns are in production today: a pull request into GitOps, an internal developer platform API, a CI deploy job, or direct cluster access. The first two scale under audit, the third works if you own the governance yourself, and the fourth should never reach production.

• Agent to PR to GitOps (Argo CD, Flux). GitOps has the strongest provenance story in the industry: Git is the record and reconciliation is continuous. Both are CNCF graduated, Argo on December 6, 2022 and Flux on November 30, 2022 (CNCF Argo, CNCF Flux). The cost: a slower loop, an agent that must learn your manifest layout, and a team running Argo CD plus the cluster.
• Agent to IDP API (Qovery, Humanitec, Port with Score, Northflank). Environments, RBAC, previews, and audit are already modelled, and the agent writes far less YAML. DORA reports 90% of organizations have adopted at least one platform (Google Cloud, DORA 2025). The cost: you adopt the product's environment model.
• Agent to CI job (GitHub Actions, GitLab CI). Works with what you have, but governance lives in workflow YAML you must keep correct, and secrets sprawl.
• Agent to kubectl or Helm. Fastest demo, fails every audit. Throwaway dev namespaces only.

Patterns 1 and 2 compose: Qovery deploys from Git, so the pull request stays the record of change.

The decision rule: already running Argo CD with a platform team, extend it. No platform team and you want environments plus RBAC on day one, use an IDP. Neither, do not hand the agent a kubeconfig.

Where should the handoff point be, and what exactly should the agent hand over?

The handoff is an immutable artifact plus a declared intent, never a set of imperative commands. The AI coding agent hands over a commit SHA or signed image digest and names the target environment; the deployment control plane decides whether that is allowed, injects secrets, performs the rollout, and records it.

• Artifact first: a commit SHA or signed digest, never "apply this YAML I generated five seconds ago".
• Portable intent: app, environment, dependencies, resources. Score is a reasonable open vocabulary, currently a CNCF Sandbox project (CNCF).
• The ephemeral preview environment is the real validation step, testing against real databases, networking, IAM, and quotas.
• Production promotion is a separate human gate, and the promoted artifact must be byte-identical to the one validated in preview.

Volume makes per-PR previews mandatory. Developers merged 518.7 million pull requests on GitHub in 2025, up 29%, and Copilot coding agent created over a million PRs in five months (GitHub Octoverse). DORA found AI adoption improves throughput but still hurts delivery stability (Google Cloud, DORA 2025). A single shared staging becomes the queue.

Cost is governance too. Wasted cloud spend rose to 29% (Flexera 2026 State of the Cloud), and agent environments without auto-stop add to it.

Ban one anti-pattern outright: the agent builds an image in the sandbox and pushes it to a registry the cluster trusts, with no provenance attestation.

How does this work with Qovery on your own cloud account or existing Kubernetes cluster?

Qovery acts as the deployment control plane: the agent calls Qovery with an artifact and an intent, Qovery deploys into your own AWS, GCP, Azure, or Scaleway account or your existing Kubernetes cluster, and every action is scoped by per-environment RBAC and recorded. The cloud bill, the data, and the audit trail stay in your account.

• BYOC: your GCP committed-use discounts, Azure VNets, Scaleway private networks, and compliance boundaries apply unchanged.
• Bring your own Kubernetes: Qovery can drive an existing self-managed or on-prem cluster.
• Git-push deployments and a preview environment per pull request: safe for the agent, still real infrastructure.
• Per-environment RBAC: an agent credential scoped to preview cannot promote to production. This one control makes agent deployment defensible to security.
• Auto-stop for non-production, databases backed by managed cloud services, and managed cluster upgrades.

Against the checklist: identity and scope come from per-environment RBAC, provenance from Git deployments tied to a commit, secret isolation from runtime injection, approval from the human-gated production promotion, and reversibility from redeploying a previous version. Policy is shared: Qovery controls who deploys where, and Kyverno or Gatekeeper keep in-cluster admission rules.

Qovery replaces the glue you would assemble around Argo CD, Terraform, and CI. It does not replace your agent sandbox, which stays the right place for untrusted code (see our sandbox comparison and why agents should deploy through a scoped API).

How do I wire this up from Claude Code, Cursor, or Codex?

Install the Qovery Agent Skills once, add the Qovery MCP Server read-only, then ask your agent in plain language to deploy the validated code to an ephemeral preview environment in your own cloud account. Write access is a separate opt-in that you also enable in the Qovery Console.

Install the skills globally for Claude Code, Cursor, Codex, OpenCode, and Gemini CLI:

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope them to the current project:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code over OAuth, read-only by default, so the agent can inspect environments, deployments, and logs:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want it, after enabling it in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) do the deploying; the MCP Server operates what exists. Then prompt "deploy this branch to a preview environment in our GCP account with Qovery", and approve the proposed actions before anything runs. See the AI agent quickstart and the Claude Code integration page.