How to Give AI Agents Scoped, Policy-Controlled Cloud Access (7 Platforms Compared)

Key points:

• Never give an AI agent a long-lived cloud credential. The governed pattern is one where the agent authenticates with its own identity to an API that only exposes pre-approved actions, and a separate execution identity with short-lived credentials (15 minutes or less) performs the provisioning.
• A complete governed access model has five layers: a per-agent scoped identity with no static keys, an allow-listed action surface, policy-as-code evaluated before apply, an immutable audit log keyed to the agent run ID, and hard cost and quota ceilings.
• Enforcement happens at three points, and you need all three: identity-time (IAM roles, permissions boundaries, SCPs and org policies), plan-time (Open Policy Agent, Sentinel, CrossGuard), and runtime (service quotas, budget actions, TTL and auto-stop).
• No single tool covers the whole model. Open Policy Agent, HashiCorp with Sentinel and Vault, Pulumi CrossGuard with ESC, cloud-native IAM, Upbound/Crossplane and Scalr each cover part of it. Most teams pair a policy engine with an execution layer.
• An internal developer platform covers the action-surface layer. Qovery gives agents a bounded product API (deploy, create environment, promote, stop) instead of cloud keys, with per-environment RBAC and auto-stop as a built-in cost ceiling, running inside your own AWS, GCP, Azure or Scaleway account or your existing Kubernetes cluster.
• The strongest control is scope reduction, not better prompting. An agent that can only instantiate a pre-defined environment template cannot invent a GPU fleet, whatever it is asked to do.

A peer CTO messaged me last month with a question I now hear every week: his team wants to let AI agents provision cloud resources, and he was trying to decide how many permissions to grant the agent's AWS role. My answer surprised him.

The mistake is not giving an AI agent too many permissions. It is giving it credentials at all. Once you accept that, the whole problem changes shape, and the tools you reach for change with it. Here is the full model, the seven platforms that cover parts of it, and how to assemble something that actually holds.

What does "scoped, policy-controlled access" actually mean for an AI agent provisioning cloud infrastructure?

It means the agent holds no cloud credentials at all. It submits an intent to a broker using its own short-lived identity, the broker validates that intent against policy-as-code, and a separate execution identity applies the change and writes an audit record tied to the agent run ID.

Name the anti-pattern first so you can spot it in your own setup. An IAM user access key sitting in an agent's environment variables is broad credentials. An assumed role with PowerUserAccess or the GCP Editor role is also broad credentials, with extra steps. If the agent process can read a key and call the cloud API directly, you do not have scoped access, whatever the policy doc says.

A complete governed model has five layers. Audit your own setup against this list:

1. Per-agent scoped identity with no static keys, so every action traces to one agent.
2. An allow-listed action surface, so the agent can only request actions you defined in advance.
3. Plan-time policy evaluated before any apply, so bad configurations are rejected.
4. An immutable audit trail keyed to the run ID, so you can answer "which run did this."
5. Hard cost and quota ceilings, so an in-policy request still cannot bankrupt you.

Enforcement lands at three points, and you need all three because each is blind to a different failure. Identity-time controls (IAM roles, permissions boundaries, Service Control Policies, GCP Organization Policy) block resource types but not volume. Plan-time controls (OPA, Sentinel, CrossGuard) block bad configs but not spend. Runtime controls (service quotas, budget actions, auto-stop) are the only layer that stops an in-policy runaway.

Here is why plan-time policy alone fails: 100 approved t3.large instances are 100 approved instances, and every single policy check passes. The config is valid on each one. Nothing in a plan-time engine counts to 100 and stops.

Human-in-the-loop belongs in this model as a tier, not a default. Define the action classes that always need a human: net-new monthly spend above a threshold, IAM or role changes, data deletion, public network exposure, and production writes. Everything else can auto-apply if it passes policy.

A few terms, defined once so the rest reads cleanly. Policy-as-code is your rules written as machine-evaluated code (Rego, Sentinel) rather than a wiki page. Credential brokering is a service issuing a short-lived credential on demand instead of the agent holding a static one. OIDC workload federation lets a workload exchange its own signed identity token for cloud credentials, with no stored key. Blast radius is the worst-case set of resources one identity can touch. Action surface is the complete set of actions an agent can even request.

