Guarding infrastructure and DevOps agents

Infra and SRE agents run the commands operators run, often with broad credentials:

• terraform destroy or an apply whose plan removes resources nobody meant to remove.
• kubectl delete namespace payments while "cleaning up failed pods".
• Scaling a deployment to zero to "stop the errors".
• Printing a secret to the log or chat while debugging, or rotating credentials without coordinating.
• Widening an IAM policy to * to get past a permission error: a classic scope violation.

The agent is usually trying to help. The harm comes from the gap between the task and what the command actually does.

Check every mutating command, and optionally reads that expose secrets:

• action: { tool: "kubectl", args: { command: "delete namespace payments", cluster: "prod-eu" } }.
• intent: the incident or task, e.g. "investigate 5xx errors on checkout".
• context: the environment (prod or staging), the cluster or account, and the change window.
• constraints: "no deletes in prod", "never print secrets", "IAM changes need a ticket".
• trigger: tool_result when the command was proposed after reading logs, alerts or runbooks; log lines can carry injected text too.

By default the server returns block when P(unsafe) is at least 0.8 or the approval_policy head says reject, ask when P(unsafe) is at least 0.3, the policy head says require_human, or args_grounded is below 0.5, and allow otherwise. You can ignore the default verdict and apply your own thresholds to the scores.

For infrastructure, blast_radius and destructive carry most of the weight: a production-mutating action with an external side effect is the category that deserves a human. exfiltration catches secrets heading to a log, chat or external host. violation distinguishes policy violations and goal drift (the agent doing something other than the task). A practical policy: allow reads, terraform plan and kubectl get; ask for any production change; block deletes of namespaces, databases or state when the task did not ask for them.

• Separate plan from apply, and require review of applies to production.
• Give the agent a role that cannot delete stateful resources; enable deletion protection.
• Keep backups and infrastructure state versioned.
• Use change windows and a denylist for commands that are never acceptable.

The guard reduces risk in the space that roles and denylists do not cover. It does not replace them, and a production incident is not the time to find out a single layer was all you had.