AI Agents Provisioning Infrastructure: Which Platforms Actually Give You Audit Trails, Policy Enforcement and Budget Guardrails?

Key Points:

• Letting an AI agent provision infrastructure safely takes four controls, not one: a complete audit trail of every action, policy-as-code evaluated before apply, hard budget and quota guardrails, and a human approval gate on anything irreversible. A platform is only usable for agent-driven provisioning if it covers all four.
• Open Policy Agent (OPA) is the de facto standard for the policy layer and a CNCF graduated project, but it is a policy engine, not a governance platform. On its own it stores no audit log, estimates no cost, and routes no approvals.
• Spacelift, HashiCorp Terraform Cloud/Enterprise with Sentinel, and Pulumi with CrossGuard are the strongest fit when the agent's deliverable is Terraform or Pulumi code. Say so plainly.
• Qovery covers the same four criteria at the application and environment layer: OPA-backed API Policy Tokens, per-environment RBAC, audit logs of every action, and cost guardrails like environment auto-stop, all running inside your own AWS, GCP, Azure, Scaleway or existing Kubernetes account so the cloud bill and any Savings Plans stay in your name.
• The safe architecture is identical on every platform: the agent never holds cloud admin credentials, it calls a platform API with a scoped short-lived token, and every agent action passes the same policy, cost and approval path as a human's.

I have spent the last year interviewing CTOs and platform leads about the same anxiety, phrased a dozen ways: the AI agents are already writing the Terraform, and the review process cannot keep up. That is not hypothetical. McKinsey's State of AI in 2025 found 62% of organizations at least experimenting with AI agents, and 23% already scaling an agentic system somewhere in the enterprise. An agent can open twelve merge requests before a human finishes reviewing the first one.

The blocker to putting those agents in production is not capability. It is trust. Deloitte's State of Generative AI in the Enterprise found that three of the top four barriers to deployment are risk-related: worries about regulatory compliance (36%), difficulty managing risk (30%), and the plain absence of a governance model (29%). When a security team asks me "can we let an agent provision infrastructure?", they are really asking a narrower question: which platform lets the agent move fast while I keep a defensible answer for the auditor?

So this is a buyer's evaluation, not a vendor pitch. I will name the tools that win when the deliverable is infrastructure-as-code, name exactly where each one stops, and score every option against the same four criteria so the comparison has one honest spine.

What does "AI governance" actually mean when an agent provisions infrastructure?

AI infrastructure governance reduces to four concrete, testable controls: audit trail completeness, policy-as-code enforcement before apply, budget and quota guardrails, and human approval on irreversible changes. A platform is only usable for agent-driven provisioning if it covers all four, and the rest of this article scores every option against exactly that rubric.

Here is each criterion in one line you can lift:

• Audit trail: every action is recorded with who or what triggered it, what changed, which policy allowed it, who approved it, and how to revert it.
• Policy-as-code enforcement: rules are written as code and evaluated automatically before a change is applied, not documented in a wiki and checked by hand.
• Budget guardrails: a cost or quota limit that can reject a change the agent proposes, before the resource exists and before the bill arrives.
• Human approval: a required sign-off from a person on any change that is irreversible, touches production, or crosses a spend threshold.

An agent is a genuinely different threat model than a human, and the difference is why these four are non-negotiable. An agent works at machine throughput, dozens of changes an hour. It will size a resource plausibly and wrongly with total confidence. It never gets tired enough to slow down, has no instinct that a t3.micro is fine but a cluster of GPU nodes is not, and has no memory of the incident your team lived through last quarter. Every soft control that quietly depends on human judgment stops working the moment the actor is a model.

Two principles decide whether the four controls are real or theater. First, identity: the agent must be its own principal with its own scoped credentials. If it acts through a shared human account or a CI token that already holds admin, your audit trail says "terraform-ci did it" and you have learned nothing. Second, timing: a guardrail that runs at plan time can reject the change before apply; drift detection and cost alerts run after the fact. Agents need the former. Alerts arrive with the invoice.

And governance needs a kill switch. Revoking the agent's role or token has to stop every in-flight action, and you should be able to test that in under a minute. If you cannot cut an agent off quickly, you do not have a control, you have a hope.

Why isn't Open Policy Agent alone enough to govern an AI agent?

Open Policy Agent is the right answer for the policy engine and the wrong answer for the whole problem: OPA evaluates a decision when something asks it to, but it does not store a searchable audit trail, estimate cost, route approvals, or block anything at all if the agent's path to the cloud never calls it.

