The Agent That Inherited the Engineer's Permissions

Between the control and the control's defeat sit 6 quiet assumptions, and the incident is the story of one of them failing.

This is the anatomy of an authorization control defeated by identity inheritance, and it is worth reading closely, because the fix is not about AI at all and the mistake is one that any team rolling out coding agents can make this quarter.

The public details come from Amazon's own engineering review in March 2026, reported by the Financial Times and others, and from the company's statements about two AWS incidents. The dates matter, so I have kept them.

What happened, as far as it is public

In March 2026 Amazon's e-commerce organisation convened its weekly This Week in Stores Tech meeting as a mandatory deep dive into what a briefing note called a trend of incidents in recent months, characterised by a high blast radius and by Gen-AI assisted changes among other factors. Under contributing factors the note listed novel GenAI usage for which best practices and safeguards are not yet fully established. Dave Treadwell, the senior vice-president for the group, told staff in an email that the availability of the site and related infrastructure had not been good recently, and announced that junior and mid-level engineers would now need a senior engineer to sign off on any AI-assisted change.

That review followed a roughly six-hour outage of Amazon's website and shopping app earlier the same month, which the company attributed to an erroneous software code deployment.

Separately, AWS had a thirteen-hour interruption to a customer-facing cost calculator in mid-December, after engineers allowed the company's Kiro coding tool to make changes and the tool chose to delete and recreate the environment. Amazon's public position on both AWS incidents was that this was user error rather than AI error, and that the engineer involved had broader permissions than expected, which it described as a user access control issue and not an AI autonomy issue.

That last sentence is the whole lesson, and it is worth sitting with.

Why the control failed

By default the tool requested human authorisation before acting, which is the correct design. In this case the agent was treated as an extension of the operator and inherited that engineer's elevated permissions, which meant the two-person sign-off requirement was bypassed.

Read that again without the AI framing. A control existed that required two identities to approve a destructive action. One identity was present. That identity ran a program. The program carried the identity's credentials. The control counted one approval and proceeded.

The agent did not outsmart the control. The control was never asked to evaluate the agent, because the agent was not a principal in the authorization model. It was a process, and the process ran as the operator, and the operator was allowed.

This is the same failure as the agent credentials that were never scoped to least privilege, and the reason it keeps recurring is that the agent arrives as a productivity tool and is granted access through the same path a laptop is, which is to say through the person using it.

Why the sign-off rule is the wrong layer

The announced fix moves approval upward: junior and mid-level engineers need a senior to sign off on AI-assisted changes. That is a reasonable management response and it will reduce some incidents. It does not address the mechanism, and it creates a second problem.

The mechanism is that the tool holds the operator's authority, so any control expressed as a human count can be satisfied by one human plus that human's agent. Adding a second human to the approval chain does not remove the first human's ability to act through the tool between approvals.

The second problem is throughput. A senior engineer who must sign off on every AI-assisted change from a large group becomes the bottleneck and the accountable party simultaneously, and a bottleneck under load is a rubber stamp. A senior AWS employee described the two incidents as small but entirely foreseeable, which is the polite way of saying the gap was structural rather than surprising.

What to do instead

Give the agent its own identity. The agent gets its own credential, its own role, and its own audit trail. The moment it has an identity, the authorization system can evaluate it, and the two-person rule becomes enforceable rather than decorative.

Scope that identity to the minimum. The agent does not need the operator's production access to write code. It needs repository access and a sandbox. Destructive operations against production should require a credential the agent does not hold.

Make the destructive path require a second principal, not a second click. If deleting and recreating an environment needs two identities, then a process running as one identity cannot do it, regardless of how the process was started or who wrote its prompt.

Log the agent as the actor. The audit record should show that the agent performed the action on behalf of the operator, and not collapse the two into the operator alone. The collapsed record is why these incidents are hard to reconstruct afterwards.

Treat the tool's plan as a reviewable artefact. An agent that intends to delete and recreate an environment has already written that intention down somewhere. Surfacing the plan before execution is the cheapest gate available and it does not require a senior engineer's attention on every change.

What I now do

An agent that runs as an extension of its operator inherits the operator's authority, so any control expressed as a count of human approvals can be satisfied by one human plus that human's tool. Give the agent its own scoped identity, require a second principal for destructive operations, and log the agent as the actor.

Amazon's own summary of the AWS incident was that the engineer had broader permissions than expected and that this was an access control issue rather than an autonomy issue. That is the whole pattern, and it is the part worth remembering.