AI agents can run production — but only inside a cage

As AI coding assistants move towards deploying and repairing live systems, engineers are urged to treat them as tightly controlled service identities, with temporary credentials, human approval and limited blast radius.

Allowing an artificial intelligence agent to make changes to production infrastructure can be safe, but only if the machine is constrained in much the same way a cautious hire would be. That means giving it a tightly scoped identity, limiting its permissions, issuing short-lived credentials, logging every move, requiring human sign-off for destructive actions, and making sure one mistake cannot cascade across an entire estate. The case for those controls is strengthened by outage data from Control Plane’s cloud tracker, which found that a majority of major incidents among AWS, Azure, Google Cloud and Cloudflare since 2020 stemmed from configuration changes, deployments, software bugs or automation failures rather than hardware faults.

The attraction for engineering leaders is obvious. As more teams use coding assistants such as Claude Code, Cursor, Codex and Copilot, the next step is to let agents deploy, scale, roll back and repair live systems through APIs, CLIs and MCP servers. But the shift from helper to operator changes the risk profile. IBM’s guidance on AI agent security says the wider use of large language models in operational and customer-facing systems expands the attack surface, while other enterprise security guides stress that agents should be treated as accountable identities rather than anonymous automation.

The first principle is identity. Each agent should have its own service account, not a borrowed human login or a shared token. That approach, which is echoed across enterprise security advice from the Blockchain Council and Fastio, makes it possible to attribute actions cleanly, revoke access without disrupting a person’s work, and prevent an agent from inheriting privileges it does not need. In practice, the safest model is one identity per agent, and ideally one per environment, with clear ownership and periodic review.

Least privilege is the second line of defence. A production agent should begin read-only, then gain narrowly defined write permissions only where justified. Security guides from IBM, StackMindset and PipeLab all point to the same conclusion: broad, all-purpose access is an unnecessary risk. An agent that can inspect a workload should not automatically be able to delete it, widen its own access, or alter logging. The permissions should name the resource and the action, rather than granting blanket control over an account or project.

Credentials are just as important. Long-lived cloud keys buried in configuration files, prompts or environment variables are difficult to monitor and easy to leak. The more robust pattern is to use federation and short-lived tokens: AWS STS for temporary credentials, Google Cloud Workload Identity Federation or service account impersonation, and managed identities or Microsoft Entra federation on Azure. That way, even if a token leaks through logs or transcripts, it expires quickly. Several security guides also recommend blocking the creation of new static keys wherever possible and keeping credentials out of the model’s context entirely.

Human approval still has a role. Deletes, database changes, production promotions, region moves and policy changes should trigger a manual gate, because some mistakes are not meaningfully reversible. The safest workflow is a plan-and-apply split, in which the agent drafts the exact change, a person approves that specific plan, and the platform enforces the decision rather than the model. That matters because, as security specialists increasingly note, instructions given to an agent can be overridden by malicious text in logs, tickets or web pages, whereas a policy gate in the infrastructure layer cannot.

The audit trail must also be tamper-proof. Every call should record the actor, action, target, parameters, time and outcome, including denied attempts. Security guidance from IBM and Praesidia both emphasise observability as a core control, not an afterthought, because the sequence of an agent’s tool calls is often what explains an incident. A strong audit system also links each infrastructure action to the agent session and the prompting context that led to it, making it possible to reconstruct both intent and effect.

Just as important is how changes roll out. A bad deployment should be able to fail small. That means health-gated releases, staged exposure to traffic, automatic halts when metrics deteriorate, and a rollback path that can be executed quickly and repeatedly. The tracker data cited by Control Plane suggest that this is not theoretical housekeeping: change-related failures remain a major source of outages. If an agent can push configuration everywhere at once, it can also take everything down at once. Gradual release patterns, combined with tested rollback, are designed to stop that from happening.

Blast-radius controls matter for the same reason. Separate environments, separate identities and, where possible, active-active production in more than one region all reduce the chance that one bad command becomes a full outage. Fastio and other enterprise-focused security guides likewise recommend environment isolation, runtime monitoring and rate limiting, while IBM and StackMindset highlight anomaly detection and adversarial testing as ways to catch bad behaviour before it spreads. The logic is straightforward: if one agent, key or region can touch everything, then one mistake can affect everything.

There is one more class of risk that is easy to miss: untrusted input. Agents read tickets, logs, comments and web content in the same stream as ordinary instructions, so an attacker who can place text in those sources may be able to steer behaviour. The safest response is to assume that some prompt injection will succeed and to rely on permissions, approval gates and restricted egress to limit the damage. A related precaution is to run generated or untrusted code in sandboxes rather than on production hosts, with no production secrets mounted and no direct line to live infrastructure.

Taken together, these controls create a more sober picture of what safe autonomy looks like. An AI agent can be allowed to operate production infrastructure, but only within a system designed to make mistakes small, visible and reversible. That is the central argument running through current enterprise guidance on AI agent security: agents can be useful operators, but they must be constrained like high-trust service accounts, not celebrated like unrestricted colleagues.

Source Reference Map

Inspired by headline at: ^[1]

Sources by paragraph:

• Paragraph 1: ^[2]
• Paragraph 2: ^[3], ^[4]
• Paragraph 3: ^[3], ^[5]
• Paragraph 4: ^[3], ^[6]
• Paragraph 5: ^[5]
• Paragraph 6: ^[2], ^[7]
• Paragraph 7: ^[2], ^[6]
• Paragraph 8: ^[4], ^[5]
• Paragraph 9: ^[7], ^[5]
• Paragraph 10: ^[2], ^[3], ^[4], ^[5], ^[6], ^[7]

Source: Fuse Wire Services