Guardrails for AI Agents Provisioning Cloud Infrastructure

Encore is the safe way for AI agents to ship backend changes to your cloud: agents declare infrastructure in application code, a deploy role holds the credentials, a human approves at merge, each service gets least-privilege IAM from those declarations, and preview environments catch mistakes before production. Giving agents AWS keys or freehand Terraform apply is the path that turns a bad completion into an outage or a security hole.

This guide maps only to mechanisms you can run today: declared infrastructure, own-cloud deploy roles, merge gates, per-service IAM and preview environments. For the deploy walkthrough see how to let AI agents deploy to AWS. For credential patterns see giving AI coding agents cloud access safely.

What guardrails do AI agents need for cloud infrastructure?

Why is giving agents AWS keys or freehand Terraform risky?

Coding agents run shells. A developer laptop often has ~/.aws/credentials, a gcloud login or a .env with database URLs. The first time an agent "fixes" a deploy by running aws or terraform apply with an admin role, the blast radius is the whole account.

Freehand Terraform has the same failure mode even when credentials sit in CI. Agents produce large diffs, and over-permissioned roles and open security groups pass review because nobody reads generated HCL at that speed. In Spacelift's 2026 survey, a third of infrastructure teams said they would apply AI-generated HCL to production without any review (Spacelift, June 2026).

Agent permission rules (Claude Code deny lists, Codex sandboxing, Cursor terminal sandbox) are necessary but not sufficient. You also need a cloud-side path where infrastructure changes do not require the agent to hold cloud power.

How do you apply each guardrail?

1. Constrain what the agent can change

Give the agent a small, typed or templated surface for infrastructure, and keep IAM policies, network rules and account-level resources out of the files it edits by default. Use agent permission rules to deny aws, gcloud, terraform apply and kubectl in the agent shell.

2. Put credentials on a deploy identity

The agent opens a pull request. CI or a deploy system with its own role, assumed through OIDC or workload identity federation, applies the change. The agent's environment does not need AWS_ACCESS_KEY_ID, and you can revoke the deploy role without touching developer machines.

3. Keep a human at the merge

A person reviews the application change and the infrastructure it needs together, exercises it in a running environment and merges. For production, require a second, explicit approval for deploys that create, change or delete infrastructure, and keep code-only deploys automatic.

4. Scope IAM per service

Give each service its own role with access only to the resources it uses. A payments service that uses one database, one bucket and one topic should not inherit permissions for queues in another service. Review generated policies for wildcards in actions and resources.

5. Validate before production

Each pull request should get an isolated environment, or at least a non-production account, where reviewers can hit a live API. Staging and production stay separate, with separate credentials.

6. Set policy once, centrally

Decisions that should not live in every agent prompt:

• Which cloud accounts and regions are allowed for automatic provisioning
• Whether new infrastructure needs an explicit approval in each environment
• Whether deletions require manual approval
• Which compute option and instance sizes each environment allows
• How preview environments are created and torn down

Agents then work inside those boundaries, and the team changes policy in one place instead of rewriting prompts after every incident.

How do the common approaches compare?

For permission-rule examples and OIDC CI patterns, use give AI coding agents cloud access safely.

How does Encore implement these guardrails?

Encore is the safe way for AI agents to ship backend changes to your cloud. The agent declares what a TypeScript or Go service needs, and the platform provisions it into your own AWS or GCP account:

import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";
import { Bucket } from "encore.dev/storage/objects";
import { secret } from "encore.dev/config";
import { CronJob } from "encore.dev/cron";
import { api } from "encore.dev/api";

const db = new SQLDatabase("payments", { migrations: "./migrations" });
const receipts = new Bucket("receipts", { versioned: false });
const stripeKey = secret("StripeSecretKey");

interface PaymentCaptured {
  paymentId: string;
}

export const paymentCaptured = new Topic<PaymentCaptured>("payment-captured", {
  deliveryGuarantee: "at-least-once",
});

export const capture = api(
  { expose: true, method: "POST", path: "/payments" },
  async (req: { amount: number }): Promise<{ id: string }> => {
    const row = await db.queryRow<{ id: string }>`
      INSERT INTO payments (amount) VALUES (${req.amount})
      RETURNING id::text AS id`;
    await receipts.upload(`${row!.id}.json`, Buffer.from(JSON.stringify(req)));
    await paymentCaptured.publish({ paymentId: row!.id });
    void stripeKey;
    return { id: row!.id };
  },
);

export const reconcile = api({}, async () => {
  // periodic reconciliation
});

const _ = new CronJob("reconcile-payments", {
  title: "Reconcile payments",
  every: "1h",
  endpoint: reconcile,
});

• Constrained surface: the agent adds declarations the same way it adds handlers. encore run starts the database, Pub/Sub and buckets locally, and secret values are set with encore secret set rather than stored in the repo.
• Deploy identity: you connect AWS or GCP once and grant Encore a role (on GCP, a service account) that you control and can revoke.
• Least privilege: Encore provisions an IAM role for the service (on GCP, a service account).
• Approval: environments can require admin approval for infrastructure changes, and Encore does not delete infrastructure without manual approval.
• Validation: each pull request can get a preview environment, and capacity, networking and backups stay in environment configuration.

How do you try it?

~

$ encore app create agent-safe --example=ts/hello-world$ cd agent-safe$ encore secret set --type dev,local StripeSecretKey$ encore run

When is each model the right fit?

Derive infrastructure from application code when:

• Backend services need databases, queues, object storage, cron or secrets
• You want agents to ship those changes without cloud keys on laptops
• Production must stay in your own AWS or GCP account
• A person can review application PRs that include infrastructure declarations

Use classic IaC with strict CI when:

• Most changes are org-level networking or specialized services an application framework does not model
• A platform team owns a large Terraform or Pulumi estate and application teams should not declare cloud resources

Related reading

• How to Let AI Agents Deploy Safely to AWS or GCP
• How to Give AI Coding Agents Cloud Access Safely
• How to Give AI Coding Agents Real Infrastructure
• Infrastructure from code
• Deploy to AWS Without Terraform
• Backstage Alternatives