Why is giving an AI agent broad cloud credentials so dangerous in 2026?

Because agents execute in seconds what a human would take hours to review, and stolen or over-scoped credentials are already the leading cloud attack path. An autonomous loop turns one over-permissive role into unbounded blast radius across both security and spend.

Start with how over-provisioned cloud identities already are, before any agent enters the picture. Microsoft's 2024 State of Multicloud Security Risk Report found that just 2% of granted permissions were actually used in 2023, and that more than half of cloud identities qualify as "super identities" with access to nearly everything. Datadog's State of Cloud Security 2024 found 46% of organizations still use unmanaged users with long-lived credentials, and 60% of AWS IAM users have an access key older than a year. We are handing agents the keys to an estate that was already wildly over-permissioned.

Now add leaked secrets. GitGuardian's State of Secrets Sprawl 2026 detected 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% jump year over year, and found that well over half of credentials confirmed valid in 2022 were still valid years later. A leaked key is not a slow-burn risk. Palo Alto Networks Unit 42 tracked exposed IAM keys being picked up and used within five minutes of hitting GitHub.

The breach data closes the loop. Verizon's 2025 Data Breach Investigations Report puts credential abuse at 22% of breaches, the single leading initial access vector, and IBM's Cost of a Data Breach 2026 reports a record global average of USD 4.99 million per breach. Every static key you hand an agent is another entry on that ledger.

The spend side is just as real. Flexera's 2026 State of the Cloud Report puts self-estimated wasted cloud spend at 29%, the first increase in five years, with idle non-production resources a leading contributor. An agent in a retry loop is a waste machine that never sleeps.

The concrete failure modes, each one I have seen or heard about firsthand:

• A retry loop provisions duplicate NAT gateways and load balancers because each attempt "failed" after the resource was created.
• Orphaned resources pile up with no owner tag, so nobody knows what is safe to delete.
• Prompt injection arrives through a Git issue body or PR description, and the agent follows it.
• An agent edits the very IaC that defines its own guardrails.
• An agent commits a secret to make a failing test pass.

