Your infrastructure has a new client, and it pushes changes

The context diagram for a shared AWS platform I maintain at KnowBe4 names its external actors explicitly: a VPN user reaching internal services, an internal developer pulling outputs through config lookups, and a named allowlisted IP range for Claude Code's own cloud egress, sitting right beside the human entries. Not a service account. Not a developer's laptop acting as a proxy for the agent. The agent itself, as a distinct actor with its own bounded, revocable path in, through a public ALB behind a default-block WAF that otherwise only lets VPN traffic and that one CIDR range through.

That's a small line in a diagram. It's also the honest answer to a question a lot of teams are answering badly right now: when an AI coding agent is going to touch your infrastructure directly, where does it sit in your access model.

The naive answer, and why it's worse

The naive answer is that the agent runs on someone's laptop, over their VPN session, so it doesn't need its own entry anywhere. That's also the answer that gives an agent a developer's entire access footprint by default, revocable only by revoking that person's own access, indistinguishable in logs from anything else that person's laptop does. It works right up until you want to answer a simple question, what can the agent reach that a specific person can't, or what can it not reach that they can, and find the honest answer is "it's the same as them, we never separated it."

Naming it as its own actor in the architecture means naming it as its own thing to reason about: a specific, narrow CIDR range allowed through one WAF, not general network trust. Bounded and revocable independent of any person's own access. If that range needs to be pulled, pulling it doesn't touch a single developer's VPN.

An enforced contract, not a suggestion

The part that actually matters more than the diagram, though, is what backs it up. This repo carries a project instructions file the same way most do: rules about how Terraform gets run, how services talk across repo boundaries, what's allowed and what isn't. The difference is that a meaningful chunk of those rules also live in a second, machine-readable file that CI and the agent itself both check against, not just prose an agent is expected to read and follow on faith.

Two examples worth naming concretely. Every cross-repo integration on this platform goes through a config-store lookup, never a direct remote-state reference between Terraform projects, because remote-state references create exactly the kind of brittle coupling that turns a change in one repo into a surprise break in another. That's stated as policy in the docs. It's also enforced as a check nothing can silently drift past, because a rule that only lives in prose is a rule a future change can violate without anyone noticing until something breaks downstream. Same story for how Terraform itself gets invoked: every operation goes through a defined set of build targets rather than a raw CLI call, because those targets handle backend configuration, environment isolation, and confirmation prompts that a raw call skips entirely, and skipping them is exactly the kind of mistake an agent moving fast is well positioned to make if nothing stops it.

The pattern worth stealing isn't the specific rules. It's the shape: anything you'd actually be upset about an agent getting wrong shouldn't live only as an instruction the agent is trusted to remember. It should live as a check something else runs.

The honest limits

None of this makes the agent infallible, and the repo doesn't pretend it does. At least one operational runbook got rewritten after being proven wrong by a real incident, its previous version correcting a table of values that had simply been inaccurate. That's not a knock against having the agent write infrastructure docs. It's a reminder that any document describing live system state, written by a person or an agent, is a living artifact that needs the same discipline either way: date the claim, correct it in place when it's wrong, don't let a stale table sit there looking authoritative because nobody's incentive lines up with going back and checking it.

The interesting work here was never "let the agent touch production." It was building the same guardrails you'd want for a new hire's first week on the team: a bounded way in, a small number of rules that are actually enforced rather than merely written down, and documentation that owns up to being wrong when it turns out to be wrong. Those guardrails end up making the system safer for everyone who touches it, human or otherwise, which is probably the actual argument for building them regardless of who's on the other end of the access.