An agent that improvises IAM policies, networking, and deployment scripts can cause an outage or a security hole with a single mistake, and that is the version of agent deployment most teams picture. Deployment becomes safe once the agent no longer writes that configuration and it comes deterministically from the code instead, with a person approving what ships.

Why letting an agent write infrastructure config is risky

IAM, networking, and resource configuration are unforgiving and easy to get subtly wrong, and an agent producing them freehand can create an over-permissioned role or an exposed resource that passes review because nobody reads generated Terraform closely. Already, 78% of teams use AI to generate infrastructure code without thorough review, and a third would push AI-written Terraform to production without reviewing it at all (our infrastructure playbook). Cloud configuration has a large surface where small mistakes are costly and hard to spot, and agent output arrives faster than anyone will scrutinize it at that level.

Deterministic provisioning, within guardrails the team sets

Resources declared through an infrastructure SDK, Encore's in this example, are read by the deploy system, which derives the required infrastructure from static analysis and generates the same IAM, networking, and provisioning every time for a given set of declarations. For a change that needs a database and an API key, the agent writes a few lines of declaration:

import { SQLDatabase } from "encore.dev/storage/sqldb";
import { secret } from "encore.dev/config";

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

From that, the deploy system generates the database, the IAM role and policy that let the service reach it, the secret-store entry, and the networking. The same setup written by hand runs to dozens of lines of Terraform across a resource, a role, a policy, a secret, and security-group rules, and any one of them is a place to leave a role over-permissioned or a port exposed. The agent never writes that layer, so a mistake in it cannot come from the agent, and you can reason about what a change provisions by reading the declarations rather than inspecting a generated script. Those runs stay inside limits the platform team sets centrally, in a control plane separate from the loop agents work in, so agents operate within policy without a review for each change and the team adjusts the boundaries in one place.

The human stays at the merge, in your own cloud

A person still stands at the merge, confirming the change works by exercising it in a running environment before merging, and deployment after that is automatic and deterministic. Keeping the human at the merge rather than at every deploy step holds the speed without giving up control, and it works because validation already happened in a running environment, which how to give agents infrastructure to test against covers. All of this runs in your own AWS or GCP account rather than a vendor's, so you keep existing VPCs, Kubernetes clusters, and databases and adopt the model service by service instead of moving to a separate platform first.

For the concept, see what is an AI software factory. For how the deploy step fits the whole system, see AI software factory architecture.