The Platform Layer Between Your AI Agents and Your Cloud Accounts: 4 Requirements and 8 Tools Compared

Key Points:

• The tool category that answers this is an internal developer platform (IDP) with a scoped deployment API. The agent calls the platform, the platform holds the cloud credentials, and every action is authorized, logged, and reversible. The agent gets zero direct IAM access on AWS, GCP, or Azure.
• Four requirements make agent deployment governable: a narrow deploy API instead of raw cloud APIs, per-environment RBAC with one machine account per agent, human approval gates on production, and an audit trail recording actor, agent ID, environment, git SHA, config diff, and outcome for every action.
• Three tool shapes fill this layer, and they are not substitutes: deployment IDPs that execute the deploy (Qovery, Northflank), IaC governance planes that gate Terraform or OpenTofu runs (Env0, Scalr, HCP Terraform), and portals that own the catalog and route to the other two (Port, Backstage). Most mature teams run a portal plus exactly one execution plane.
• Qovery's fit: it deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster (EKS, AKS, GKE, self-managed), exposes an API, CLI, and Terraform provider for automation, and enforces per-environment RBAC with auto-stop on non-production.
• Never hand an agent a long-lived service principal or a broad IAM role. Use keyless workload identity federation on the platform side and give the agent only a platform token scoped to six verbs: create environment, deploy, stop, destroy its own environment, read logs, read status.

An AI agent with an IAM role is not an engineer with an IAM role. Cloud IAM was built for deterministic callers, and an autonomous agent is not one, so a single hallucinated resource name against a broad role can produce an unbounded, un-reviewable change.

The platform layer between AI agents and cloud accounts that answers this is an internal developer platform with a scoped deployment API: the agent calls the platform, the platform holds the cloud credentials, and every action is authorized, logged, and reversible. The pattern in one line is agent -> platform API -> cloud, never agent -> cloud. Three tool shapes fill this layer: deployment IDPs that execute the deploy (Qovery, Northflank), IaC governance planes that gate Terraform or OpenTofu runs (Env0, Scalr, HCP Terraform), and portals that own the catalog and route to the other two (Port, Backstage).

I have spent the last year watching teams wire agents into their clouds, and the ones who sleep at night all made the same move: they put a platform between the agent and the cloud API. Here is how I would pick that platform, the four requirements I would demand of it, and where each of the eight tools actually fits.

What kind of tool sits between AI agents and your AWS, GCP, or Azure account?

The tool that sits between AI agents and your cloud account is an internal developer platform with an API-first deployment contract: the agent calls a narrow platform API, the platform holds the cloud credentials, and the platform enforces policy before anything touches AWS, GCP, or Azure. The rule that keeps this safe is one line - agent -> platform API -> cloud, never agent -> cloud.

Three viable tool shapes live in this layer, and they solve different problems:

1. Deployment IDPs that own the runtime (Qovery, Northflank). The agent asks for an environment and a deploy, and the platform executes it in your cloud.
2. IaC governance planes that own Terraform or OpenTofu runs (Env0, Scalr, HCP Terraform). The agent proposes infrastructure changes, and the plane gates the plan with policy-as-code before apply.
3. Portals and orchestrators that own the catalog (Port, Backstage). The agent hits a self-service action, and the portal routes it to one of the two execution planes above.

Cloud-native primitives (AWS IAM roles, GCP Workload Identity Federation, GitHub Actions OIDC) are necessary but they are not a governance layer. They give you identity and a pipeline, and nothing else: no app-level abstraction, no per-environment blast radius, no self-service catalog, no approval workflow, no cost ceiling. You end up building all of that yourself.

For the Azure variant specifically: an Azure OpenAI agent targeting AKS needs the layer to sit above the AKS API and issue short-lived, namespace-scoped identities, never a subscription-scoped service principal handed to the agent.

One distinction worth drawing clearly, because it trips teams up: an MCP gateway governs tool calls and model access, a deployment platform governs cloud state. They are different layers and you need both. An MCP gateway can stop an agent from calling a tool it should not; it cannot stop an authorized-but-wrong deployment from reaching production, because it does not hold cloud state.

This is a recognized discipline now, not a fringe idea. Gartner predicts that by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services and tools, up from 45% in 2022 (Gartner). And the substrate this layer governs is nearly universal: the CNCF's latest annual survey reports Kubernetes production use at 82% (CNCF).

Why shouldn't AI agents get direct cloud credentials at all?