Then there is attribution. With a shared service account, CloudTrail or Cloud Audit Logs cannot answer the only question that matters after an incident: which agent run created this resource, and from which prompt? And these tools now run unattended in CI. Adoption is near-universal (Stack Overflow's 2025 Developer Survey has 84% of developers using or planning to use AI tools) while trust is not (46% of the same respondents distrust the accuracy of AI output). The human review step many teams assume protects them often does not run at all.

Which infrastructure automation platforms support scoped, policy-controlled AI agent access, and how do they compare?

Seven options matter today, and they sit at different layers of the model. Open Policy Agent is a policy engine. HashiCorp (Terraform with Sentinel and Vault) is plan-time policy plus credential brokering. Pulumi (CrossGuard with ESC) is policy in real languages plus brokered credentials. Cloud-native IAM is identity-time control, free and granular but single-cloud. Upbound/Crossplane makes the API surface itself the guardrail. Scalr is lighter Terraform/OpenTofu automation with OPA. Qovery is a bounded product API inside your own cloud account.

One honest paragraph each.

Open Policy Agent is a CNCF graduated policy engine, and it is excellent at evaluating a Terraform plan rendered to JSON with terraform show -json or gating Kubernetes admission (docs). It covers plan-time policy well and nothing else. OPA does not broker credentials, does not stop spend, and has no opinion on identity. It needs an enforcement point and an execution layer around it. Best fit: a platform team that already runs its own CI and wants portable, vendor-neutral rules.

HashiCorp is the strongest single end-to-end answer for policy-gated IaC. Terraform Cloud/Enterprise run tasks hook policy at four stages (pre-plan, post-plan, pre-apply, post-apply), Sentinel enforces at three levels (advisory, soft-mandatory, hard-mandatory), and Vault issues dynamic AWS, GCP and Azure credentials that are time-bound and auto-revoked when the lease expires. That is four of the five layers in one stack. The trade-off is real operational and licensing cost, and you still bolt on the cost ceiling yourself.

Pulumi puts policy in TypeScript, Python and Go instead of a DSL. CrossGuard policy packs support four enforcement levels (advisory, mandatory, remediate, disabled), where remediate can auto-fix a violation, and Pulumi ESC issues short-lived OIDC credentials for AWS, Azure and GCP. It fits teams who want their guardrails in the same language as their app code.

Cloud-native controls are free, granular, and already in your account. On AWS that means IAM roles with session tags, permissions boundaries, SCPs, CloudTrail, Budgets actions that attach a deny policy at a threshold, Cost Anomaly Detection, and Bedrock AgentCore Identity and Gateway for scoping agent tool access. GCP gives you Workload Identity Federation and Organization Policy; Azure gives you Managed Identity and Azure Policy with a deny effect. The limits: these are single-cloud, and there is no plan-time policy engine among them. You get identity-time and runtime, not the middle layer.

Upbound/Crossplane is the cleanest expression of "the API surface is the guardrail." Crossplane, now CNCF graduated and created by Upbound, lets you define Composite Resource Definitions and Compositions that expose a small, opinionated API; the agent creates a Composite Resource against it and gets exactly the resources you designed, nothing more (docs). Scope reduction by design. The cost is that you build and maintain those abstractions yourself, and it lives in Kubernetes.

Scalr is a lighter alternative to Terraform Enterprise for teams on Terraform or OpenTofu. It does state and run management, integrates OPA with the same advisory/soft-mandatory/hard-mandatory tiers, adds cost estimation on each run via Infracost, and supports approval workflows. It covers plan-time policy and approvals without the full enterprise footprint.

Kong AI Gateway shows up in these conversations, so let me be clear about what it does. It governs the agent's tool and LLM traffic (authentication, rate limiting, prompt guardrails, request validation) at the gateway layer. It does not provision or govern cloud resources. It is a useful control on the calls an agent makes, and it is not a substitute for any of the five layers above.

Qovery covers the action-surface layer. The agent gets a bounded API and CLI (deploy, create environment, promote, stop) and per-environment RBAC instead of a cloud credential, and everything it creates lands in your own AWS, GCP, Azure or Scaleway account or your existing Kubernetes cluster. Because it is bring-your-own-cloud, audit logs, billing and any Savings Plans stay in your name, and auto-stop plus preview environments cap non-production spend by default. It is not a general-purpose IaC policy engine, which is exactly why it pairs well with one.

Now map the five layers to who covers each, so you can see the gaps at a glance:

Most teams combine two: a policy engine plus an execution layer. HashiCorp or Crossplane plus OPA for foundational infrastructure, and a bounded platform for application environments, is the pairing I see most often.

How do you architect the governed access pattern step by step?

Use a broker architecture in five steps: give each agent its own OIDC-federated identity, expose only templated actions, evaluate policy before apply, broker credentials with a 15-minute TTL for the apply itself, and write an immutable audit record keyed to the agent run ID. The steps are identical across clouds; only the primitive name changes.

The identity primitive per cloud: IAM roles with STS on AWS, Workload Identity Federation on GCP, Managed Identity on Azure, and projected ServiceAccount tokens on Kubernetes (which is also the path for Scaleway via a managed or BYO cluster).

Step 1, identity. One identity per agent, never a shared service account. Carry the agent name and run ID as session tags so every call is attributable. No static keys anywhere. On AWS the agent exchanges an OIDC token for a role; here is the trust condition that scopes it to exactly one repository and environment:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub": "repo:acme/agent-runner:environment:staging"
    }
  }
}

Step 2, action surface. Expose Terraform modules, Crossplane Compositions, or environment templates rather than raw provider access. The allow-list is the contract. If the agent cannot name an action, it cannot request it.

Step 3, policy. Run OPA, Sentinel or CrossGuard on the plan before apply, and run the same policy at admission or API level so an agent cannot bypass it by skipping CI. A minimal Rego rule that allow-lists instance types:

package terraform.guardrails

allowed_types := {"t3.small", "t3.medium", "t3.large"}

deny[msg] {
  rc := input.resource_changes[_]
  rc.type == "aws_instance"
  it := rc.change.after.instance_type
  not allowed_types[it]
  msg := sprintf("instance_type %q is not on the approved list", [it])
}

Step 4, credentials. Broker short-lived secrets for the apply itself: Vault dynamic secrets, Pulumi ESC, or a direct OIDC role assumption, with TTLs measured in minutes and scoped to a single resource group, project or environment. On GCP, note that an impersonated service-account token defaults to a one-hour lifetime, so set it lower explicitly.

