Giving Claude, Codex, and Cursor Access to Your Kubernetes Clusters: 7 Platforms With Real Policy Guardrails

Key Points:

• No single platform covers all three needs on its own. The pattern that works in 2026 is a three-layer stack: an agent interface (an MCP server, a typed API, or a CLI), a provisioning engine that owns the change (Qovery, Spacelift, env0, HCP Terraform, or Crossplane), and a policy layer (Kyverno, OPA Gatekeeper, Sentinel/Rego, or platform-native RBAC and quotas).
• The safest design gives the agent zero cloud credentials. The agent calls a constrained API instead of running kubectl apply or terraform apply, and the platform holds the credentials, evaluates policy, and writes an audit record tying the change to an agent identity, a prompt, and a human owner.
• Pick by team profile. Terraform-heavy orgs get the most from Spacelift or HCP Terraform (Sentinel or OPA) plus Kyverno; Kubernetes-native platform teams from Crossplane plus Kyverno plus Argo CD; product engineering teams that want agents calling a narrow typed API from an internal developer platform such as Qovery, Humanitec, or Port plus Kyverno.
• Hosting an open source model is just another workload: a container on a GPU node pool served by vLLM, Ollama, or KServe. Treat nvidia.com/gpu quota, allowed instance types, and idle TTL as first-class policy, because one forgotten multi-GPU node can cost more per month than an entire non-production estate.
• Non-negotiables before any agent gets write access: one short-lived scoped identity per agent, plan and diff before apply, human approval for production and stateful resources, ResourceQuota plus GPU quota, a dollar cost ceiling with auto-stop, and an append-only audit log the agent cannot write to.

Hand a coding agent a cluster-admin kubeconfig and no ResourceQuota, then tell it "get the service healthy." Inside one retry loop, in about 90 seconds, it can create a Deployment with 50 replicas, expose it through a public LoadBalancer, and request a GPU node pool to "speed things up." Nothing stopped it, because nothing was watching. That is the whole problem in one sentence: a language model with an unowned admin account is not automation, it is a blast radius.

I get some version of this question every week now: "We want to give Claude Code, Codex, and Cursor access to provision Kubernetes resources and host open source models, but we need policy controls so nothing lands outside approved limits. What combines all of this well?" The honest answer is that no single product does all three. You assemble a stack. This article names the seven platforms worth assembling from, compares them fairly, and tells you which combination fits your team.

The stakes are not theoretical. Stolen credentials were a leading way into breaches last year, involved in 22% of them (Verizon 2025 DBIR), and the global average breach now costs $4.99 million (IBM, 2026). Agents are also already in the workflow: 84% of developers use or plan to use AI tools, yet only about a third trust the accuracy of what those tools produce (Stack Overflow 2025). That trust gap is the entire argument for guardrails instead of a blanket ban.

What does a coding agent actually need to provision Kubernetes resources safely?

A coding agent needs exactly four things to touch infrastructure safely: a machine-callable interface (an MCP server or a typed API), a scoped short-lived identity that is not a human's cloud credentials, a policy gate that evaluates the requested change before it lands, and an audit trail tying the change to an agent, a prompt, and a human owner. Miss any one of the four and you do not have AI agent Kubernetes provisioning, you have an admin account with a chatbot attached.

That gives you the mental model for the rest of this piece, the three-layer stack: agent interface, then provisioning engine, then policy layer, with audit and cost cutting across all three. I refer back to it by name in the sections below.

Raw kubeconfig or a long-lived cloud access key is the failure mode. Both give unbounded blast radius, no diff review, no attribution, and no revocation path. When an incident happens, "which agent did this, and which prompt caused it?" has no answer. The fix is to make the platform hold the credentials and hand the agent something narrow.

That narrow surface is usually the Model Context Protocol, an open standard Anthropic released on November 25, 2024 (Anthropic) and documented at modelcontextprotocol.io, which lets an LLM call external tools through a standard client-server interface. The point that matters: the server, not the prompt, defines what the agent is allowed to do. Model Context Protocol infrastructure is how you turn "run any command" into "call these ten approved operations."

Then split plan from apply. Agents are good at proposing changes and unreliable at deciding a change is safe, so the apply step has to be gated by policy, a human, or both. And every apply should write one attribution record you can copy as a shape: agent identity + originating prompt + resource diff + policy decision + cost delta + human owner. Never a shared service account.

