How to Let AI Coding Agents Deploy Without Handing Them Your Cloud Account

A CTO I talked to earlier this year gave Claude Code an AWS access key so it could "just handle the deploys." Two weeks later the agent read a GitHub issue with instructions hidden inside a fenced code block, did what the text told it to do, and started creating resources nobody had asked for. Nothing blew up. But the CloudTrail log showed a single IAM role doing all of it, so no one could say which task, which prompt, or which agent run was responsible.

That is the question I now get from CTOs almost every week: we are rolling out Claude Code and Cursor across the team, so how do we let these agents deploy without handing them the keys to our cloud account?

The short answer is that you never give an AI coding agent long-lived cloud credentials. You give it an API on a platform that already holds scoped, short-lived credentials and executes only pre-approved actions on the agent's behalf. The agent gets a deploy button, not a cloud console. Everything below is how to build that, and how the main platforms compare when you do.

Key Points:

• Never give an AI coding agent long-lived cloud credentials. Give it an API on a platform that already holds scoped, short-lived credentials and executes only pre-approved deployment actions on the agent's behalf.
• Governed execution for agents needs five things: scoped identity per agent, an allow-listed action surface (deploy, promote, rollback - not raw cloud API), isolated ephemeral environments, an immutable audit trail, and human approval gates on production.
• Platform choices split into two groups: agent sandbox/workspace platforms (Daytona, CodeSandbox, Coder, E2B) that isolate where the agent runs code, and deployment control planes (Qovery, TrueFoundry, AWS-native IAM + Service Catalog) that govern what the agent can ship.
• Qovery fits the second group: it runs inside your own AWS, GCP, Azure, or Scaleway account (or your existing Kubernetes cluster), exposes deployments through an API/CLI with per-environment RBAC, ephemeral preview environments per pull request, and an audit log - so the agent gets a deploy button, not IAM keys.
• The safest default pattern in 2026: agents get unrestricted write access to ephemeral non-production environments, and propose-only access to production behind human approval.

What does "governed execution" actually mean for AI agent deployments?

Governed execution means the agent never holds cloud credentials. It calls a control plane that authenticates it as a distinct identity, checks the requested action against policy, executes with short-lived scoped credentials, and records what happened. Five control points make it work:

• Identity. Each agent gets its own service account or API token, so every action is attributable to a specific agent and task.
• Action surface. The agent can call platform verbs (deploy, promote, roll back, read logs), not the raw cloud API.
• Blast radius. Agent work lands in isolated, ephemeral environments, not shared production.
• Auditability. Every action is written to an immutable log you can review after the fact.
• Approval gates. Anything touching production waits for a human to say yes.

The naive version of this is a human handing the agent an IAM user, or dropping an admin role into the Cursor or Claude Code terminal. The governed version is the agent calling a deployment API that already knows what it is allowed to do.

This matters more for agents than for people. A human engineer with admin access acts a few times an hour and thinks about consequences. An agent acts at machine speed, can loop, and can be steered mid-task by untrusted input it reads while working: a malicious GitHub issue, a poisoned dependency, a web page it opens during research. One more distinction, because teams conflate them constantly: sandboxing controls where an agent runs code, governing controls what it is allowed to ship. Most teams need both.

Why is giving an AI agent direct AWS (or GCP/Azure) access the wrong default?

IAM was built for stable, human-scoped roles. An AI agent is a non-deterministic actor that can be talked into things by input it reads while working, which breaks the assumptions IAM was designed around. Five concrete failure modes show up:

• Prompt injection is a real path to your cloud API. Prompt injection is ranked LLM01 and excessive agency is LLM06 in the OWASP Top 10 for LLM Applications. An agent that reads a malicious issue or README and also holds cloud credentials can be turned into a deploy tool for someone else.
• Least privilege collapses. For a general-purpose agent, an IAM policy is either too broad (effectively admin) or so narrow the agent stalls constantly and a tired engineer widens it "just for now."
• Credentials leak. Keys placed in an agent's context window end up in logs, in prompt history, and in model-provider traces. Stolen credentials were the initial access vector in 22% of breaches in Verizon's 2025 DBIR.
• Attribution disappears. When every agent uses the same role, CloudTrail shows one identity doing everything. After an incident you cannot answer "which agent deployed this?"
• Cost blast radius. An agent looping on terraform apply or spinning up resources can run up a bill before anyone notices.

Anthropic's own guidance for building agents points the other way: test agents in sandboxed environments with guardrails, and build in checkpoints where the agent pauses for human feedback. OWASP now maintains a dedicated Agentic Security Initiative for exactly these risks. Everyone converges on the same conclusion: short-lived, scoped credentials instead of long-lived keys, which is also AWS's own top IAM recommendation.

