How to Give AI Agents Scoped Cloud Permissions: 7 Platforms That Actually Enforce It

Key Points:

• Never give an AI agent a long-lived cloud access key. The working pattern is three-party: the agent proposes a change, a platform holding its own short-lived scoped identity executes it, and a policy engine (Sentinel, OPA/Rego, Pulumi CrossGuard, Cedar, or Kyverno) evaluates it before any cloud API call is made.
• A governed access model needs five controls: short-lived federated identity via OIDC/STS, policy-as-code evaluated pre-apply, a constrained catalog of approved resource shapes, human approval on the privileged set (IAM, networking, data deletion, production), and an immutable audit trail attributing every cloud API call to the agent identity. Miss one and you have slow broad access, not scoped access.
• Seven platforms enforce this today: HCP Terraform (Sentinel or OPA policy sets + dynamic provider credentials), Spacelift (OPA/Rego policies by decision point), Pulumi (CrossGuard + ESC), env0 (OPA + approval flows), AWS Service Catalog with launch constraints, Crossplane or ACK with Kyverno admission policies, and Qovery as an internal developer platform layer.
• The real design choice is where the guardrail sits. IaC platforms govern the plan, so the agent can author any resource and your policy rules have to catch it. Internal developer platforms govern the interface, so an unsafe request has no representation. Run both, with AWS SCPs and IAM permissions boundaries (or the GCP and Azure equivalents) as the account-level floor.
• Qovery runs inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster. The agent authenticates with a scoped Qovery API token under per-environment RBAC and can deploy apps, open ephemeral preview environments, and scale services without ever receiving an AWS access key, a GCP service account key, or an Azure client secret.

An AI agent holding a long-lived AWS access key is an intern with root, working at machine speed, with no memory of what it did yesterday. The fix is not a tighter IAM policy on the agent. The agent should never hold cloud credentials at all. A platform with its own short-lived scoped identity executes on the agent's behalf, and a policy engine checks the request before it reaches a single cloud API.

I have spent 15 years building on cloud and the last year interviewing platform leads about the same knot: the agents are already writing infrastructure code, and nobody wants to hand them the keys to the account. Below is the five-control pattern that makes agent access defensible, and a straight comparison of the seven platforms that enforce it. If you already run Terraform at scale, I will tell you to reach for HCP Terraform or Spacelift before anything else. This is a buyer's guide with a verdict, not a pitch.

Why is giving an AI agent long-lived cloud credentials the wrong starting point?

Handing an AI agent a long-lived cloud access key gives a non-deterministic process durable, directly exploitable reach over your account, and none of the controls you already trust apply to it. MFA, key rotation, and pull request review were built for humans and deterministic CI pipelines. The credential belongs to the executor, never to the model.

• Agents are non-deterministic. The same prompt can produce different API calls across runs, so you cannot pre-audit behavior the way you review a Terraform plan diff in a PR. You are trusting a distribution of outcomes, not a fixed script.
• Prompt injection turns any credential the agent holds into an exfiltration path. An agent reading a GitHub issue, a log line, or a scraped web page can be instructed to create an IAM user or open a security group. Prompt injection is ranked LLM01:2025, the number one risk in the OWASP Top 10 for LLM Applications, and giving an agent more reach than its task needs is exactly the Excessive Agency (LLM06:2025) failure the same list warns about.
• Static keys are still how attackers get in. Compromised credentials were the initial access vector in 22% of breaches in the 2025 Verizon DBIR, and a leaked AWS key committed to a public repo drew attacker reconnaissance within about four minutes in Unit 42's controlled test. A key an agent can leak is a key an attacker will use before you finish lunch.
• Over-permissioned, long-lived identities are already the default before agents arrive. Datadog found that 59% of AWS IAM users still carry an access key older than a year, alongside a similar picture for GCP service accounts and Entra ID apps. Agents pour machine throughput onto a foundation that was already leaking.

So the question to ask is not "which IAM policy do I attach to the agent." It is "which system executes on the agent's behalf under its own scoped, short-lived identity." There are two credible places to put the guardrail: govern the plan (an IaC platform plus a policy engine) or govern the interface (a developer platform or service catalog). The rest of this article works through both.

The one line to quote: the agent gets a token for a system that holds credentials, never the credentials themselves.

What does a governed access model for an AI agent actually require?