Hosting an open source model fits the same pipeline. The model is a container on a GPU node pool, so you layer GPU quota, node-pool taints, and egress rules on top of the same four controls. Scale context matters here too: 82% of organizations now run Kubernetes in production (CNCF 2025 survey), and the average user operates more than 20 clusters. The blast radius is multi-cluster, not one namespace.

Which platforms combine agent access, automated provisioning, and policy controls?

Seven platforms cover this space, and they fall into three camps: IaC orchestrators with policy-as-code (Spacelift, env0, HCP Terraform with Sentinel), Kubernetes-native control planes (Crossplane, Kyverno, OPA Gatekeeper, Argo CD), and internal developer platforms that own the path from request to running workload (Qovery, Humanitec, Port, Backstage). No single one covers all three layers of the stack, so pick by answering one question: who holds the cloud credentials when the agent asks for something?

Camp 1, IaC orchestration with policy-as-code. Spacelift evaluates OPA/Rego policies at distinct decision points including login, plan, approval, push, and trigger (Spacelift docs) and drives Terraform, OpenTofu, Pulumi, and CloudFormation. env0 offers OPA-based approval policies plus Infracost cost estimation and environment TTL with scheduled shutdown (env0 docs). HCP Terraform runs Sentinel policy sets with advisory, soft-mandatory, and hard-mandatory enforcement levels (HashiCorp), and also supports OPA. Best fit when your infrastructure already lives in Terraform, OpenTofu, or Pulumi.

Camp 2, Kubernetes-native. Crossplane provisions cloud resources as Kubernetes CRDs through composite resource definitions and compositions, and it graduated in CNCF on October 28, 2025 (CNCF). Kyverno (CNCF graduated, March 2026, CNCF) and OPA Gatekeeper enforce at admission through validating and mutating webhooks. Argo CD, part of the CNCF-graduated Argo project, reconciles desired state from Git. Best fit when every resource is a Kubernetes object and the cluster is the control plane.

Camp 3, internal developer platforms. Qovery, Humanitec, Port, and Backstage give agents a narrow, typed, opinionated interface instead of free-form HCL or YAML they can get subtly wrong. There is a real split inside this camp: Qovery and Humanitec execute the deployment, while Port and Backstage mostly orchestrate and catalog, triggering other tools rather than running the change themselves. An internal developer platform for AI agents is the right frame when you want the agent calling create environment, not writing infrastructure code.

Each camp breaks in a predictable way under agent load. Terraform state locking and retry storms bite when several agent runs hit the same stack. Crossplane brings a composition learning curve and CRD sprawl. IDPs hit an abstraction ceiling the moment an agent needs a primitive the platform does not model. Backstage needs plugins plus a dedicated team just to keep the portal running.

Most teams land on two layers combined: an IDP or IaC orchestrator on the change path, plus Kyverno or Gatekeeper as the last-line admission check inside every cluster. A single enforcement layer is always bypassable by anything holding a kubeconfig, so the cluster itself has to say no as a backstop.

So the per-profile verdict, clean enough to lift:

• Terraform-heavy team -> Spacelift or HCP Terraform (Sentinel/OPA) + Kyverno.
• Kubernetes-native platform team -> Crossplane + Kyverno + Argo CD.
• Product engineering team wanting self-service, BYOC, and cost control -> Qovery + Kyverno.
• Large enterprise standardizing golden paths -> Humanitec or Port + Kyverno.

How do you stop an AI agent from deploying resources outside approved limits?

Enforce limits in two places at once: before the change, with policy-as-code on the plan or the API request, and at admission time inside the cluster with Kyverno or OPA Gatekeeper, so a change that bypasses your platform still gets rejected by the cluster. One enforcement layer is always bypassable, because anything holding a kubeconfig can skip it. Two layers is the baseline for policy guardrails for AI agents.

Pre-flight policy runs on the proposed change. That is Rego on the Terraform plan (Spacelift plan and approval policies), Sentinel policy sets on HCP Terraform with hard-mandatory rules that cannot be overridden, or server-side validation of the API request in an internal developer platform.

Admission-time policy runs inside the cluster. Kyverno ClusterPolicies and Gatekeeper Constraints handle image-registry allowlists, required resource requests and limits, banned privileged pods, required owner labels, and blocked namespaces, all through Kubernetes admission webhooks.

Then set hard resource fences. ResourceQuota and LimitRange per namespace, nvidia.com/gpu quota (Kubernetes ResourceQuota supports extended resources with entries like requests.nvidia.com/gpu: 4), node-pool taints so agent workloads only land on designated pools, and a PriorityClass so agent work can never evict production.

