Agents on cloud operations: read-only first, and pull requests after that
An agent with cloud credentials is the most useful and most dangerous automation you can build. The pattern that works is investigation with a read-only role and change as a reviewed plan.
Cloud operations look like the perfect agent task. The information is all in APIs, the questions are repetitive, the answers require correlating five services, and nobody enjoys doing it at eleven at night.
They are a good agent task. They are a terrible place to give an agent write access, and the gap between those two sentences is where the whole design sits.
Start with the work that is pure reading
Before anything writes, there is a large amount of value in an agent that only looks:
Incident investigation. "Latency on the checkout service doubled at 14:20, what changed?" An agent with read access to CloudWatch or Cloud Monitoring, the deployment history, the load balancer metrics and the database performance insights can correlate those four timelines in ninety seconds. It will not always be right. It will always produce a shorter list than a human starting from scratch, and that is the job of the first five minutes of an incident.
Cost archaeology. "Why did the bill go up 18 percent last month?" Cost data is a large table with a fiddly schema, and the question is a series of increasingly specific queries. This is close to ideal agent work, and it needs no write access at all.
Drift and inventory. What exists that is not in Terraform, which security groups are unused, which snapshots predate the person who made them. All read.
Documentation of what is actually there. Generating an accurate architecture description from the live account, which is usually more truthful than the diagram in Confluence.
Give it ReadOnlyAccess minus the actions that read secrets — secretsmanager:GetSecretValue, ssm:GetParameter with decryption, kms:Decrypt — because a read-only policy still hands over every credential in the account otherwise. That exclusion is the single most missed step.
Then let it write, but only into git
When the agent should change something, the output is a pull request, not an API call.
The loop: the agent investigates, proposes a Terraform change, opens a branch, CI runs plan, a human reads the plan and merges. Everything that made the change safe before — review, plan output, policy checks, an audit trail, a revert path — keeps working, and the agent slots into a process your team already trusts.
This is also where agents are genuinely strong on infrastructure, because Terraform gives them a feedback loop. plan and validate tell the agent it was wrong before a person has to, and the whole quality difference between agent output with and without a feedback loop shows up here.
Put policy-as-code in the pipeline and it covers the agent for free: Checkov, Conftest or Sentinel rules do not care whether a human or a model wrote the HCL. If you already run them, you already have most of the control you need.
The narrow set of direct actions worth allowing
There is a category of operation where waiting for a pull request defeats the purpose: scaling a node group during a traffic spike, restarting a wedged task, rotating a key after an alert.
If you allow these, constrain them hard. A fixed list of specific operations, never a general API capability. Resource scoping by tag, so the agent can only act on what the policy matched. Magnitude caps — scale to at most N, never terminate more than one instance in a window. A rate limit enforced outside the agent. And an immediate notification to a channel with the reason and a one-click revert.
That is the same structure as bounding any agent's writes, applied to the blast radius that happens to be your production estate.
What not to automate
Anything involving IAM policy changes, anything touching a production database schema, anything that deletes. Not because an agent cannot do it, but because these are the operations where a mistake is not recoverable and the time saved is minutes. The value of automation is proportional to frequency, and these are rare.
What to do this week
Create a read-only role with the secret-reading actions excluded, point an agent at it, and ask it your last incident's opening question. The answer, right or wrong, will tell you within one afternoon whether this is worth building out — and it cannot change anything while you find out.