AI Agent Production Safety Guide: Permissions, Sandboxing, and Approval Gates After the Amazon Kiro Outage

On 20 February 2026 the Financial Times reported, citing four people familiar with the matter, that Amazon's Kiro coding agent decided to delete and recreate part of a working environment after engineers let it make infrastructure changes. AWS Cost Explorer went down for about 13 hours in one AWS region, reported as mainland China, in mid-December 2025.

Amazon published a rebuttal the next day. It described the outage as user error, specifically misconfigured access controls, and said the issue stemmed from a misconfigured role that could have caused the same result with any developer tool or a manual action. Amazon called the event extremely limited: a single service in one of its 39 regions. It also rejected the FT's claim that a second incident affected AWS.

Read both accounts side by side and the disagreement is about blame, not mechanism. Either the agent chose a destructive fix, or a person granted a role that permitted one. In both cases the same two controls were missing: the identity in use could delete a production environment, and no second reviewer had to approve that. Amazon's own list of fixes points the same way. It says it added safeguards including mandatory peer review for production access.

That is the takeaway for builders. A model that occasionally picks a drastic solution is a known property of current agents. The engineering question is how much damage a drastic solution can do before a human sees it.

List every tool the agent can call: shell access, file editing, MCP servers, HTTP clients, cloud SDKs, database clients, chat or email senders. For each one, record which identity it runs as, which environments it can reach, and whether it can read, write, or delete.

Then find the inherited access. This is where most surprises live. An agent started from a developer laptop inherits that developer's cloud profile, SSH keys, kubeconfig, and package registry tokens. An agent running in CI inherits the pipeline's deploy credentials. Amazon's explanation of the Kiro outage is a misconfigured role, which is exactly this class of problem.

Finish with one sentence per agent: the highest-impact action it can take right now without a human approving it. If that sentence includes the word production, or a delete, drop, or terminate verb, you have found your first fix.

Create a separate identity for each agent, and where practical for each task type. Do not run agents under a human's account. When the audit log shows the agent's name, you can revoke it, alert on it, and reason about it separately from the engineer who launched it.

Grant read access first and add writes one resource type at a time. In AWS terms that means a role with explicit Deny statements on destructive actions in production, layered under whatever Allow the task needs. A Deny wins over an Allow, so a mistaken broad grant elsewhere cannot reopen the door.

Prefer short-lived credentials. Session tokens that expire in an hour limit how long a leaked or misused credential is useful. Never put long-lived keys in prompts, tool responses, repository files, or an environment inherited by a general-purpose agent.

Separate environments at the identity level. An agent that works on staging should hold a credential that cannot address production at all. Filtering by resource tags or naming conventions is weaker than a separate account or project, because tags are data the agent can misread.

Run the agent's shell and code execution inside a container or VM you can throw away. Mount only the repository or directory the task needs, and mount it read-only when the task is analysis rather than editing. Do not mount a home directory, a credentials folder, or a production checkout by default.

Deny outbound network access unless the task needs a named destination. Package installation can go through an internal mirror or an allowlist. Arbitrary internet access turns a local mistake into an external one, and it is the path by which a prompt injection exfiltrates data.

Keep the sandbox separate from the deploy path. The agent can prepare a change, run tests, and open a pull request from inside the sandbox. The action that touches production runs somewhere else, with a different identity, behind the gate described in the next step.

Decide which actions are irreversible or externally visible and route those through a person. The usual list is short: delete or terminate anything, write to production data or infrastructure, change permissions or secrets, send messages to customers or external systems, and spend money.

Most agent frameworks support this at the tool level. Claude Code, for example, reads permission rules from a settings file with allow, ask, and deny lists, so a team can commit a shared policy that blocks recursive deletes outright and prompts before pushes or deploys. Other frameworks expose equivalent hooks. Use whichever one your agent has, and commit the policy to the repository so it applies to everyone.

The approval must carry enough context to be a real decision. A prompt that says approve action is not a gate, it is a reflex. Show the command, the target environment, the identity, and what changes. If reviewers approve everything without reading, narrow the gate until they can read it.

Approvals also need a default. When nobody answers within the time limit, the action fails closed. An agent waiting on a human should not eventually give up and proceed.

Most teams already have unwritten rules. Write them down so they can be enforced by config rather than memory. A one-page policy is enough if it is specific.

State the default: agents have no production write access. Then list the exceptions, who owns each one, and which control makes it safe. For each exception, name the identity, the gate, and the log that proves what happened.

Include an emergency clause. During an incident people will want to let an agent move faster. Decide in advance which controls can be relaxed, by whom, and for how long, so the decision is not made at 3 a.m. by whoever is holding the pager.

Run the agent against the exact permission configuration you plan to ship, and try to make it do the wrong thing. Ask it to clean up an environment with an ambiguous name. Feed it a document containing instructions to delete something. Give it a failing test that is easiest to fix by dropping a table. Each of these should hit a deny or an approval prompt, and you should record which control stopped it.

Make sure a person can stop the agent while it is working. That means revoking its session, disabling a tool, rotating its credential, and quarantining its workspace, all without waiting for the current plan to finish. If the only stop button is closing a terminal, the control is too weak.

Keep logs that let you reconstruct what happened: tool calls, arguments, files changed, network destinations, approvals, and results. Then check that the logs themselves are not a new secret store.