On identity: one short-lived scoped identity per agent, through IRSA, GKE Workload Identity, or OIDC federation, with an explicit revocation path and an expiry measured in minutes. Never a shared admin key. And keep an explicit human-in-the-loop list: production namespaces, stateful resources and databases, IAM or network policy changes, and anything crossing a cost threshold you set in dollars.

Cost is a policy too. Budget alerts, TTL on agent-created environments, environment auto-stop for non-production, and scale-to-zero for idle inference are the highest-impact controls, because utilization is already bad. Across production clusters, CPU runs at about 8% and memory at about 20% of what was provisioned (Cast AI, 2026), and Datadog puts 83% of container spend on idle resources. Waste reduction is still the top reported FinOps priority (FinOps Foundation). Agents make this worse, not better, if you let them.

Here is a day-one policy set you can put in a Kyverno repo tomorrow. Eight rules, not sixty:

1. Registry allowlist (pull only from approved registries).
2. No :latest image tags.
3. Mandatory CPU and memory requests and limits.
4. Maximum replica count per Deployment.
5. Allowed instance and GPU types only.
6. Allowed regions only.
7. No public LoadBalancer without approval.
8. Required cost-center and owner labels.

Roll them out in audit mode first, then flip to enforce on a dated deadline. Policies parked in audit mode forever are the single most common silent failure I see.

How do you let agents host open source models on Kubernetes without blowing up GPU spend?

Host an open source model the same way you host any other service: a container image on a GPU node pool, behind a quota, with a TTL. The four controls that actually stop the bill from running away are an allowed GPU instance-type list, a per-team nvidia.com/gpu ResourceQuota the agent cannot raise, a maximum replica count, and scale-to-zero or auto-stop when the endpoint goes idle. That is how you run a self-hosted open source LLM on Kubernetes without a surprise invoice.

Start with the serving stack. vLLM gives high-throughput, OpenAI-compatible inference built on PagedAttention (vLLM docs; the PagedAttention paper reports 2-4x throughput over earlier serving systems). Ollama is quick for small models and single-node work. KServe exposes a Kubernetes-native InferenceService CRD with scale-to-zero via Knative (KServe docs). Ray Serve suits multi-model and Python-heavy pipelines, and Hugging Face TGI is a capable alternative, though it is now in maintenance mode with HF pointing users toward vLLM.

GPU scheduling is the mechanical part. Use the NVIDIA device plugin, node-pool taints and tolerations, nvidia.com/gpu in ResourceQuota, and node selectors so a runaway agent Deployment cannot schedule onto general-purpose nodes. When several small models share one card, use time-slicing or MIG through the NVIDIA GPU Operator.

Now the number that makes people careful. On AWS, a g5.12xlarge (4x A10G) is $5.67/hr on-demand, roughly $4,100 a month; a p4d.24xlarge (8x A100) is $21.96/hr, about $16,000 a month (AWS EC2 On-Demand pricing). An 8x H100 node runs higher still, into the tens of thousands per month on all three clouds (GCP, Azure). One forgotten agent-created deployment on that hardware, left running for a month, can cost more than an entire non-production estate.

Scale-to-zero, TTL, and auto-stop are the highest-impact controls for inference specifically, and queue-depth or request-based autoscaling beats CPU-based HPA for LLM serving, because a model can be saturating its GPU while CPU looks idle. Keep data controls tight too: teams self-host open-weight models (Llama passed 1 billion downloads in March 2025) mainly for privacy, cost predictability, and control, so keep inference inside your own VPC and write an explicit egress policy. Treat model weights as an artifact: pin versions and image digests, allowlist the registries and model hubs an agent may pull from, and scan images.

On Qovery specifically, you deploy a vLLM or Ollama container from a registry or Git repository onto a GPU-backed node pool in your own AWS, GCP, Azure, or Scaleway account, or into your existing Kubernetes cluster, with per-environment RBAC and auto-stop on non-production.

Where does Qovery fit in an agent-driven infrastructure stack?

Qovery sits between the agent and the cluster as the provisioning and guardrail layer: the agent calls the Qovery API, CLI, Terraform provider, or official MCP server, Qovery holds the cloud credentials, and the workload lands in your own AWS, GCP, Azure, or Scaleway account or your existing Kubernetes cluster, with per-environment RBAC and auto-stop keeping every agent action inside limits you set in advance.