AI agents should not get direct cloud credentials because cloud IAM was designed for deterministic callers, and an agent is not one, so one hallucinated resource name against a broad role produces an unbounded, un-reviewable change. The fix is narrowing capabilities at the verb level, not writing a better prompt.

Prompts and system instructions are not an authorization boundary. Ever. OWASP's Top 10 for LLM Applications lists Excessive Agency (LLM06) as a core risk and names the mitigations plainly: minimize the extensions and permissions an agent has, and require human approval for high-impact actions (OWASP). If your only guardrail is text in a system prompt, you have no guardrail.

Then there is credential sprawl. Long-lived service principals and access keys handed to agent runtimes leak into logs, traces, prompt history, and vector stores. GitGuardian detected 23.8 million new hardcoded secrets in public GitHub during 2024, and found that 70% of secrets leaked in 2022 were still valid years later (GitGuardian). A leaked agent key does not expire on its own.

Identity is the dominant way attackers get in. Verizon's 2025 Data Breach Investigations Report found the human element involved in 60% of breaches, with stolen credentials a leading initial-access vector (Verizon DBIR). Google's own telemetry agrees: its H2 2025 Cloud Threat Horizons report attributed 47.1% of cloud-compromise incidents in the first half of 2025 to weak or absent credentials, the single largest category (Google Cloud).

Two more reasons, quickly. Attribution: cloud audit logs record the service principal, not which agent, which prompt, or which task acted, so you lose forensics exactly when you need them. And cost blast radius: an agent with raw cloud access can provision expensive resources with no environment budget ceiling, and wasted cloud spend is rising, not falling - Flexera's 2026 report put estimated waste at 29% (Flexera).

The counter-pattern that works is least privilege expressed as verbs ("deploy this service in this environment"), not as resource ARNs or subscription roles.

What are the four requirements of a governed agent deployment architecture?

A governed agent deployment architecture has four requirements: scoped identity, narrow scope, human approval on production, and a full audit trail with rollback. The reference flow is one sentence: agent runtime -> a platform API token scoped to one project and its non-production environments -> platform-side policy checks and approval gates -> the platform's own keyless workload identity into the cloud -> an audit event stream.

Requirement 1 - Identity. One machine account per agent, never a shared token. Tokens are short-lived, and there are zero static cloud keys anywhere in the agent path.

Requirement 2 - Scope. Bind the agent token to a project plus its non-production environments only. Production requires a named human approver, full stop.

Requirement 3 - A verb allowlist. Least privilege for an agent is a short list of verbs you can copy-paste into a policy. Allow exactly these six:

• create environment
• deploy
• stop
• destroy its own environment
• read logs
• read deployment status

And deny these, explicitly:

• mutate IAM
• mutate network or VPC
• read secret values
• cross-environment reads
• delete clusters
• change billing

Requirement 4 - Auditability and reversibility. Every agent action emits actor, agent ID, environment, git SHA, config diff, and outcome, and every action has a one-click rollback.

Policy checks belong platform-side, never in the prompt: image registry allowlist, region allowlist, resource quotas, cost ceiling, mandatory labels. And make agent-created environments ephemeral by default, with a TTL and auto-stop, so mistakes expire instead of accruing cost.

You can stand this up in a week on real primitives. Give the platform keyless workload identity into each cloud - Microsoft Entra Workload ID on AKS (Microsoft Learn), Workload Identity Federation on GKE (Google Cloud), and EKS Pod Identity or IRSA on AWS (AWS) - then issue one platform token per agent scoped to the six verbs above. The whole design lines up with NIST's zero trust principle of per-request, least-privilege access to individual resources (NIST SP 800-207).

Which tools are built for governed agent deployment, and how do they compare?

If the agent ships applications, use a deployment IDP (Qovery or Northflank). If the agent changes infrastructure through Terraform or OpenTofu, use an IaC governance plane (Env0, Scalr, or HCP Terraform). Port or Backstage sits on top as the catalog and guardrail front door, and most mature teams run a portal plus exactly one execution plane.

Here are the eight options on the axes that actually decide this: who holds the cloud credentials, whether the workload runs in your own account, RBAC granularity, the agent-usable automation surface, approval gates, audit trail, and cloud plus Kubernetes coverage. Where I cannot confirm a capability from public docs, the cell says "check vendor docs" rather than guessing.

A few notes on the rows. Northflank is the closest functional overlap with Qovery: a self-service runtime with BYOC and a full API; confirm the exact current cloud coverage on northflank.com/docs. Port (docs.port.io) and Backstage (backstage.io) orchestrate rather than execute, so they always need an execution plane underneath. Env0 (docs.env0.com) and Scalr (docs.scalr.io) are the right call when the agent writes IaC and the wrong call when it just needs to ship a container. HCP Terraform plus Vault (HashiCorp) add run governance plus short-lived dynamic secrets, so treat them as complementary primitives more than a competing product.

