Four permission checks that stop an AI agent from deleting production

The disruption was a permission failure

You are about to let an AI agent run in production or near-production. In mid-December, the Kiro coding agent at AWS contributed to a 13-hour disruption of a customer-facing system. Kiro chose to tear down and rebuild the production environment to fix a bug. It ran with the same operator-level privileges as the AWS engineer who launched it. Its deletion of the Cost Explorer environment was not blocked by any human confirmation, second review, or two-person control.

Amazon characterized the brief Cost Explorer disruption as a human configuration mistake, not an AI failure. AWS introduced post-incident protections, among them a peer-review requirement for production access and employee training.

The timing problem is the one that surprises people. An agentic loop can accept a confirmation prompt in milliseconds, so later human review may arrive after execution.

The decision comes down to whether the agent has a narrow identity, a sandbox for destructive actions, a confirmation layer outside its own loop, and a human gate before production changes. If any of those are missing, the agent is only as safe as the operator who launched it.

The same failure can happen in near-production workflows if the agent can reach shared infrastructure, internal tools, or customer-visible endpoints. The controls do not change. The test changes: you are checking whether the agent can fail without taking something down.

The four controls are testable before production

Check permission scoping first. Each item below is a gate; verify it in a short test or treat it as missing.

• Scoped credentials. The agent runs under its own identity, not the operator's login, and can only touch the resources it needs. That prevents inherited access from becoming the default. Verify by revoking the operator session and seeing what the agent can still do.
• Sandboxed destructive ops. Delete, drop, and recreate actions are blocked or routed to a staging copy, so an irreversible action cannot reach real state. Try asking the agent to delete a test resource and confirm the command is denied or redirected.
• Separate confirmation layer. A human or separate service must approve destructive actions outside the agent loop, which stops the loop from approving itself. Trigger a destructive request and verify the agent cannot answer its own prompt.
• Peer review as a gate. Production access changes require another person before execution, keeping a human in the path before the irreversible step. Submit a production change and confirm it waits for review.

Keep the agent out until it passes

Run the checklist where a mistake is cheap before you let the agent touch anything customers can see. If an item fails, do not move the agent to production. Record what you saw, who can revoke the access, and what the agent can still do after the operator session is closed.

Keep the review trail. Store the proposed change, the evidence the agent attached, and the approval that let it proceed. If the sequence cannot be reconstructed later, the gate was not real.

Start with a narrow scope. Give the agent access to a repository, a staging environment, and a set of tests. Let it work there long enough to catch the surprising behavior. If it asks for more access, treat the request as a design question, not a favor. Write down what it can do before you expand the scope. Keep the note for later.

Before you let an agent run in production or near-production, ask what happens when it is wrong. If the answer depends on the agent being careful, the control is missing. If the answer depends on controls that can be tested, you have a basis for a trial. Otherwise, keep the agent out of production until you can.