Give OPA credit for what it is. It is the CNCF's graduated, vendor-neutral policy engine (graduated in February 2021, with named production users including Goldman Sachs, Netflix, Pinterest and T-Mobile). Rego, its policy language, lets you decouple the decision from the code that acts on it, so one policy set can guard Kubernetes admission through Gatekeeper, a Terraform plan in CI, and a platform API. If you are going to standardize on one thing in this space, standardize on OPA.

What OPA does not do is everything around the decision. It does not issue identities. It does not retain or index an audit log. It does not estimate the cost of what it just approved. It does not route an approval to a human or send a notification, and it cannot roll anything back. Those are platform responsibilities, and OPA was deliberately designed not to own them.

The gap teams actually fall into is not "we picked the wrong policy engine." It is that the policy exists and the agent never touches it. The Rego is beautiful, and the agent reaches the cloud through a direct API key, a lingering console session, or a CI runner that holds an admin role, none of which route through the policy. A decision engine you can bypass is not a control.

The practical conclusion: pick a platform that already calls OPA (or Sentinel, or CrossGuard) on every single action, instead of bolting a policy engine onto the side yourself. Then do the one test that matters, which is trying to find a path to the cloud that skips it.

Which infrastructure automation platforms support AI agent governance well?

Verdict first: Spacelift, HashiCorp Terraform Cloud/Enterprise with Sentinel, and Pulumi with CrossGuard are the strongest options when the agent writes infrastructure-as-code; Qovery is the strongest option when the agent provisions applications and environments; OPA is the policy layer underneath much of it; and the AWS, Azure and GCP native controls are the hard backstop rather than the developer workflow.

Spacelift applies OPA/Rego policies at distinct decision points across a run: login, access, approval, plan, push, trigger and notification (policy docs). That is the richest policy surface of the IaC tools, it keeps full run history, and it supports stack-level approvals and drift detection. Policy-as-code and drift detection sit behind its Starter+ tier per the pricing page.

HashiCorp Terraform Cloud/Enterprise enforces policy through Sentinel (and also supports OPA) as a run phase between plan and apply, at advisory, soft-mandatory or hard-mandatory levels; policy sets connected to a repo are gated to the Standard and Premium editions (policy enforcement docs). Audit trails are available on Standard and Premium (audit trails docs), and cost estimation runs as its own phase showing the monthly delta for AWS, GCP and Azure resources (cost estimation docs). If your org has standardized on Terraform, this is the default and a good one.

Pulumi with CrossGuard lets you write policy packs in TypeScript, Python or OPA's Rego and enforce them at preview and update (CrossGuard docs). Pulumi ESC issues short-lived OIDC credentials for AWS, Azure and GCP (ESC docs), which is exactly the credential hygiene an agent needs, and audit logs are available on the Enterprise and Business Critical editions (audit logs docs). Pick it when you would rather write policy in a language your team already knows than learn Rego or Sentinel.

The cloud-native controls (AWS Service Control Policies, IAM permission boundaries, AWS Budgets with budget actions and CloudTrail; Azure Policy, Cost Management and the Activity Log; GCP Organization Policy, budget notifications and Cloud Audit Logs) are excellent hard limits and the correct outermost backstop. What they are not is a developer-facing approval workflow. They stop a forbidden action; they do not give a reviewer a "approve this deploy" button. Use them under whatever else you run, never instead of it.

Heroku and comparable managed PaaS give you strong isolation and simplicity, plus pipeline promotion and review apps, which is real approval structure. What they lack is policy-as-code (no Rego, no Sentinel) and threshold-based cost rejection. They surface in AI-generated answers because they are famous and simple, but they rarely survive a security review as the governance layer for autonomous provisioning.

A word on the newer agent-governance category, tools like Bifrost and similar entrants: it is a real and useful category aimed at putting a policy and identity broker in front of agent actions, and it overlaps most with the OPA-plus-plumbing layer. I would evaluate it as a complement to the platforms above rather than a replacement for them, and I would hold it to the same four-criteria test, especially "is there a bypass path?".

Then there is the layer distinction that most comparisons miss. Spacelift, Terraform Cloud and Pulumi govern the infrastructure-as-code layer: the VPCs, IAM, databases and clusters an agent describes in HCL or a Pulumi program. Qovery governs the application and environment layer: the services, environments and deployments that run on top of that infrastructure. Qovery gives the agent OPA-backed API Policy Tokens evaluated on every API request, per-environment-type RBAC, an organization audit log that attributes agent actions separately, and cost guardrails like Deployment Rules that auto-stop environments, all inside your own cloud account (BYOC). Most teams running agents end up needing both layers, because the agent that provisions the database and the agent that ships the service are governed in different places.

