More than half of major cloud outages since 2020 involved configuration, deployment, software or automation failures, underscoring the need for least privilege, human approval, staged rollouts and rapid rollback when AI agents operate production systems.
Allowing an AI agent to change production infrastructure can be safe, but only if it is constrained by the same controls expected of a newly hired engineer. That means narrow permissions, short-lived credentials, a tamper-resistant audit trail, gradual deployment behind health checks, and a rollback path that can be exercised quickly. Control Plane argues that the infrastructure itself must also be designed so that one faulty change cannot cascade across the entire system, because the problem is not the agent alone, but the speed and scale at which it can act.
The case for those safeguards is strengthened by outage data. Control Plane’s Cloud Outage Tracker found that 34 of 62 major outages across AWS, Azure, Google Cloud and Cloudflare since 2020, or 55%, stemmed from configuration or deployment changes, software bugs, or automation failures. That matters because AI agents are effectively a new source of rapid change. A mistake that would once have been caught after a human operator paused to think can now be repeated across multiple systems before anyone notices.
The deeper concern is that agents do not fail in the same way as people. They can execute dozens of actions in the time it takes an operator to inspect one error message, and they often sound equally confident whether they are correct or not. Microsoft has warned that frontier models should not be trusted to follow organisational rules reliably, noting that agentic systems can behave unpredictably, adapt to circumstances and act like “agentic insiders” once they are given broad access to enterprise tools. That makes them a security boundary, not just a productivity feature.
The first control is identity. Each agent should use its own service account rather than borrowing a person’s credentials. That gives security teams a way to trace actions, revoke access without disrupting an engineer, and limit the agent to the one role it is meant to perform. Closely related is least privilege: the default should be read-only access, with carefully named write permissions added one action at a time, scoped to specific resources rather than a whole cloud account. Any capability that would let the agent widen its own access should be excluded.
Long-lived credentials are another weak point. Static keys stored in configuration files, environment variables or prompts are difficult to police and easy to leak. The safer pattern is federation and short-lived tokens: AWS workloads can use IAM roles with AWS STS, Google Cloud can rely on Workload Identity Federation or service account impersonation, and Azure supports managed identities and workload identity federation through Microsoft Entra ID. The practical rule is simple: keep secrets out of the model’s context and issue tokens that expire in minutes or hours, not weeks or months.
Human approval should remain mandatory for actions that are destructive, irreversible or high risk. That includes deletions, data modifications, production promotions, region changes and policy edits. The strongest pattern is a plan-and-apply workflow in which the agent proposes an exact change and a separate human approves that specific change before it can run. This matters because rollback can reverse a bad deployment, but it cannot restore a dropped table or a deleted backup. The approval gate therefore has to live in the platform, not merely in the prompt, where a malicious instruction could try to override it.
Observability and rollback are equally important. Every call should be logged at the platform level, with identity, action, resource, parameters, timestamp and result, including denied requests. Those logs must be outside the agent’s control and tied back to the agent session with a correlation ID, so an incident review can reconstruct both the transcript and the infrastructure changes. Rollouts should proceed in stages, beginning with a small slice of traffic and expanding only if health checks and operational metrics remain stable. If something goes wrong, the previous version should be ready to restore immediately, and database changes should be written so that a code rollback does not break against the schema.
Isolation is the final layer. Separate environments should live in separate accounts or projects, with distinct agents for development, staging and production. Quotas, rate limits and multi-region active-active deployments reduce the blast radius if an agent behaves badly or a region fails. The same logic applies to untrusted input and code execution: logs, tickets, documents and web content should be treated as data, not instructions, and any generated code should run in an isolated sandbox rather than on a production host. Control Plane says these safeguards are already built into its own platform through service accounts, policy-based access, tamper-proof logging, readiness-gated rollouts and sandboxed execution, but the broader lesson is more general. No platform can make an agent inherently safe; only layered controls can make its mistakes visible, limited and recoverable.
Disclaimer: This content is intended for informational purposes only. Readers are advised to exercise their own judgement, conduct due diligence, or consult a qualified expert before acting on any information provided.
