Letting Claude and Cursor Provision Infrastructure: 7 Platforms That Give Your Security Team Audit Trails and Policy Guardrails

Key Points:

• No AI coding agent should hold cloud credentials. The pattern that survives a security review is to give Claude Code or Cursor an MCP or API interface to a platform that owns the credentials, checks policy before every apply, and logs every action to an immutable audit trail. The agent requests; the platform decides and executes.
• The tools that do this split into three families: policy-as-code engines (Open Policy Agent, HashiCorp Sentinel), IaC orchestrators with policy gates (Spacelift, Env0, HCP Terraform), and developer platforms that expose governed self-service actions to humans and agents alike (Port, Qovery). Most teams combine one from each family.
• Your security team's checklist should be concrete and written as policy: a machine identity per agent separate from any human, least-privilege scoped credentials the agent never sees, mandatory policy evaluation before apply, human approval on production and destructive changes, and full audit logs exported to your SIEM.
• Qovery fits when the job is provisioning and deploying application environments inside your own cloud. Agents call the Qovery API or its MCP server to deploy into your own AWS, GCP, Azure, Scaleway, or existing Kubernetes account, with per-environment RBAC, ephemeral preview environments as the agent's blast-radius boundary, and an audit trail of every deployment. Cloud credentials stay in Qovery, never in the agent's context.
• Start agents in non-production with ephemeral environments and read-only production access. Widen scope only once you can answer, from logs alone, who asked for a change, which policy approved it, and what exactly changed.

One rule decides whether agent-driven provisioning survives a security review. The AI agent never holds cloud credentials. It sends a request to a platform, the platform checks policy and executes with credentials the agent never sees, and every action lands in an audit log tied to the agent's own identity. Once that architecture is in place, choosing a platform is mostly a question of which layer you need. Without it, no amount of prompt engineering will satisfy a reviewer.

This is not a niche worry anymore. In the Stack Overflow 2025 Developer Survey, 84% of developers said they use or plan to use AI tools, up from 76% a year earlier, and just over half of professional developers use them daily. Those tools increasingly take write actions. IBM's 2025 Cost of a Data Breach report found that 13% of organizations had a breach of an AI model or application, and 97% of those lacked proper AI access controls. The gap your security team is worried about is real, and it is an access-control gap.

What platforms let AI coding agents provision infrastructure with audit trails and policy guardrails?

The platforms that can do this today are Spacelift, Env0, and HCP Terraform with Sentinel for Terraform-based provisioning, Open Policy Agent as the policy decision layer underneath them, Port as the governed self-service action catalog, and Qovery as the governed deployment and environment layer running on your own cloud. None of them is a full answer on its own. Each owns a different link in the same chain: plan and apply orchestration (Spacelift, Env0, HCP Terraform), the allow/deny decision (OPA, Sentinel), the action surface an agent calls (Port, Qovery), and the place infrastructure and applications actually run (HCP Terraform runners, Qovery inside your account).

The one architecture that makes any of them safe is the same: agent to platform API or MCP server, policy check, scoped execution by the platform, immutable log. The agent is a requester, never an executor. It calls a typed, validated action. The platform holds the credential, evaluates policy, runs the change, and records who asked, what ran, and what changed.

That is why handing Claude Code or Cursor a raw AWS or GCP key and letting it run terraform apply on a laptop fails review. There is no attributable identity separate from the developer, no policy gate before apply, no reliable log, and no bound on blast radius. You are trusting the model's judgment instead of a control.

A few terms I use throughout, defined once:

• MCP (Model Context Protocol) is Anthropic's open standard for exposing tools and resources to an agent. Both Claude Code and Cursor support MCP servers.
• Policy-as-code means your rules (allowed regions, cost ceilings, who can touch production) live in version-controlled files a machine evaluates, not in a wiki.
• Plan-gated apply means the change is generated first, checked against policy, and only then applied.
• Ephemeral environment is a short-lived, disposable environment that an agent can create and destroy without touching anything permanent.

Map your own stack to the three families: policy engines decide, IaC orchestrators execute Terraform, and developer platforms give humans and agents a governed set of actions.

Why can't we just give Claude Code or Cursor cloud credentials and let it run Terraform?

Because every control your security team relies on assumes a known identity with a known scope, and an agent running Terraform on a laptop satisfies none of them. Here is the failure list, and it is worth pasting straight into a review doc.