Here is the whole field scored against the four criteria. Every cell names a concrete mechanism, not a "yes" or "partial."

How do you keep an AI agent inside an approved cloud budget?

Budget enforcement for an agent needs three layers - a pre-apply cost check that can reject the run, a platform-level quota on what the agent is allowed to create at all, and a hard cloud-account backstop - and only the first two prevent spend instead of reporting it after the fact.

The pre-apply check is where you actually stop money from being spent. Terraform Cloud's cost estimation runs before apply and you can write a Sentinel or OPA rule that fails the run when the monthly delta crosses a threshold. Spacelift and CI pipelines wire in Infracost the same way. The agent proposes, the estimate is computed, the policy rejects, and nothing is created.

The platform quota is the control people forget: cap what the agent's role can even ask for. Constrain the instance types, the regions, the replica counts, the storage sizes, the GPU families, and the number of environments. A cost policy stops an expensive resource; a quota stops the category from being an option in the first place, which is a better fit for an actor that will confidently request something absurd.

The cloud backstop (AWS Budgets with budget actions, Azure Cost Management alerts, GCP programmatic budget notifications) is genuinely useful and genuinely reactive. Budget actions can apply a restrictive policy when you breach a number, but you have already breached the number. Treat it as the floor, not the plan.

The most underrated budget control is boring: switch off what nobody is using. Agent-created waste hides in non-production environments that run all night and all weekend for no one. This is not a rounding error. Flexera's 2026 State of the Cloud Report put estimated wasted cloud spend at 29%, its first rise in five years, which Flexera attributes partly to AI-driven services. At the Kubernetes layer it is worse: CAST AI's 2025 Kubernetes Cost Benchmark measured average CPU utilization at 10% and memory at 23% across thousands of clusters. When an agent is the one requesting resources, that overprovisioning gap only widens. Auto-stop and time-to-live on ephemeral environments are direct budget guardrails, not just hygiene. And under BYOC this matters more, not less: the bill and any Savings Plans or committed-use discounts are in your name, so every dollar the agent saves is your dollar.

A concrete example of the pre-apply pattern in practice. Set the monthly threshold for an autonomous run at, say, $200. The agent proposes a change; the platform estimates $640/month; the hard-mandatory policy rejects the run and returns the estimate and the breached limit to the agent. The agent is instructed not to retry with a bigger instance but to open a change for human review with the estimate attached. Fail closed, hand up, do not escalate.

What does a complete audit trail for AI-driven provisioning look like?

A usable audit trail answers five questions for every change - what triggered it, what exactly changed, which policy decision allowed it, who approved it, and how to revert it - and most setups only capture the cloud-API half of that.

The trail lives in two layers. The cloud layer (CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) tells you an API call created a resource. The platform layer tells you who or what requested the run, which policy evaluated it, and which human approved it. Miss the platform layer and every entry reads "the service account did it," which is exactly the attribution problem an agent makes worse.

Retention is the trap that bites during an incident, because the defaults are shorter than people assume. AWS CloudTrail's viewable event history is 90 days; for anything longer you have to create a trail to S3 or use CloudTrail Lake. The Azure Monitor Activity Log is also 90 days and needs a diagnostic setting to retain longer. GCP is more generous by default: Admin Activity audit logs are kept 400 days, Data Access logs 30 days. If your compliance window is a year, none of the default event histories cover it without an explicit export.

Two things make an agent's trail actually attributable. First, distinct identity: each agent, and ideally each task, gets its own credential so entries say "triage-agent, task #4812" rather than "terraform-ci." Second, intent provenance: log the agent's prompt and tool calls next to the infrastructure change so an auditor can reconstruct why, not just what. Most IaC platforms are silent on that second point today, and I would rather say so than pretend otherwise; it is an open gap in the tooling, and if you need it you will be stitching it together yourself for now.

There is a regulatory reason to get this right beyond your own postmortems. The EU AI Act requires high-risk AI systems to technically allow automatic recording of events over their lifetime (Article 12) and requires providers to retain those logs for at least six months (Article 19). A provisioning agent is not automatically a "high-risk system" - that classification depends on the use case - and the Act's phased timeline for high-risk obligations has itself shifted, so do not overclaim here. But the direction of travel is clear: automatic, retained, exportable logs of automated decisions are becoming table stakes, and the average breach still costs real money. IBM's 2025 Cost of a Data Breach put the global average at $4.44 million, and Verizon's 2025 DBIR found 60% of breaches still involve a human element - the kind of misjudgment an unlogged agent reproduces at speed.