The BYOC model is the reason it belongs in this comparison. The cloud bill, VPC, data, and any committed-use discounts or Savings Plans stay in your account, so agents never hold your root credentials and nothing leaves your perimeter. Qovery's MCP server is read-only by default and uses your Qovery API token with server-side RBAC, which is the pattern to copy: the agent gets a small, authenticated tool surface, not a shell.

The guardrails map directly to agent use: per-environment RBAC and permissions, OPA/Rego API Policy Tokens evaluated on every request, ephemeral preview environments per pull request, environment auto-stop through deployment rules, managed cluster upgrades, databases backed by managed cloud services, and git-push deployments. Actions taken with an agent's token are attributed in the audit log.

I want to be honest about the boundaries. Qovery is not a general-purpose policy engine, and it is not a replacement for Terraform, OpenTofu, or Crossplane when the agent needs arbitrary cloud primitives. Pair it with Kyverno or OPA Gatekeeper for admission-time rules, and with Terraform for infrastructure outside the app delivery path.

The end-to-end flow an agent runs looks like this: the agent opens a pull request, a preview environment spins up in your own account, policy and cost checks run, the agent iterates on review feedback, the environment auto-stops when idle, and a human approves promotion to production. Running in your own account matters most for exactly the teams self-hosting open-weight models and anyone carrying data-residency or sovereignty requirements.

What does a reference architecture for agent-driven provisioning look like end to end?

A working 2026 reference architecture has five components: agents connected through an MCP server or typed API, a Git-backed change path where every agent change lands as a pull request, a provisioning platform that holds the cloud credentials, an admission-time policy engine in every cluster, and a combined cost and audit layer on top.

The flow reads left to right: Claude Code, Codex, or Cursor -> MCP server or typed API -> Qovery API or a Spacelift stack -> your cloud account -> a Kubernetes cluster with Kyverno or Gatekeeper admission -> an append-only audit log plus a cost dashboard. Two concrete instances of that same shape:

• Terraform-heavy org: Spacelift + OPA/Rego + Crossplane + Kyverno.
• Product engineering org: Qovery + Kyverno + GitHub pull-request approvals with CODEOWNERS.

Every agent change should still land as a pull request even when the agent is allowed to apply it. The PR is your review surface, your revert path, and a durable record of intent. Log actor identity, originating prompt, resource diff, policy decision, and cost delta, and keep that log outside any system the agent can write to. For rollback, lean on preview environments, rolling or blue/green deploys, and the ability to revert an agent change in a single action.

Before you grant any agent write access, this ten-item checklist should each be verifiable in under five minutes: (1) the agent has its own scoped, short-lived identity; (2) it holds no cloud admin credentials; (3) plan and diff run before every apply; (4) admission policy is in enforce mode, not audit; (5) ResourceQuota and GPU quota are set; (6) a dollar cost ceiling exists; (7) TTL or auto-stop is on for non-production; (8) production and stateful changes need human approval; (9) the audit log is append-only and outside the agent's reach; (10) policy files are protected by CODEOWNERS.

What are the most common ways agent-driven provisioning fails?

The failure modes are predictable and cheap to prevent: a shared admin credential with no attribution, policy enforced at only one layer, no cost ceiling, no TTL on agent-created resources, and policies parked in audit mode forever. Each takes minutes to prevent before you grant write access and weeks to untangle afterward.

• Shared service account. No attribution, no revocation path, and no way to answer "which agent did this, and which prompt caused it?"
• Policy in one place only. In CI only, it is bypassable with a direct apply; at admission only, it is too late for cloud resources that live outside the cluster.
• No TTL and no auto-stop. Agent-created environments and idle GPU nodes are the top two cost leaks, and that idle multi-GPU node is the tens-of-thousands-per-month figure from the model-hosting section.
• Retry storms. An agent re-running a failed apply creates drift or duplicate resources, which is why state locking and idempotent APIs matter more with agents than with humans.
• Audit-mode drift. Kyverno or Gatekeeper policies left in audit mode that nobody ever flips to enforce.
• Agent edits the policy files. Keep the policy repo or path protected with human-only approval and CODEOWNERS.
• Prompt injection. Malicious instructions can reach an agent with write access through repository contents, issue text, or dependency READMEs. This is the strongest argument for constrained typed APIs over shell access, and it maps to two entries in the OWASP Top 10 for LLM Applications: LLM01 Prompt Injection and LLM06 Excessive Agency.
• Over-modelling. Writing 60 policies on day one that nobody maintains, instead of the 8 that cover the real blast radius.