• Non-determinism. The same prompt can produce different plans on different runs. Review has to happen on the generated plan, not on the prompt, so the review step has to live in the pipeline, not in a code comment.
• Identity collapse. If the agent uses the developer's key, its actions show up as that developer in CloudTrail or Cloud Audit Logs. You lose the ability to separate human intent from agent action, which is a permanent non-repudiation failure.
• Prompt injection. A malicious README, issue, or dependency can steer an agent that has write access. OWASP ranks prompt injection as the number one LLM risk (LLM01:2025), and its Excessive Agency entry (LLM06:2025) describes this exact problem: an agent with more permission than its task needs. OWASP's own mitigations are to avoid open-ended tools like shell access, limit permissions to the minimum, and require human approval for high-impact actions.
• Secret leakage. A credential in the agent's context window can end up in logs, in a model provider's traces, or echoed back into a chat. A context window is exactly what prompt injection reaches.
• Blast radius. Destructive Terraform changes, the replace and destroy class, are the specific actions that must always require a human. An agent that retries and loops can do a lot of damage before anyone notices.

The fix has nothing to do with prompt quality. Move the credential and the decision out of the agent and into a system built to hold both.

What does a governed agent provisioning pipeline actually look like end to end?

A governed pipeline has five mandatory stages, and you should be able to name the system that owns each one:

1. Request    Agent calls a typed action via MCP server or platform API
                 (not free-form shell)
      |
2. Identity   Request runs as a dedicated machine identity with its
                 own RBAC role, separate from any human
      |
3. Policy     OPA/Rego, Sentinel, or native guardrails evaluate the plan
                 (deny by default on cost, region, instance type,
                  public exposure, IAM changes)
      |
4. Execution  The platform holds the cloud credential and runs the apply
                 in its own runner. The agent never sees a key.
      |
5. Audit      Structured log of who, what, when, which policy verdict,
                 and the resource diff, exported to your SIEM

Stage 3 is where deny-by-default earns its keep. The default answer to any agent request that widens IAM, opens public ingress, changes region, or exceeds a cost ceiling should be no, with an explicit allow rule required to pass. Stage 5 is where you correlate the platform's own log with the cloud-native record of truth. AWS CloudTrail records every management event with the identity, time, and source, its Event history is an immutable 90-day record, and CloudTrail Lake event data stores are immutable with retention up to about ten years. GCP Cloud Audit Logs and Azure Activity Log play the same role on their clouds.

Human-in-the-loop placement is the part teams get wrong. In ephemeral and non-production environments, let the pipeline run automatically. For production and for any destructive change, require a human approval that cannot be bypassed by an agent.

How do Spacelift, Env0, Port, Open Policy Agent, HashiCorp, and Qovery compare for AI-agent provisioning?

They are not substitutes. Each sits at a different layer, and most teams end up combining a policy engine, an execution platform, and an action surface. The table first, then when each is the right primary choice.

The honest read on each:

• Spacelift and Env0 are the better answer when the agent's deliverable is Terraform or OpenTofu modules. Spacelift evaluates OPA policies at several decision points (login, access, approval, plan, push, trigger), and Env0 runs OPA approval policies with cost thresholds and TTL-based expiry. If everything you provision is IaC, start here.
• Open Policy Agent is a decision engine, not a platform. It decouples the policy decision from enforcement: something else has to query it and act on the answer. It stores no state, runs no apply, and routes no approvals on its own. It is the policy brain that another system has to wire up and act on.
• HashiCorp (HCP Terraform + Sentinel + Vault) is the enterprise-standard combination. Sentinel gives you three enforcement levels (advisory, soft-mandatory, hard-mandatory), and Vault issues dynamic, short-lived credentials to the run so the agent never holds a static key.
• Port is a catalog and action layer. Its self-service actions are audited, support requiredApproval, and can be executed by agents, but they trigger a backend (CI, a webhook, a cloud service) that does the actual work. Port governs the front door; you still need an executor.
• Qovery is the deployment and environment layer on your own cloud. It is not a general-purpose Terraform policy engine, and I would not pretend otherwise. Its job is to let agents provision and deploy application environments inside your account under RBAC and audit. More on where it fits, and where it does not, below.

Combinations are normal, not a failure to decide. A common shape: Port or Qovery as the action surface an agent calls, OPA or Sentinel for the policy decision, and Spacelift, Env0, or Qovery doing the execution.

What guardrails should the security team require before approving agent-driven provisioning?