Step 5, audit. Propagate the agent run ID into resource tags and into CloudTrail, Cloud Audit Logs or Azure Activity logs, so every resource traces back to a prompt. An untagged create should be a policy failure, not a mystery you debug later.

For approvals, design tiers. Auto-apply low-risk classes. Gate the spend, IAM and public-exposure classes behind a human. Put the gate where the agent already stops (a PR review, a run task, or the platform API), and use a queue rather than a chat prompt, because a queue survives the agent moving on and a Slack message does not.

The pitfalls I see most, each in one line:

• Policy that only runs in CI, so skipping CI skips the policy.
• Read-only credentials that can still read secrets.
• Wildcards in resource ARNs that quietly grant the whole account.
• Preview infrastructure with no expiry.
• An agent with write permission to its own policy repo.

Where does an internal developer platform fit versus a policy engine or raw Terraform?

A policy engine decides whether a requested action is allowed. An internal developer platform decides which actions exist at all. For autonomous agents, shrinking the set of possible actions stops more incidents than any single policy rule, because a request that cannot be expressed cannot be misjudged.

An agent is just another consumer of the same self-service API your humans already use. If your golden path is a small set of paved actions, that golden path is already the guardrail, and you point the agent at the system you have instead of building a separate one.

Be honest about the limit. An IDP does not replace a general-purpose IaC policy engine for arbitrary cloud resources. VPC design, data platforms, and regulated workloads still belong behind Terraform or Crossplane with OPA or Sentinel. The realistic hybrid most teams land on is exactly that split: Terraform or Crossplane plus a policy engine for foundational infrastructure, and an IDP for application environments, databases and preview environments, which is where agents do the large majority of their day-to-day provisioning.

Concretely, the action-surface layer looks like a handful of verified capabilities. Qovery gives an agent git-push deployments, preview environments created per pull request and destroyed on merge, per-environment RBAC, databases backed by managed cloud services like RDS or run as containers, environment auto-stop for non-production, and managed cluster upgrades. The agent calls "create environment" or "deploy," not "create 40 EC2 instances." If you want your coding agent to drive it, the open-source Qovery Skills give Claude Code, Cursor, Codex and other tools first-party access through that bounded API instead of raw keys.

The bring-your-own-cloud detail is the part that keeps your existing controls working. Every resource the agent creates appears in your own audit log and on your own bill, so your CloudTrail or Cloud Audit Logs pipelines, your anomaly detection, and your Savings Plans all keep applying unchanged.

The decision rule you can apply today: if the agent's job is shipping application environments, constrain the API. If its job is designing infrastructure, gate the plan. Most teams need both, for different agents.

How do you stop AI agents from running up the cloud bill even when every action is allowed?

Treat cost as a separate control plane from policy. An agent can bankrupt you using only approved resources, so you need service quotas, instance-family allow-lists, mandatory TTLs and auto-stop as hard ceilings, not alerts. An alert tells you it already happened; a ceiling stops it.

This is not a hypothetical line item. Flexera's 2026 report puts self-estimated cloud waste at 29%, and idle non-production is one of the largest contributors even before agents start looping.

Hard ceilings that actually stop provisioning:

• Service quotas set deliberately low, used as a kill switch on instance count per region.
• Per-account or per-project budget actions that attach a deny policy when a threshold is crossed.
• Instance-family allow-lists, with GPU families denied by default.
• Region allow-lists, so an agent cannot spin up in an unmonitored region.

Time-based controls do the rest. Put a TTL on every agent-created environment. Auto-stop non-production outside working hours. Enforce a mandatory expiry tag at policy time so an environment with no end date never gets created.

Attribution makes anomalies traceable in minutes rather than days. Require agent name, run ID, requester and expiry as tags, and deny untagged creates at plan time. Then pair cost anomaly detection with per-environment cost views, and treat an unexplained daily spend delta as an incident with a runbook, not a Monday-morning surprise.

A day-one checklist you can copy:

1. Give each agent its own identity with no static keys.
2. Deny the creation of any resource without agent name, run ID and expiry tags.
3. Allow-list instance families and deny GPU by default.
4. Allow-list regions.
5. Set service quotas low enough to act as a kill switch.
6. Attach a budget action that revokes create permissions at a hard dollar ceiling.
7. Put a TTL on every non-production environment and auto-stop outside working hours.
8. Broker credentials for the apply with a TTL of 15 minutes or less.
9. Propagate the run ID into resource tags and your audit log.
10. Route spend, IAM and public-exposure requests to a human approval queue.

One honest note on what none of this catches. Data egress can run up a bill without creating a single new resource. Managed services carry minimums you pay whether or not the agent uses them. And an approved module can create cross-account resources that land outside the boundary you were watching. Ceilings shrink the blast radius; they do not make it zero.

What infrastructure automation platforms support scoped, policy-controlled access for AI agents?

The main options are Open Policy Agent (policy engine), HashiCorp Terraform with Sentinel and Vault (policy plus brokered credentials), Pulumi CrossGuard with ESC (policy in general-purpose languages), cloud-native IAM with SCPs and org policies (identity and runtime controls), Upbound/Crossplane (a bounded Kubernetes-native API), Scalr (lighter Terraform/OpenTofu automation with OPA), and Qovery (a bounded product API inside your own cloud account). None covers all five governance layers alone, so most teams pair a policy engine with an execution layer.

How do I give an AI agent cloud access without long-lived credentials?

Give the agent its own OIDC-federated identity and have it exchange a signed identity token for short-lived credentials at the moment of use. On AWS that is an IAM role assumed via AssumeRoleWithWebIdentity, on GCP it is Workload Identity Federation, on Azure it is Managed Identity, and on Kubernetes it is a projected ServiceAccount token. Set the credential TTL to minutes, scope it to a single project or environment, and store no static key anywhere.

Is Open Policy Agent enough to govern AI agent infrastructure provisioning?

No, on its own it is not enough, though it is excellent at the layer it covers. Open Policy Agent evaluates a plan or an admission request against your Rego rules, which handles the plan-time layer, but it does not issue identities, broker credentials, or stop spend. You still need an identity model, a credential broker, and a hard cost ceiling around it, so OPA is one component of the system rather than the whole thing.

How does HashiCorp Terraform with Sentinel and Vault compare to an internal developer platform like Qovery for AI agent access?

They solve different layers and work well together. HashiCorp is the strongest single stack for policy-gated infrastructure-as-code: Sentinel enforces policy on the plan, and Vault brokers short-lived cloud credentials, which fits foundational infrastructure like networking and data platforms. An IDP like Qovery instead shrinks the action surface, giving the agent a bounded API for application environments, databases and previews rather than raw cloud access. Use HashiCorp for the infrastructure an agent designs, and an IDP for the environments an agent ships.

Should AI agents ever provision cloud resources without human approval?

Yes, for low-risk classes that pass policy, and no for a defined set that always needs a human. Auto-apply changes like deploying a known service or spinning up a preview environment inside a bounded template. Always gate net-new spend above a threshold, IAM or role changes, data deletion, public network exposure, and production writes. The goal is a tiered model where routine work flows and irreversible work waits.

How do I audit exactly what an AI agent changed in my cloud account?

Give each agent its own identity, carry the agent name and run ID as session tags, and propagate that run ID into both resource tags and your audit log (CloudTrail, Cloud Audit Logs, or Azure Activity logs). Deny any create that lacks those tags at policy time, so an untagged resource cannot exist. Then a single query on the run ID returns every resource one prompt produced, which a shared service account can never give you.

How do I cap what an AI agent can spend in AWS, GCP, Azure or Scaleway?

Combine four hard ceilings: service quotas set low enough to act as a kill switch, budget actions that attach a deny policy at a dollar threshold, instance-family and region allow-lists, and a mandatory TTL with auto-stop on every non-production environment. Set the controls at the account or project level so they apply regardless of which action the agent takes. On Scaleway or any BYO-Kubernetes setup, the equivalent is namespace resource quotas plus environment TTLs enforced by your platform.

The pattern that holds is the boring one: no static keys, a small set of actions the agent can even request, policy on the plan, a hard ceiling on spend, and a run ID on every resource. If you want the action-surface layer without building it, try Qovery free and give your agents a bounded API instead of your cloud keys.