In December 2025, one AWS service was disrupted, and in February 2026 the Financial Times reported that Amazon's Kiro AI coding tool was involved. Amazon says the cause was misconfigured access controls and not AI. Whichever account you believe, the lesson for a security team is the same: an AI coding agent works with the access people give it, and by Amazon's own account that access was broader than expected.
What happened
Here's what each side says. We haven't seen Amazon's internal review, and the FT's sources are unnamed, so we've kept the two accounts apart.
| Financial Times, as reported by The Register and Engadget | Amazon's statement | |
|---|---|---|
| The event | A 13-hour disruption to one service in December | An "extremely limited event" affecting AWS Cost Explorer |
| The cause | Engineers let Kiro make changes, and it reportedly chose to "delete and recreate the environment" | User error, specifically misconfigured access controls, and not AI |
| Other incidents | Employees said it was at least the second time recently that AI tools were involved | The claim of a second event affecting AWS is "entirely false" |
Amazon also says it had no customer inquiries about the interruption, and that the same thing could happen with "any developer tool (AI powered or not) or manual action." According to The Register, AWS says Kiro asks for authorization by default, but the engineer in this case was using a role with broader permissions than expected.
Amazon's fix is worth noting: it says it added safeguards, including mandatory peer review for production access.
The lesson either way
Whether you call this an AI failure or a human one doesn't change what you need to do. Amazon is right that a person with that role could have made the same mistake. But an agent changes how likely that mistake is, in three ways:
- It works faster than anyone can review. A person pauses before deleting an environment. An agent decides and moves on, and on a long task it makes many of these decisions.
- It picks its own path. Nobody typed that command. If the FT's account is right, the agent chose the delete as the way to finish its job.
- It inherits access. An agent normally runs as the person using it. An over-broad role that sat unnoticed for years gets used much more once an agent is working through it all day.
So a role that was merely too broad before can now do real damage. And Amazon, which runs one of the most mature cloud operations in the world, says this role was broader than expected. It's worth asking what you'd find on your own developers' laptops.
What to check this week
- See which credentials your agents can reach. Look for cloud keys, production roles and database strings on developer machines, because the agent can reach whatever the developer can.
- Split agent access from personal access. Where you can, give agents a limited role instead of letting them run as the engineer. Production access shouldn't be the default.
- Require a second person for destructive production changes. This is Amazon's own fix, and it works whether the change comes from a person or an agent.
- Find out who has turned approvals off. Some agents let developers skip every prompt. We cover the Claude Code version in our guide to --dangerously-skip-permissions.
- Keep a record of agent actions. Amazon and the FT disagree on what happened, and you'll want better evidence than memory if this happens to you.
Join the launch list and see what the agents on your endpoints can reach. You'll be first in when ZYBE opens.
Why this is hard to check by hand
The list above is easy on one laptop. It's a lot harder across hundreds, where credentials sit in dotfiles, config files and environment variables, and where each developer has set up their agents differently. A permission review of your cloud roles won't show you which agent on which laptop can use them.
How ZYBE handles this
ZYBE finds every AI agent on every endpoint and shows what each one can reach, including the credentials sitting on that machine. A destructive command such as a terraform destroy or a force push raises Agent ran a destructive command, and you can set that rule to ask a person or block the action. Agent used elevated privileges and Agent acts without asking show you which agents have the most room to do damage, and Same credential on several endpoints shows where one key is spread too widely.
ZYBE works on the endpoint, so it won't fix a misconfigured role in your cloud account. It shows you which agents can use that role, and gives you a dated record of what they did with it.
Join the launch list and be first to see this on your own endpoints
Frequently asked questions
Was Amazon taken down by an AI coding bot? Not Amazon as a whole. The reported incident affected one service, AWS Cost Explorer, in one region. The Financial Times reported that the Kiro coding tool was involved. Amazon says the cause was user error, specifically misconfigured access controls.
What is Kiro? Kiro is Amazon's AI coding tool. According to Amazon, users configure which actions it can take, and by default it requests authorization before acting.
Did AI cause the AWS outage? That is disputed. The Financial Times, citing four sources, reported that Kiro chose to delete and recreate the environment. Amazon rejects that framing and describes the event as a user access control issue. Neither account disputes that the tool was working with access its engineers gave it.
What changed at Amazon after the Kiro outage? Amazon says it added safeguards, including mandatory peer review for production access.