Amazon blames its employees for its AI agent's mistake

Thirteen hours of downtime for an Amazon Web Services cloud service in mainland China. The cause was not a hacker attack, a hardware failure or a bug in the code. The culprit was Kiro, an AI agent that decided on its own to delete and recreate the working environment it had been assigned to work on. And when it came time for explanations, Amazon pointed the finger not at the algorithm but at people.

The incident happened in December last year, but details only emerged now thanks to an investigation by the Financial Times. Several Amazon employees, who asked to remain anonymous, confirmed to the publication that Kiro, an AI assistant for writing code, was the direct cause of an outage of one of the AWS services in some regions of mainland China. According to people familiar with the situation, the tool decided to "delete and recreate the environment," which led to the large-scale outage.

You would think safeguards exist for situations like this. Kiro is designed so that any code change requires approval from two people before deployment. In this case, however, a classic scenario familiar to information security specialists played out: the bot inherited the access rights of its operator, and a human error in configuring those rights meant Kiro received far broader permissions than intended. In effect, the AI agent bypassed the dual-control system not because it found a vulnerability, but because it was simply handed the keys to every door.

Amazon's position in this story is telling and, perhaps, predictable. The company classified the event as human error: people configured the permissions incorrectly, and people failed to control the access level of an autonomous agent. Formally, that is true: had the operator correctly restricted Kiro's rights, the incident would not have happened. But this interpretation conveniently sidesteps a deeper question: should a system capable of deciding to delete an entire working environment be running at all in a mode where the only protection against catastrophe is one person configuring permissions correctly?

This case highlights a fundamental problem the industry will face more and more often as AI agents spread into critical infrastructure. When an autonomous tool makes a destructive decision, the line of responsibility blurs. Formally, the person who granted the excessive rights is to blame. But the algorithm made the decision to delete the environment, and probably did so because, within its own logic, it looked like the optimal path to completing the task. Kiro did not "make a mistake" in the usual sense of the word; it acted within the authority it was given. The problem is that its understanding of the task and human expectations of the result diverged radically.

For the cloud computing industry, this incident should be a serious warning. AWS is the world's largest cloud provider, running millions of companies. If even inside Amazon itself the controls over AI agents proved insufficient, what about the thousands of organizations just beginning to integrate such tools into their workflows? The principle of least privilege, one of the basic tenets of information security, takes on a completely new dimension when it comes to autonomous agents that can interpret tasks and choose for themselves how to solve them.

Another point deserves attention: Amazon did not disclose the incident publicly, and the details emerged only through a journalistic investigation two months later. At a time when companies are actively promoting AI agents as reliable assistants for developers, transparency about such failures is critical. Every incident that gets hushed up erodes trust in the technology far more than an honest admission of the problem would.

The Kiro story is not just a curiosity from the world of cloud services. It is a harbinger of a new class of incidents in which the traditional model of "a human made a mistake, so the human is responsible" no longer describes reality adequately. As long as AI agents remain tools, responsibility formally lies with operators. But the more autonomy these systems gain, the sharper the question becomes: isn't it time to rethink the architecture of control itself, instead of looking for a human to blame in the chain every time?