Originally published on graycloudarch.com.
Local review outline. Not approved for publication.
An AI agent can explain a Terraform change without being allowed to apply it.
That distinction sounds obvious until the workflow blurs it.
The same assistant that summarizes a pull request can also run commands, read state, assume an AWS profile, and generate a plan. If the environment lets it cross those boundaries silently, model quality becomes the wrong primary question.
The better question is authority.
The mental model
Reasoning authority is the right to inspect, interpret, summarize, and propose.
Production authority is the right to reach systems that can change state.
Infrastructure work needs both.
It does not need both in the same trust zone.
Why this matters more in infrastructure repos
Application repositories usually contain several local failure dampers.
- tests fail
- CI blocks the merge
- reviewers reject the PR
- bad code often stays inside the application boundary
Infrastructure repositories reach a different surface.
- AWS accounts
- IAM permissions
- network topology
- deployment state
- secrets paths
- production infrastructure
Same assistant.
Different authority.
The failure mode
Most AI-assisted engineering workflows collapse three steps together.
- The agent reasons about the change.
- The agent runs commands to validate the change.
- The agent gains enough access to execute or nearly execute the change.
That collapse feels efficient.
It also makes the review boundary soft.
A reviewer should not have to scroll a chat transcript to reconstruct what happened. They should be able to inspect a durable evidence packet.
The evidence packet
Before an AI-assisted infrastructure change moves toward execution, the platform should be able to show:
- which account and workspace were in scope
- which commands ran
- which credentials were available
- what the Terraform plan changed
- what policy checks passed
- what assumptions remained unresolved
- who approved the handoff
The artifact is not just the pull request.
It is the operational record around the pull request.
Planning and execution as different trust zones
A safer operating model separates the zones.
Planning zone
- read-only repository access
- read-only cloud inventory access where needed
- no production mutation credentials
- generated plan summaries
- explicit unresolved assumptions
Execution zone
- short-lived credentials
- bounded command paths
- human approval gate
- auditable runner identity
- retained plan and policy evidence
The agent can help in both zones.
But the authority should not move with the conversation by default.
What platform engineering owns
This is not only an AI-tooling problem.
It is platform engineering work.
The platform defines:
- where AI can inspect
- where AI can propose
- where AI can run bounded validation
- where human review is mandatory
- where production authority begins
- what evidence survives after the session ends
That is the operating model beneath the tooling.
Draft thesis
As AI moves closer to infrastructure, the scarce resource is not intelligence.
It is authority.
Platform teams need to define where reasoning authority ends and production authority begins.
Possible final structure
- Open with a concrete Terraform/AWS repo moment.
- Define reasoning authority and production authority.
- Contrast app repo failure dampers with infrastructure blast radius.
- Show the workflow collapse failure mode.
- Define the evidence packet.
- Propose planning/execution trust zones.
- End with the operating-model question.
Open questions before full draft
- Should this stay tool-neutral, or mention Claude Code/Copilot/Codex as examples?
- Should the concrete example be Terraform plan review, AWS profile scope, or command execution boundaries?
- Should this become a standalone blog post or remain the governing idea for the LinkedIn series?
- What real sanitized artifact can prove the pattern without exposing the private governance registry?
Top comments (0)