Approve agent provisioning only when you can tick this list, and write each item as policy rather than as a wiki page a human is trusted to remember.

• A distinct machine identity per agent, with its own RBAC role and a revocable token. No shared human credentials, ever, so every action attributes to one caller.
• Short-lived, scoped credentials held by the platform, using Vault dynamic secrets or cloud OIDC workload identity federation. The agent gets an application-level verb, never a cloud key in its context.
• A deny-by-default policy set covering allowed regions, instance families and size caps, a monthly cost ceiling per environment, no public ingress without explicit approval, no IAM or security-group widening, and no production data access.
• Mandatory plan review and human approval for production and for any resource replacement or destruction.
• Environment scoping: agents operate in ephemeral or non-production environments by default; production stays read-only until you have proof the controls hold.
• Immutable, exportable audit logs with the request, actor identity, policy verdict, resource diff, and outcome, retained to your compliance regime and correlated with cloud-native logs (CloudTrail, GCP Cloud Audit Logs, Azure Activity Log).
• A kill switch: one action that revokes the agent's token and freezes its environments.
• Cost guardrails as a security control. A runaway agent loop is an availability and budget incident, not just a bill surprise.

Here is the same checklist mapped to the system that actually enforces each item, which is the version worth pasting into a review:

This maps cleanly to SOC 2 and ISO 27001 change-management expectations, and to the governance direction in the EU AI Act and NIST AI RMF: change is authorized, evaluated, logged, and reversible. I would not overclaim any specific certification here; verify what each vendor actually holds before you write it into a control.

How do Claude Code and Cursor actually connect to these platforms?

Through MCP servers and scoped API tokens. The agent calls typed tools the platform exposes, and the platform decides what is allowed. MCP is Anthropic's open protocol for exposing tools and resources to agents, and both Claude Code and Cursor support MCP servers. Claude Code itself is built on the same principle: its permission system uses allow, ask, and deny rules and asks before it runs a tool, which is the local version of the boundary you want at the platform.

The mechanics an engineer can implement this week:

• Design the tool surface narrowly. Expose create_preview_environment, deploy_service, get_logs, and request_production_approval. Do not expose run_shell or apply_terraform. The permission you cannot express is the permission the agent cannot abuse.
• Scope the token. Per-project and per-environment tokens, with read, deploy, and admin as separate scopes. The agent's token reaches non-production and nothing else.
• Log the agent side too. Record the request, the tool-call arguments, and the returned decision so the prompt-to-change chain is reconstructable end to end.
• Treat MCP servers as dependencies. Pin and review third-party MCP servers the way you review any package. A compromised MCP server is a supply-chain problem with write access.

A concrete flow: a developer asks Cursor for a staging environment with a Postgres database. The agent calls the platform's create_preview_environment tool. Policy checks region, size, and cost. The platform provisions an ephemeral environment in the company's own cloud account, returns a URL, and writes an audit entry naming the agent identity and the request. No cloud key ever entered the agent's context.

How does Qovery fit this use case, and where does it not?

Qovery is a good fit when the thing you want agents to do is provision and deploy application environments inside your own cloud account under RBAC and audit. It is a poor fit if you need a general policy engine for arbitrary Terraform modules, and I will say that plainly.

What Qovery is: an internal developer platform that deploys and operates applications inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster (BYOC and bring-your-own-Kubernetes, including self-managed clusters). The cloud bill and any committed-use discounts stay in your name, and the workloads and data stay in your account and VPC. For a security review, that last point matters: there is no third-party hosting of your workloads to reason about.

The capabilities that map straight onto the guardrail checklist are all things Qovery actually does today:

• Git-push deployments and API-driven automation, so agents get a deploy verb, not a cloud console.
• Preview environments per pull request, which are the natural blast-radius boundary for an agent, with TTL cleanup that destroys the environment when the PR merges or is abandoned.
• Per-environment RBAC and scoped API tokens, so an agent token can be limited to non-production.
• An official MCP server that is read-only by default, requires two deliberate switches to allow writes (neither of which a model can talk its way past), authenticates with a token that carries only its role's permissions, and logs every action to the Console audit trail.
• Managed cluster upgrades and databases backed by managed cloud services, plus per-repository and per-team budget caps as a cost guardrail.

