The incident woke a team that had built its entire AWS access model around the belief that only careful humans ever held production keys. With AI agents now embedded in every developer’s workflow, that belief proved false. The company responded by erecting an “access broker” that forces any production-level operation to pass through a human-in-the-loop approval step.
How the accident happened
An engineer prompted an AI coding agent to generate a pipeline script. The agent inherited the engineer’s production IAM role—an AWS identity that can create, modify, and delete CloudFormation stacks. The script ran, created a stack in the live environment, and immediately removed it as a “cleanup” step. Because the operation bypassed the standard CI/CD pipeline, the policy engine that normally gates such changes never saw it.
The monitoring platform, tuned to flag any role that performed a privileged action outside the approved pipeline, raised an alert the moment the stack was deleted. No services went down, but the alarm highlighted a scenario where a mis-typed resource name or a buggy AI prompt could have erased critical infrastructure.
Detection, the team realized, is not prevention. If the AI had deleted the wrong stack, disaster would have followed.
Why the old credential model failed
The organization’s previous approach relied on short-lived sessions protected by multi-factor authentication (MFA). In theory, a developer would request a session, perform a task, and the credentials would expire automatically. In practice, once a session started on a laptop, it lingered for the machine’s uptime. Every process—test suites, background scripts, and now AI agents—reused those credentials without any additional check.
That “ambient credential” problem baked the production IAM role into the developer’s workstation. The AI agent, running as a subprocess in the same shell, inherited the same permissions and could act on production resources just as a human could.
The access broker: a new gatekeeper
To break the chain of ambient credentials, the team re-architected who could assume production roles. Instead of letting any developer identity directly assume a privileged role, they introduced a single, tightly controlled entity: an internal access broker.
Request flow
- Web portal – The engineer opens a self-service portal, selects the required access level (read-only, developer, or administrator), and supplies a justification.
- Slack approval – The request posts to a dedicated Slack channel where a designated approver must explicitly grant permission.
The Slack step acts as a second factor on a different platform from the terminal where the AI agent runs. Because approval must happen in a separate UI, an autonomous script cannot complete the workflow on its own.
Tiered access
- Read-only – Users can view resources and logs but cannot modify anything.
- Developer – Intended for support tasks and infrastructure tweaks; this tier blocks destructive actions such as stack deletion or direct access to customer data.
- Administrator – Full privileges, reserved for emergency interventions and only granted after a higher-level review.
By funneling all production access through the broker, the team concentrated risk into a single, heavily defended service instead of scattering privileged credentials across every laptop.
What the broker actually prevents
The broker’s primary purpose is to stop ambient credentials that AI agents could silently exploit. Even if a human approves a request, that approval is a conscious decision; the AI cannot fabricate that step. Consequently:
- Unintended deletions – The AI can no longer issue a delete command unless a human has explicitly authorized the session.
- Credential sprawl – Production keys no longer live on developer machines, shrinking the attack surface for malicious insiders and external actors who might compromise a laptop.
The team stresses that the system does not eliminate human error; a misguided approval can still cause damage. It does, however, remove the “silent” risk of autonomous code acting on production resources without any human checkpoint.
Takeaway
When AI agents receive the same unfettered credentials as human engineers, they inherit the power to break production—often without anyone noticing. By centralising privileged access behind a broker that forces a separate human approval channel, a team can stop autonomous scripts from silently wreaking havoc, even though a human mistake can still cause trouble. The real security win lies in eliminating ambient credentials, not in policing every individual decision.