A governed access model requires five concrete controls, and any platform missing one of them is not giving you scoped access. Those controls are short-lived federated identity, pre-apply policy-as-code, a constrained resource catalog, human approval on privileged operations, and per-agent audit attribution.

• Control 1, short-lived workload identity. OIDC federation into a role via sts:AssumeRoleWithWebIdentity (default one-hour session, twelve-hour maximum), or IAM Roles Anywhere. The GCP equivalent is Workload Identity Federation; the Azure equivalent is Workload Identity; on Kubernetes it is IRSA with projected service-account tokens. No static key anywhere in the chain.
• Control 2, policy-as-code evaluated before apply. OPA/Rego, HashiCorp Sentinel with its advisory / soft-mandatory / hard-mandatory enforcement levels, Pulumi CrossGuard's advisory / mandatory / remediate levels, AWS CloudFormation Guard, Cedar with Amazon Verified Permissions, or Kyverno and OPA Gatekeeper at Kubernetes admission. The check has to run before apply, not as an alert after the resource exists.
• Control 3, a constrained surface. A service catalog, a no-code module registry, or a platform abstraction so the agent can only express approved resource shapes, regions, instance sizes, and tags. This is what makes policy-as-code for AI agents tractable instead of an infinite game of rule-writing.
• Control 4, human-in-the-loop on the privileged set only. IAM and trust policy changes, VPC and security group changes, data deletion, and anything touching production. Everything else auto-approves so the agent stays useful. A gate on every action gets rubber-stamped within a week.
• Control 5, attribution and audit. Every cloud API call traceable to the agent identity through CloudTrail session tags plus platform run logs, with cost ceilings and drift detection alongside. On GCP that is Cloud Audit Logs; on Azure, the Activity Log.

Underneath all five sit the account-level backstops that survive a policy gap: AWS SCPs and IAM permissions boundaries, plus STS session policies that intersect rather than grant. Session policies and permissions boundaries can only narrow what a role already allows, so they fail closed. The GCP equivalents are Organization Policy and IAM Deny policies; the Azure equivalents are Azure Policy and management-group-scoped assignments.

There is also an emerging plumbing layer worth naming. When an agent reaches infrastructure through a Model Context Protocol server, the MCP authorization spec makes that server an OAuth 2.1 resource server: it holds the credential, enforces scope, and must reject any token not issued specifically for it. The agent only ever holds a scoped token for the server. That is the same principle as everything above, written into a protocol.

Run this five-question checklist against your own setup: Is there a static key anywhere the agent can reach? Does a policy run before apply or only alert after? Can the agent express a resource shape nobody approved? Does a human sign off on the privileged set? Can you attribute every cloud API call to the agent by name? Five yeses is scoped access. Anything less is broad access with extra steps.

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

Seven platforms can enforce scoped, policy-controlled provisioning for an AI agent today: HCP Terraform with Sentinel or OPA, Spacelift with OPA/Rego, Pulumi with CrossGuard and ESC, env0 with OPA, AWS Service Catalog with launch constraints, Crossplane or AWS Controllers for Kubernetes with Kyverno, and Qovery. Choose by asking two questions: where does the guardrail sit, and does the agent ever hold a cloud credential directly?

• HCP Terraform / Terraform Enterprise. Sentinel and OPA policy sets with three enforcement levels, plus dynamic provider credentials over OIDC so no static cloud keys are stored in workspaces, no-code modules as the constrained catalog, and run tasks for external checks. The default choice when Terraform is already your standard.
• Spacelift. OPA/Rego policies typed by decision point (Login, Access, Plan, Approval, Push, Trigger, Notification, Intent), Blueprints as the self-service catalog, private worker pools, and cloud integrations that assume a role instead of storing static keys. The richest policy surface of the IaC tools.
• Pulumi. CrossGuard policy packs written in TypeScript, Python, or Rego with advisory, mandatory, and remediate enforcement, and Pulumi ESC issuing short-lived dynamic cloud credentials via OIDC for AWS, Azure, and GCP. Pick it to write policy in a language your team already knows.
• env0. OPA-based policy enforcement, custom flows for pre and post hooks, templates as the catalog, approval workflows, and TTL plus cost guardrails. A strong fit for Terraform and OpenTofu teams who want lifecycle and budget controls out of the box.
• AWS Service Catalog. Launch constraints let an end user (or an agent) provision a product without holding permissions on the underlying resources, because the product launches under a role Service Catalog assumes. Pair it with permissions boundaries and CloudFormation Guard. One caveat: AWS Proton, often mentioned alongside it, is being wound down (closed to new customers since October 2025), so do not build on it now.
• Crossplane or ACK with Kyverno. Crossplane Compositions or AWS Controllers for Kubernetes turn cloud resources into Kubernetes objects, and Kyverno policies or OPA Gatekeeper constraints validate them at admission, with namespace-scoped RBAC as the boundary. The right answer when everything already runs through Kubernetes.
• Qovery. An internal developer platform running in your own cloud account, where the agent calls the Qovery API or CLI with a scoped token under per-environment RBAC, while Qovery holds the cloud credentials and provisions only the resource shapes the platform models. It governs the interface rather than the plan.