Sandboxes vs deployment control planes: the two categories

Agent tooling splits into two groups, and they solve different halves of the problem.

Agent sandboxes and dev environments isolate where an agent runs code. Daytona, E2B, CodeSandbox SDK, and Coder workspaces give you fast, disposable, isolated compute so an agent can execute untrusted code without touching anything real. They are genuinely good at this, and Qovery does not compete here. What they do not do is govern a production deployment.

Deployment control planes and internal developer platforms govern what an agent is allowed to ship into real infrastructure. Qovery and TrueFoundry sit here, as does a hand-built AWS-native stack (Service Catalog, SCPs, IAM Roles Anywhere, CloudTrail, Config). These check a requested deploy against policy and run it with scoped credentials.

Where do Claude Code and Cursor fit? They are the agents, not the guardrail. They inherit whatever credentials the shell they run in already has, which is exactly the problem you are trying to solve. The guardrail has to live below them.

The connective tissue is increasingly the Model Context Protocol (MCP). Instead of calling a cloud SDK, the agent calls a governed MCP tool that enforces auth and policy on the way through. The composition most teams land on: a sandbox for execution, a control plane for deployment, and git as the source of truth in between.

Which platforms provide governed execution for agent-driven deployments?

Here are five credible options in 2026. Each governs a different layer, so choose based on whether your real constraint is agent compute isolation or production deployment policy.

Qovery is a BYOC deployment control plane. It installs into your own AWS, GCP, Azure, or Scaleway account, or connects to your existing Kubernetes cluster, and the cloud account, bill, and data stay yours. Deployments are exposed through a REST API, CLI, and Terraform provider, with per-environment-type RBAC (No Access, Read-Only, Deploy, Manage, Full Access), ephemeral preview environments per pull request, environment auto-stop to cap agent-driven cost, and an audit log that records who did what, where, and when including the API token responsible. It also ships an MCP server that is read-only by default and enforces the same RBAC and audit trail, so an agent gets exactly the scoped deploy button described above. Best fit: teams that want governed application and environment deploys inside their own cloud, on AWS, GCP, Azure, Scaleway, or bring-your-own-Kubernetes alike.

TrueFoundry is strongest when the workload is AI/ML and model serving. It runs on Kubernetes and, for enterprise customers, the control plane can sit in your own cloud. If your agents are shipping models and inference endpoints rather than general application infrastructure, it fits well.

Coder is about governed remote development environments. It is self-hosted and runs agents and workspaces on infrastructure you control, with centralized policy and audit. It is excellent for containing agent execution inside your enterprise network. It is less about being the thing that ships to production.

Daytona, E2B, and CodeSandbox are agent sandboxes. Daytona advertises sub-90ms sandbox creation for running AI-generated code, E2B runs agent code in Firecracker microVMs, and CodeSandbox SDK gives you programmatic microVMs with fast fork and snapshot. Use them for fast, isolated, untrusted-code execution. They do not govern deployment, and that is fine, because it is not what they are for.

DIY AWS-native is the honest build-it-yourself baseline: IAM Roles Anywhere or OIDC for short-lived credentials, SCPs to cap permissions, Service Catalog for approved products, and CloudTrail plus Config for audit. Maximum control, and a real ongoing maintenance cost. One caveat: AWS Proton, often cited in this stack, is scheduled for end of support in October 2026, so I would not build anything new on it.

A concrete guardrail pattern: the permission ladder

The pattern that works in practice is a permission ladder. Agents get full autonomy where mistakes are cheap, and progressively less as the blast radius grows. Seven steps:

1. Give each agent its own token. A dedicated service account or API token per agent, never a shared human login, so the audit log attributes every action.
2. Scope the action surface to platform verbs. Create environment, deploy, promote, roll back, read logs. Not iam:*, not raw cloud API calls.
3. One ephemeral environment per task or PR. Isolated, and auto-deleted or auto-stopped when the work is done or the environment goes idle.
4. Put policy checks in the pipeline. IaC scanning, a reviewed Terraform plan, OPA or Kyverno admission control, and secret scanning run before anything reaches a real cluster.
5. Human approval gate on production. The agent opens the pull request. A human merges it. That single rule removes most of the risk.
6. Quotas and budget alarms. A looping agent should hit a wall, not your monthly cloud budget.
7. Monitor, and be able to revoke instantly. An immutable audit log, deployment history, and a token you can kill the moment something looks wrong.