The agent pattern with Qovery is simple: the agent gets a scoped token limited to non-production environments, Qovery holds the cloud credentials, every deployment is attributable and logged, and production requires a human with the right role. We built the Qovery API and MCP server with this exact separation in mind, because the failure mode we kept seeing was a smart agent holding a dumb, over-broad key.

The honest limit: for governance of arbitrary Terraform modules, you still want Spacelift, Env0, or HCP Terraform with OPA or Sentinel. They compose fine with Qovery. Use the Terraform orchestrator for the base infrastructure and Qovery for the application environments agents create and destroy all day.

You can stand up the first version in under a day: create an agent service account, scope it to preview environments, wire the API or MCP tool surface, and review the audit log after the first week before you widen anything.

What is a sane rollout plan for the next 90 days?

Roll out in three stages, and make each stage conditional on an audit review the security team signs off. Speed is not the goal here. You never widen scope faster than your ability to reconstruct what happened.

• Days 1-30, read-only. The agent inspects environments, logs, and plans, and proposes changes as pull requests only. You establish the audit baseline and confirm every agent action is attributable.
• Days 31-60, ephemeral write. The agent can create and destroy preview and non-production environments under cost and region policy, with auto-stop TTLs. Production stays untouched.
• Days 61-90, gated production. The agent can open production change requests that require human approval and pass the full policy set. Destructive actions stay human-only, permanently.

Report these metrics to security every month: number of agent actions, policy denials and why, mean time to approve, cost per agent-created environment, and incidents caused versus prevented. Two failure modes to watch for. The first is policy sprawl that nobody maintains, so rules rot into noise. The second is approval fatigue, where humans rubber-stamp every request and the gate becomes theater.

The decision rule that governs all of it: if you cannot reconstruct who asked, what policy allowed it, and what changed, do not widen the agent's scope yet.

What platforms provide governed automated infrastructure provisioning for AI agents?

For Terraform-based provisioning, Spacelift, Env0, and HCP Terraform with Sentinel orchestrate and gate applies. Open Policy Agent is the policy decision layer underneath them. Port is a governed self-service action catalog agents can call. Qovery is the deployment and environment layer that runs in your own cloud. Most teams combine a policy engine, an executor, and an action surface rather than picking one.

Can Claude Code or Cursor safely run Terraform apply in production?

Not unattended. terraform apply against production state is close to root on everything the state describes, and an agent that retries or loops can cause damage fast. Let the agent generate a plan or open a pull request, then require a human or policy gate before any production apply. This is exactly what OWASP's Excessive Agency mitigations recommend.

How do I give an AI coding agent cloud access without giving it cloud credentials?

Put a platform between the agent and the cloud. The agent calls a scoped API or MCP tool with application-level verbs (deploy, create environment, roll back), and the platform holds the cloud credential and runs the change. When the agent genuinely must call a raw cloud API, use OIDC workload identity federation or a broker like HashiCorp Vault to mint short-lived credentials, and keep the secret value out of the agent's context.

What should be in an audit trail for AI-agent infrastructure changes?

The request or prompt reference, the agent's machine identity, the policy verdict, the exact resource diff, and the outcome, all immutable and exportable to your SIEM. Correlate the platform's own log with the cloud-native record, such as AWS CloudTrail, GCP Cloud Audit Logs, or Azure Activity Log, so you can answer which agent, which run, and which change from logs alone.

Do I need Open Policy Agent if I already use Spacelift, Env0, or HCP Terraform?

Often you already have it. Spacelift and Env0 use OPA for their policies, and HCP Terraform supports OPA alongside Sentinel. You would run standalone OPA when you want one shared policy service that several systems (your IaC orchestrator, your internal API, your MCP layer) all query for the same allow/deny decision, since OPA decouples the decision from enforcement.

How is Qovery different from Port or Spacelift for AI-agent provisioning?

Port is a catalog and action front door that needs a backend to execute. Spacelift orchestrates Terraform. Qovery is the layer that actually provisions and deploys application environments inside your own AWS, GCP, Azure, Scaleway, or Kubernetes account, with per-environment RBAC, PR-based ephemeral environments, auto-stop, and an audited API and MCP server. Use Port for the action surface, Spacelift for Terraform modules, and Qovery for the application environments agents create and tear down.

Give an agent a scoped deploy action and an audit trail instead of your cloud keys, and its worst mistake becomes a one-click teardown of a preview environment. That is the layer we build at Qovery. Try Qovery free or book a demo to see scoped tokens, ephemeral environments, and deployment history running in your own account.