For AWS-native identity brokering specifically, Amazon Bedrock AgentCore went generally available in October 2025; its Identity and Gateway components act as a credential vault so the agent retrieves a scoped OAuth token instead of raw cloud keys. It complements the platforms above rather than replacing them.

Here is the whole field on one spine. Every cell names a concrete mechanism, never a bare yes or no.

Be fair about the choice. If you already run Terraform at scale, reach for HCP Terraform with Sentinel or Spacelift with OPA first; that is the honest recommendation and rewriting your infrastructure to avoid it would be a mistake. Qovery fits teams who want an application-level product surface instead of a plan-approval workflow. And Backstage, which people often bring up here, is an interface and catalog layer with no policy engine of its own, so it needs one of the above underneath it to actually enforce anything.

Should the guardrail live in the policy engine or in the interface the agent uses?

Both models work and they fail differently. A policy engine rejects an unsafe request after the agent has written it; a constrained interface makes the unsafe request impossible to express in the first place. The pragmatic split is a constrained interface for routine agent work and policy-gated IaC for the long tail, with SCPs and permissions boundaries underneath both.

• Policy engine model. The agent generates Terraform or Pulumi, the plan runs, Sentinel or OPA or CrossGuard evaluates it, and violations block the apply. Maximum flexibility, covers any resource, but coverage is only as good as the rules you wrote.
• Interface model. The agent calls a platform API with a fixed vocabulary (deploy an application, create an environment, scale a service, attach a managed database), and anything outside that vocabulary has no representation at all. There is nothing to write a rule against because the dangerous shape cannot be named.
• Failure mode of policy-only. Rule gaps, rule drift, and the review burden of reading agent-authored HCL that nobody has time to read. Given that 45% of AI-generated code samples introduced a security weakness in Veracode's 2025 testing, "the policy will catch it" is a bet on the completeness of your rules.
• Failure mode of interface-only. The agent cannot provision the one bespoke resource you actually need, so you keep an IaC escape hatch for the exceptions.
• The rule I give teams. Constrained interface for the routine majority of agent actions, policy-gated IaC for the remainder, SCPs and permissions boundaries (or GCP Org Policy and Azure Policy) as the floor nothing crosses.

Wherever you start, start with ephemeral environments. They are isolated, short-lived, auto-stopped, and cheap to destroy, which makes them the safest place to let an agent act. Qovery preview environments spin up per pull request and Deployment Rules auto-stop non-production, so a mistake expires on its own instead of running up a bill.

How does Qovery fit into a scoped access model for AI agents?

Qovery sits between the agent and your cloud account. The agent authenticates to Qovery with a scoped API token governed by per-environment RBAC, and Qovery holds the cloud credentials and provisions only the resources it models, inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster. The agent gets AI agent cloud access without long-lived credentials, because there are none for it to hold.

• BYOC by design. Workloads, data, VPC, and the cloud bill stay in your own account, so existing Savings Plans and committed-use discounts keep applying. Qovery orchestrates; it does not resell your compute.
• Scoped tokens plus per-environment RBAC. An agent can be restricted to one project or one preview environment with no path to production. Qovery's API Policy Tokens are backed by OPA, so the token itself is evaluated in Rego on every request and can allow, say, redeploy and rollback on one environment while denying everything else.
• A smaller vocabulary. The agent never receives an AWS access key, a GCP service account key, or an Azure client secret. It receives a Qovery token that expresses a far smaller set of actions: git-push deployments, preview environments per pull request, environment auto-stop, service scaling, managed cluster upgrades, and databases backed by managed cloud services.
• Audit that attributes. Every deployment is attributable to the token or user that triggered it in the organization audit log, and the underlying cloud API calls still land in CloudTrail (or the GCP and Azure equivalents) under Qovery's scoped role.
• The honest boundary. Qovery is not a general-purpose IaC replacement. For bespoke cloud resources outside the platform model, pair it with Terraform or Pulumi under a policy engine. Most teams running agents end up wanting both layers, because the agent that provisions the database and the agent that ships the service are governed in different places.

