Why Can’t We Branch Our Cloud? Building Git Style Branches for AWS
We branch code without thinking twice, but cloud changes still go almost straight to production. Here’s how I built a way for AI agents to fork a model of an AWS account, try changes, and see the consequences first.
Every developer branches code without a second thought. Try an idea, look at the diff, throw it away if it’s wrong. Nothing touches main until you’re sure.
Cloud changes don’t work like that. You change a security group, delete a database, or edit an IAM policy, and it happens to the real thing. Terraform plan tells you what actions will run, but not what they mean for the rest of your account.
And now AI agents are making these changes. That made me ask a simple question: why can’t an agent get a branch of the cloud?
The idea
Emfirge gives an agent a safe copy of your cloud to experiment on. Not a real copy, which would be slow and expensive, but a model of it.
- Snapshot. You add a read-only IAM role. Emfirge scans the account and builds a graph of resources and how they connect: what can reach what, which role can do what.
- Branch. A branch is that snapshot plus an ordered list of changes. The agent can add, modify, or delete resources like EC2 instances, security groups, RDS databases, S3 buckets, and Lambda functions.
- Diff. Emfirge rebuilds the graph with the changes and compares it to the base: new or removed findings, internet exposure, and dependencies that would break.
- Verdict. Every branch gets a pass, warn, or block, with the evidence behind it.
Nothing ever touches your real AWS. If the agent likes the result, a human or your normal pipeline applies the change.
What it looks like
You connect your agent:
npx @emfirge/mcp install --privacy=strict
Then ask: “Create a branch of my cloud and show me what changes if I make my database private.”
The agent creates a branch, flips publicly_accessible from true to false, and gets back a diff: the database is no longer reachable from the internet, and the related finding disappears. It can stack more changes, compare two branches side by side, undo the last change, or discard the branch entirely.
One rule I care about: the LLM doesn’t decide
The verdict comes from deterministic graph analysis, not from a model guessing. A new critical finding or a new privilege-escalation path means block. Deleting a data store with no recovery point means block. The AI explains the evidence; it doesn’t invent it. If an agent is checking its own work, another AI judging it isn’t enough.
What I got wrong
My first test against a real AWS account passed 3 of 12 scenarios. Some lessons:
- An agent sent a security-group rule with a slightly wrong field name. Emfirge silently accepted it and modeled no ingress, so the server looked safer than it was. Now every change has to be validated against the resource schema.
- Exposure was tracked per machine, not per port, so opening a database port on a host that already had SSH open registered as “nothing new.”
- In strict privacy mode, real resource names still leaked through error messages and free-text notes.
A tool that says “safe” when it isn’t is worse than no tool, so these became the first things to fix, before any new feature.
Limits
It’s a model, not reality. It works from a snapshot, so it can go stale. It can’t tell you latency, load, or whether your app will actually respond, which needs a real run. And only some resource types can be changed on a branch today. Next up: accepting Terraform plans as input, broader resource coverage, and better freshness.
Try it
Emfirge is open source: emfirge.cloud . If you’re letting agents near your AWS account, I’d genuinely love to hear what would make you trust a tool like this.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article