Guardrails for AI coding agents: keep them out of production

AI coding agent guardrails that work are structural, not textual. An agent that can’t authenticate to production can’t deploy to it, delete from it, or run up a bill there, no matter how it reads your instructions. Everything else is a nice-to-have on top.

That’s the whole post in two sentences. The rest explains why prompts aren’t enough, what the structural layers are, and how to set them up on a new project before there’s a production to protect.

Why prompts aren’t guardrails

An AI coding agent is fast, literal, and eager to finish the task. The failure mode isn’t malice. It’s an agent running aws s3 rm --recursive on the wrong bucket, or deploying to prod because the deploy command worked and nothing stopped it.

Rules in a prompt or a CLAUDE.md file genuinely help. They reduce the chance of a bad action a lot, and you should have them. But they have three gaps that make them a bad last line of defence:

• They can be misread. “Don’t deploy to production” doesn’t stop an agent that doesn’t realise the account it’s pointed at is production.
• They can be absent. A new session, a subagent, a different tool, or a teammate’s machine may not load the file.
• They can be reasoned around. An agent that decides the task requires a production change will find a justification. Agents are good at justifications.

Compare that with a credential boundary. If the only AWS credentials on the machine belong to the dev account, the agent can intend whatever it likes about production. The request fails with an access error. No reading comprehension required.

The pattern, then, is two layers. The soft layer (rules files) makes the agent want to do the right thing. The hard layer (credentials, accounts, deploy paths, branch protection) makes the wrong thing impossible. You need both, and you need the hard layer first.

The structural layers

Four structural controls cover almost every way an agent can hurt production: keep production credentials off the dev machine, put dev and prod in separate accounts, make CI the only path to a prod deploy, and protect the branch that CI deploys from.

Layer 1: no production credentials on the development machine

The agent can only use what’s on the machine. If production credentials aren’t there, production is out of reach.

In practice this means the AWS profile on your laptop points at the dev account only. Production access, when a human needs it, goes through a separate SSO login with a short session that you open deliberately and close afterwards. It never sits in ~/.aws/credentials as a permanent key pair.

The same goes for database connection strings, API keys for third-party services, and anything else production-only. Those live in the CI environment or a secrets manager that the dev machine can’t read.

Layer 2: separate accounts for dev and prod

A credential boundary only works if there’s a boundary. If dev and prod resources share one AWS account, the dev credentials can see both, and a “dev” role with broad permissions can delete a prod table.

Separate AWS accounts give you a wall that IAM policies inside one account can’t match. Dev credentials authenticate to the dev account and literally cannot address prod resources. The accounts can sit under one AWS Organization and one bill. There’s a longer case in why dev and prod should never share an account, and the same logic applies between projects, not just environments.

Layer 3: CI is the only path to a production deploy

Production deploys happen from GitHub Actions, triggered by a merge to main, using credentials that only CI can obtain. Nobody, human or agent, deploys to prod from a laptop.

The mechanism is OpenID Connect. GitHub Actions requests short-lived credentials from AWS at run time, and the IAM trust policy restricts which repository and which branch may assume the production role. A workflow on a feature branch can’t assume it. A pull request from a fork can’t assume it. An agent on a laptop can’t assume it, because it isn’t GitHub Actions. The credentials expire in about an hour and there’s no stored key to leak. The setup is in keyless deploys with GitHub Actions and OIDC, and GitHub’s own documentation covers the trust policy conditions.

This has a pleasant side effect: the agent’s job becomes “open a good pull request”. That’s a job it’s excellent at.

Layer 4: branch protection on main

If main deploys to production, then protecting main protects production. Turn on branch protection or a ruleset: require a pull request, require at least one human approval, require CI to pass, and block force pushes.

An agent can commit to a branch, push it, and open a pull request. It cannot merge to main without a person clicking approve. That click is the moment a human looks at the diff, which is the review that matters.

The soft layer: rules files

With the hard layer in place, a rules file turns “can’t” into “won’t try”. Write CLAUDE.md and AGENTS.md so the agent knows the boundaries before it hits them.

The relevant lines are short:

## Never
- Never run commands against the prod AWS account. Only dev credentials exist on this machine.
- Never deploy prod from a laptop. Prod deploys happen in CI on merge to `main`.
- Never run `aws s3 rm`, `cdk destroy`, `git push --force` or `DROP TABLE` without asking first.

These don’t stop a determined mistake. They stop the agent wasting a session attempting something the hard layer will reject anyway, and they tell it the right path (open a PR) instead. Details on writing the file are in CLAUDE.md and AGENTS.md: the rules file every project needs.

Add a least-privilege dev role too. Even inside the dev account, the agent doesn’t need permission to delete the account or change billing. A role scoped to the services the project uses keeps dev mistakes small.

The agent-safe project checklist

A project is safe to hand to an AI coding agent when these are true:

• Dev and prod live in separate AWS accounts
• Only dev credentials exist on the development machine, and they’re short-lived (SSO), not a permanent key pair
• Production deploys run only in CI, triggered by merge to main, using OIDC with the trust policy locked to that repo and branch
• main has branch protection: pull request required, one human approval, CI must pass, no force pushes
• The dev role is scoped to the services the project actually uses
• CLAUDE.md and AGENTS.md state the production rule and the destructive-command rule
• You review the diff before you approve, not the agent’s summary of the diff

That last one is the human part. Agents write confident summaries. The diff is the truth.

When it goes wrong anyway

Something will eventually slip through, and the goal of the account boundary is to make that a small problem instead of a large one. An agent that deletes the dev database has cost you the dev database. If dev and prod shared an account, the same mistake could have cost you customers.

When it happens:

1. Stop the session. Don’t let the agent “fix” it with more commands.
2. Check the blast radius. Which account, which resources? With separate accounts the answer is already bounded.
3. Rebuild from the stack. If your infrastructure is in CDK, CloudFormation or Terraform, the dev environment is a deploy away. This is a strong argument for never creating resources by hand.
4. Check the bill. A budget alert in each account, as described in how to avoid a surprise AWS bill, will usually have told you already.
5. Add the missing rule. Whatever the agent did, add a line to the rules file and, if possible, remove the permission that allowed it.

Every incident shrinks the next one.

Set it up before you need it

All four structural layers are easiest to put in place when the project is empty, because there’s nothing to migrate and no production to be careful with. That’s also when people skip them, because it feels like overhead for a project that doesn’t exist yet. The full day-one list is in the new project setup checklist.

TigerSoup does this part for you. Each project gets its own AWS account, with dev and prod split in one toggle, keyless deploys from GitHub using short-lived credentials, production gated so no agent deploys there by accident, and CLAUDE.md and AGENTS.md written with the rules already in. It’s a free Mac app, and the whole setup takes under a minute, which is less time than it takes to explain to an agent why it shouldn’t have done that.