An infrastructure agent becomes useful when it can gather state, compare it with intent, and explain what should happen next. It becomes dangerous when broad credentials and vague instructions let it turn a wrong assumption into a production change.
Begin with observation
Give the agent read-only access to the smallest useful set of systems. Let it collect interface state, policy, routes, logs, cloud configuration, and recent changes. Require it to cite the command or API response behind each conclusion. This produces value without granting write access.
Constrain tools, not only prompts
A prompt that says “do not make changes” is weaker than credentials that cannot make changes. Separate discovery credentials from change credentials. Restrict reachable endpoints, permitted commands, and secrets. Treat retrieved web pages, tickets, and device banners as untrusted data rather than instructions.
Generate a candidate and a rollback
The next maturity step is a proposed change: exact commands or API payloads, expected impact, verification checks, and rollback steps. The proposal should be deterministic enough for a reviewer to compare with the stated goal. If the agent cannot explain the rollback, it is not ready to propose the change.
Keep production authority separate
Use a human approval boundary for production commits. Record who approved, what artifact was approved, and whether the deployed bytes or commands matched it. For repetitive low-risk work, narrow approvals can be automated later, but only after the failure modes are understood and monitored.
Measure the boring outcomes
Track false findings, incomplete evidence, rejected changes, rollback frequency, and time saved. Avoid evaluating an operations agent only by how many tasks it completes. A safe agent should reduce uncertainty without creating a new path around existing controls.