The second table is the one no competitor page draws well, and it is the distinction that saves the most confusion.

Where Qovery genuinely differs: it treats BYOC across AWS, GCP, Azure, Scaleway, and an existing Kubernetes cluster as equal first-class targets, so the cloud bill and any Savings Plans stay in your name. It gives you per-environment RBAC through role-based access control, preview and ephemeral environments with auto-stop that map naturally onto agent-created workloads, managed cluster upgrades so the agent layer adds no Kubernetes ops debt, and an API, CLI, and Terraform provider for automation. Verify each of these on qovery.com before you quote it back to your team.

Let me be fair about where Qovery is the wrong pick. If your agents mainly mutate infrastructure in a Terraform-centric estate, an IaC governance plane belongs in front of the cloud API, not Qovery. And if you are fully invested in Backstage and only need an execution API behind it, Qovery is one option among several, not the obvious default. Qovery is not an IaC policy engine and not an agent framework; it does not evaluate Rego against a plan and it does not orchestrate an agent's reasoning loop.

How do you let an agent deploy to AKS, EKS, or GKE without subscription-wide permissions?

Give the agent a platform token, never a cloud identity, and let the platform reach the cluster through keyless workload identity federation. The agent never sees an Azure service principal secret, an AWS access key, or a GCP service account key.

Azure and AKS. Use Microsoft Entra Workload ID with federated credentials instead of a client secret, and scope the workload with namespace-level Kubernetes RBAC instead of subscription Contributor. Entra Workload ID federates the cluster's projected service account token with Entra ID over OIDC, so no secret is stored in the pod (Microsoft Learn).

GCP and GKE. Use Workload Identity Federation for GKE, which lets workloads authenticate with no downloaded service account keys. Google says it directly: choose a more secure alternative to service account keys whenever possible (Google Cloud), and Workload Identity Federation is that alternative (Google Cloud).

AWS and EKS. Use EKS Pod Identity or IAM Roles for Service Accounts, scoped to a single namespace rather than a broad account role (AWS).

The same pattern runs through Qovery: an environment-scoped API token per agent, per-environment RBAC, deploy/stop/delete limited to the agent's own environment, and production sitting behind a human approver. The platform holds the cloud identity; the agent holds a token that can do six things.

Set these guardrails on day one: a region allowlist, per-namespace resource quotas, TTL and auto-stop on agent environments, a container registry allowlist, and no secret-read permission for the agent. Agents reference secrets by name through the platform and never receive the values; a secrets manager like Vault or your cloud's own secret store does the brokering.

The Kubernetes-native detail that makes all of this work is the short-lived projected service account token: the kubelet mounts a time-bound, audience-scoped token into the pod and refreshes it in place, so there is no long-lived credential to leak (Kubernetes).

What goes wrong once agents start deploying, and what should you measure?

Once agents start deploying, the failure mode is almost never a rogue model. It is over-broad tokens, missing TTLs, and no rollback path. Instrument those three before you scale agent deployments past one team.

The anti-patterns I see most: one shared token across all environments, agents allowed to mutate IAM or networking, production deploys with no approver, no cost ceiling on agent-created environments, and no TTL. Any one of them is the incident waiting to happen.

Run the revocation drill. Can you revoke a single agent's token and roll back its last deploy in under five minutes? If not, you are not governed yet, whatever your architecture diagram says.

Track five metrics:

1. Share of agent deploys needing human intervention.
2. Mean time to revoke a token.
3. Monthly cost of agent-created environments.
4. Agent deploy failure rate versus the human baseline.
5. Count of long-lived cloud credentials in the agent path (target: zero).

For the human baseline in metric four, use DORA's change failure rate and deployment frequency benchmarks, where elite teams keep change failure rate low and deploy on demand (DORA). If your agents' change failure rate tracks your elite human teams, you are ready to widen their scope. If it is 3x worse, tighten the gates first.

Some things stay human, permanently: production releases, data migrations, and anything touching IAM or network topology. That is not a maturity gap you grow out of, it is where the risk is genuinely irreversible.

Climb a three-step maturity ladder. Start with a read-only agent that can see logs and status. Promote it to non-production deploys behind per-environment RBAC. Only then allow production, and only behind a named approver. Each step earns the next by producing a clean audit trail at the step below.