The agent-facing surface is an API and CLI a token can call. That is the scoped surface I would give an agent before I gave it anything that looks like an IAM user.

How do you set up scoped AI agent access step by step?

You can stand up a governed agent scope for non-production in an afternoon with six steps: write the blast radius down, issue a platform-scoped token instead of an IAM access key, federate short-lived cloud credentials on the platform side, write the deny rules before the allow rules, gate only the privileged set behind a human, and run the agent in ephemeral environments first.

1. Write the blast radius down explicitly. Which environments, which regions, which resource types, which monthly spend ceiling, and which actions always need a human. If you cannot write it in a paragraph, the agent will find the ambiguity.
2. Issue the agent a platform-scoped credential. A Qovery API token, a Spacelift API key, or an HCP Terraform team token. Never an IAM user access key, never a service account JSON key.
3. Wire short-lived cloud credentials on the platform side. OIDC federation or assume-role, so no static key exists anywhere in the chain. This is scoped IAM permissions for AI agents done right: the permissions live on a role the platform assumes, not on the agent.
4. Write the deny rules first. No IAM or trust policy changes, no public object storage, no 0.0.0.0/0 ingress, no untagged resources, no instance class above a set size, no production apply without approval.
5. Auto-approve everything outside the privileged set so the agent stays fast, and stream run logs plus CloudTrail into your SIEM with the agent identity as a first-class field.
6. Run the agent in preview and ephemeral environments with auto-stop for the first month, then widen scope only after clean audit logs.

Here is the deny rule from step 4 as OPA/Rego, blocking any security group that opens ingress to the world:

package terraform.aws.network

deny contains msg if {
    sg := input.resource_changes[_]
    sg.type == "aws_security_group"
    rule := sg.change.after.ingress[_]
    rule.cidr_blocks[_] == "0.0.0.0/0"
    msg := sprintf("%s opens 0.0.0.0/0 ingress", [sg.address])
}

And here is the short-lived identity from step 3 as an IAM trust policy, scoped so only your agent runner's OIDC subject can assume the role:

{
  "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:preview"
    }
  }
}

The aud and sub conditions are what stop any other workflow from assuming the role. On GCP this is a Workload Identity Pool provider with an attribute condition; on Azure it is a federated identity credential on a managed identity.

How do you prove the guardrails are actually working?

Guardrails only count if you can measure them, so track four numbers monthly: static long-lived cloud keys in the chain (target zero), the share of agent actions hitting a policy deny, the share requiring human approval and how fast approvals happen, and the percentage of cloud API calls attributable to a named agent identity (target 100%).

• Zero static keys is a binary test. Run the IAM credential report and query access-key age. Anything long-lived the agent can reach fails the test. Given 23.8 million secrets leaked to public GitHub in 2024 per GitGuardian, the only safe number of standing keys is none.
• Policy deny rate reveals rule quality. Near-zero denies usually means gaps, not safety. A constantly blocked agent means rules too tight to be useful. You want a low, non-zero rate that trends down as the agent learns the guardrails.
• Approval rate and time-to-approval. If humans approve everything in seconds without reading, the gate is theater. Watching the Stack Overflow finding that only about a third of developers trust AI output show up as careful review is a good sign; instant approvals are not.
• Attribution coverage. Every cloud API call should map to an agent identity in CloudTrail via session tags, not to a shared platform role with no context. This is the control the auditor cares about, and it is why breach math matters: the 2025 IBM Cost of a Data Breach Report puts the mean time to identify and contain a breach at 241 days, and a clean per-agent trail is what shortens your half of that.
• Add drift detection and a spend ceiling alert, because a well-behaved agent can still be expensive.
• Red-team it. Run a prompt-injection test against the agent and confirm the policy layer, not the model, is what stops the unsafe action. The same IBM report found that 13% of organizations had a breach involving their AI, and 97% of those lacked proper AI access controls. The control has to live below the model, because the model will eventually be talked into trying.