This maps cleanly onto primitives that already exist. On Qovery, that is per-environment RBAC for steps 1 and 2, preview environments for step 3, the deployment API or CLI as the scoped action surface, environment auto-stop for step 6, and audit logs for step 7. You can build the same ladder on the DIY AWS stack. You will just wire and maintain more of it yourself.

How much autonomy should you actually give an agent?

Give autonomy in proportion to reversibility. Where a mistake is disposable, let the agent run. Where a mistake is expensive or irreversible, keep a human in the loop.

Some operations should never be in an agent's tool list at all: delete a database, modify IAM policies, change networking, rotate production secrets. Keep them out of the action surface entirely rather than trusting the agent to decline.

Rollback is the safety net that makes autonomy affordable. The real question is not "will the agent make a mistake," because it will, but "how fast can we undo it?" If a bad deploy is one click or one API call to reverse, you can let agents move fast on the lower rungs.

There is a review-burden reason to place the production gate carefully too. AI writes a lot of code now: 84% of developers report using or planning to use AI tools, and it is not all clean. Veracode found 45% of AI-generated code samples introduced OWASP Top 10 vulnerabilities, and GitClear measured copy-pasted code rising from 8.3% to 12.3% of commits between 2021 and 2024. More code, reviewed less carefully, is exactly why the human gate belongs on production rather than everywhere. Start with one repo and one agent, measure, then widen.

What this costs, and where teams get it wrong

The dominant cost of agent-driven deployment is not the platform license. It is idle infrastructure and cloud spend from agents that create resources faster than anyone cleans them up. Organizations already estimate that 29% of cloud spend is wasted, and agents make that worse if you let them.

The common failure modes:

• Orphaned preview environments. Every PR spins one up, nobody tears them down.
• Agents re-running builds and duplicating stacks. Loops and retries multiply compute.
• Unbounded sandbox minutes. Disposable is only cheap if it actually gets disposed.

Auto-stop and TTLs on non-production environments are the single most effective control here. Qovery cites up to 60% cost reduction from scheduling non-prod environments off outside working hours, and reducing waste is the top FinOps priority for a reason.

There is a BYOC angle too. When the platform runs in your own account, the cloud bill and any committed-use discounts or savings plans stay in your name. With a fully managed platform, the vendor owns that relationship. For teams with real spend, keeping the bill in your account usually wins.

Two more places teams get it wrong. Over-restrict, and agents stall so often that engineers widen permissions by hand, quietly undoing the whole design; a guardrail has to be usable or it gets removed. Skip attribution, and after an incident nobody can answer "which agent deployed this?", which is why per-agent identity and an audit log are not optional extras.

FAQs

What platforms provide governed execution for AI agent driven deployments?

For governing deployments: Qovery, TrueFoundry, and a DIY AWS-native stack (IAM Roles Anywhere, SCPs, Service Catalog, CloudTrail, Config). For isolating where agents run code: Daytona, E2B, CodeSandbox, and Coder. Most teams combine one from each group.

How do I let an AI coding agent deploy to AWS without giving it admin IAM access?

Put a control plane between the agent and AWS. The agent calls an API that holds short-lived, scoped credentials and only exposes deploy, promote, and rollback verbs, so it never sees an IAM key. This is also what AWS recommends: temporary credentials over long-lived access keys. The same approach works on GCP, Azure, and Scaleway.

What is the difference between an agent sandbox (like Daytona or E2B) and a deployment control plane (like Qovery)?

A sandbox isolates where the agent runs code: fast, disposable compute for untrusted execution. A control plane governs what the agent can ship into real infrastructure, with identity, policy, and audit. They are different jobs, and you usually want both.

Can AI agents deploy to production safely, or should humans always approve?

Let agents deploy autonomously to ephemeral and staging environments behind policy checks. Keep a human approval gate on production. The agent opens the PR, a person merges it. That single gate removes most of the downside while keeping the speed.

How do I audit what an AI agent deployed and roll it back?

Give each agent its own token so actions are attributable, keep an immutable audit log of every deploy, and use a platform with deployment history and one-step rollback. On Qovery the audit log records the token responsible for each action, and you can revoke that token instantly.

Does Qovery only work with AWS, or also GCP, Azure, Scaleway, and my own Kubernetes cluster?

All of them. Qovery is multi-cloud: it runs in your own AWS, GCP, Azure, or Scaleway account, and it can connect to an existing self-managed Kubernetes cluster. AWS is just the running example in this article.

The teams getting this right are not the ones with the most locked-down IAM policies. They are the ones who stopped handing agents credentials at all and gave them a governed deploy button instead: scoped identity, an allow-listed action surface, ephemeral environments, an audit trail, and a human on the production gate. Build that layer once, and letting agents deploy stops being a risk you tolerate and becomes a capability you can actually use.