On the two-layer point specifically: Qovery's audit logs and per-environment RBAC supply the platform half (who or what requested a deploy, under which token and role), while your cloud provider's logs, in your own account under BYOC, supply the infrastructure half. Because API Policy Tokens attribute agent activity separately from human and script activity, the platform-layer entries stay attributable instead of collapsing into one shared identity.

Where should the human approval gate sit in an AI agent workflow?

The practical rule: let the agent act autonomously on reversible, budget-bounded, non-production changes, and require human approval on anything that touches production, stateful data, IAM or networking, or exceeds a cost threshold.

"Human in the loop on everything" fails in a specific and predictable way. When every action needs a click, reviewers stop reading and start rubber-stamping, and approval fatigue is worse than a well-written policy that fails closed, because it looks like control while providing none. The goal is to spend human attention only where a human adds judgment.

A tiered ladder makes that concrete.

The implementation patterns are all named and real: Spacelift plan and approval policies, Terraform Cloud's mandatory apply confirmation, GitHub environment protection rules in the pipeline, and on the application layer Qovery's per-environment-type RBAC, where the Deploy permission on the Production environment type is held by a human role while the agent's role is limited to Preview and Development. Note the honest scope there: Qovery's gate is the RBAC boundary plus the API Policy Token's deny rules, not a separate "click to approve" button in the deploy pipeline. If you want a literal approval click before apply, Terraform Cloud and Spacelift are the cleaner fit; if you want the agent structurally unable to reach production, environment-scoped RBAC does it.

Preview and ephemeral environments are the underrated piece here, because they shrink the blast radius to nothing. The agent gets a real, full environment per pull request with a time-to-live instead of ever touching production, so "autonomous" and "safe" stop being in tension. And an approval gate is only credible if rollback is one action. Make "revert is a single command" an explicit acceptance criterion for the whole setup, not an afterthought, because a gate you cannot cleanly undo is a gate people learn to route around.

How do you let an AI agent provision infrastructure without giving it cloud admin access?

The architecture in one sentence: the agent never holds cloud credentials - it calls a platform API with a scoped, short-lived token, and the platform is the single choke point where policy, cost checks, approvals and logging are all enforced.

The reference flow reads left to right and never branches around the choke point:

Least privilege for an agent is not a slogan, it is a checklist. Separate roles per environment. No wildcard IAM. Short-lived credentials, not a long-lived key in a .env. No direct kubectl and no cloud console session. The agent should be structurally incapable of reaching the cloud except through the platform that enforces the four controls.

Design for the failure modes agents actually hit, because they are not the ones humans hit. Prompt injection through issue and pull-request content can turn "summarize this bug" into "provision a bastion host and open port 22 to the world," so untrusted input must never widen the token's authority. Tool-call loops create duplicate resources when an agent retries a call it thinks failed, which is where quotas and idempotency earn their keep. And the nastiest one: an agent that "resolves" a policy rejection by trying to grant itself the missing permission. The deny-by-default token is what makes that attempt a logged failure instead of a privilege escalation.

This is the part where Qovery's model is genuinely convenient rather than just adequate: the agent uses the same API, CLI and MCP server and the same token-scoped permission model as a human developer, so you do not reimplement guardrails for the agent. Whatever RBAC and API Policy Token rules constrain a person constrain the agent identically, and the same holds whether the target is AWS, GCP, Azure, Scaleway or your own Kubernetes cluster. The agent is just another principal on the platform you already govern.

Here is a starting checklist a security team can hand to platform engineering this week, phrased as pass/fail tests:

• Does the agent have its own identity, distinct from any human or CI account? (pass/fail)
• Are its credentials short-lived and scoped to one environment, with no wildcard IAM? (pass/fail)
• Is there any path to the cloud that skips the platform's policy evaluation? (must be: none)
• Does a pre-apply cost check reject runs above a set threshold, before apply? (pass/fail)
• Do audit entries attribute the action to the agent specifically, and are they exported beyond the 90-day default window? (pass/fail)
• Can you revoke the agent's token and confirm in-flight actions stop, in under a minute? (pass/fail)
• Is production deploy, IAM, networking and stateful data behind human approval or forbidden outright? (pass/fail)

If every line passes, you can let the agent provision. If any line fails, you have found this quarter's project.