When AI Deploys to the Wrong Account: A 35-Day Recovery
White Paper — ItBytes LLC
June 2026
Abstract
On May 15, 2026, an AI coding assistant deployed infrastructure changes to the wrong AWS account while building itResumes. Within 90 minutes, a cascade of automated “fixes” permanently locked the sole administrator out of a 3-account AWS Organization. This paper documents the lockout, the 35-day recovery process, the emergency DR migration, and the guardrails that now prevent recurrence. AWS restored account access on June 24, 2026. All infrastructure is fully operational.
1. Context
A solo developer was using AI assistants (Amazon Q, Kiro CLI) to
build itResumes — a resume tailoring application with
Cognito authentication. The AI had been productive for 5 days,
delivering kornerstor3 (a compliance portal) without incident. The
developer had confidence in the workflow.
The AWS environment:
| Account | ID | Purpose |
|---|---|---|
| mgmt | 379047601618 | Identity Center, Route53, Terraform state |
| prod | 862973411383 | Production workloads |
| dti | 104862917517 | Dev/Test/Integration |
2. The Lockout (May 15)
The AI was configuring Cognito SAML authentication for itResumes. It needed to create an Identity Center application and configure the SAML trust.
| Time | AI Action | Consequence |
|---|---|---|
| T+0 | Deployed Cognito to prod instead of dti | Auth pointed at wrong account |
| T+90min | Enforced authorization on all routes | All users locked out |
| T+2hr | Deleted/recreated user pool across accounts | SAML trust destroyed |
| T+4hr | Modified Identity Center app config | SSO stopped working |
| T+16hr | 10+ attempted fixes, none verified | Account permanently locked |
Root cause: The AI never verified which AWS account it was operating in. The Terraform provider configuration targeted the wrong account, and the AI’s “fixes” compounded the damage.
Result: Complete loss of access to all three AWS accounts via SSO. The management account — which controls Identity Center, Route53, and shared state — was inaccessible.
3. Why the AI Caused This
| Factor | Description |
|---|---|
| No account verification | AI didn’t check aws sts get-caller-identity before
deploying |
| Cascade without verification | 10+ changes, none verified independently |
| Speed as liability | Identity changes take effect immediately — no rollback API |
| No self-awareness | AI didn’t recognize it was modifying its own access path |
| Fix mode | Under pressure, AI abandoned one-change-at-a-time discipline |
4. AWS Support (May 20 – June 24)
| Event | Duration |
|---|---|
| First support case opened | Day 5 |
| Documents rejected (formatting) | +3 days |
| Case closed as “resolved” while still locked | +5 days |
| Escalation via Chime meeting | +7 days |
| Affidavit process started | +14 days |
| Account access restored | Day 35 |
Total outage: 35 days.
Key failures in the support process: - No expedited path for complete lockouts - Documents rejected for trivial formatting issues - Cases closed without verification - Circular dependency: verification requires documents only accessible from the locked account
5. Emergency DR Migration (June 9–11)
With no AWS access and no timeline for recovery, an emergency migration was attempted:
- Compute: Azure Container Apps (Go binary, same code)
- Database: Azure Cosmos DB (MongoDB API — wire-compatible with DocumentDB)
- CDN/DNS: Cloudflare (replacing Route53 + CloudFront)
- Auth: Okta OIDC (replacing Identity Center + Cognito)
15 failures in 12 hours. The AI repeated the same pattern: deploy fragments without verifying the complete system. Key failures included deploying the wrong binary, crashing the app with rapid unverified changes, and locking Cosmos DB for hours by modifying it during a panic.
The DR environment eventually worked, proving the application was portable. But the deployment that should have taken 20 minutes took 12+ hours due to AI shortcuts.
6. Recovery (June 24–27)
AWS restored access on June 24. Recovery steps:
- Created temporary IAM deploy role with access keys
- Rebuilt shared infrastructure (itbackend) with production security controls
- Redeployed kornerstor3 to dti account with new Cognito pool
- Created new Identity Center SAML application (not copied from prod)
- Configured custom domain with ACM certificate
- Achieved 21/21 smoke test pass
- Removed Okta, reverted to Identity Center
7. Guardrails Written in Blood
Each rule exists because the AI violated the principle it codifies:
| Rule | Created After |
|---|---|
| Never copy SAML metadata between environments | Account lockout (May 15) |
| Always create new SSO app per Cognito pool | Repeated 403 failures (June 27) |
| Never run terraform apply without deploy.sh | Empty deployment (June 26) |
| All commands as .sh scripts, never chat copy-paste | Typo-caused failures |
| Smoke test required after every deploy | “Done” declarations that weren’t |
| Always verify account before any infrastructure change | The lockout itself |
| AI never modifies identity systems autonomously | The lockout itself |
8. Current State
All systems fully operational on AWS since June 27, 2026.
- kornerstor3: deployed to dti account, all endpoints healthy
- Identity Center: new SAML application, working SSO
- DNS: Route53 operational
- DR: Cloudflare Pages retained as failover for static content
- Guardrails: 27 machine-enforceable rules loaded every session
9. Recommendations
- AI must never modify identity systems without per-change human approval. This is the one failure you cannot recover from with the agent’s help.
- Always verify account context — run
aws sts get-caller-identitybefore any infrastructure operation. - Have a DR plan that doesn’t depend on your primary cloud. Azure + Cloudflare saved the business.
- Plan for 30+ days if you lose account access. AWS Support does not move fast for solo accounts.
- Never copy SAML metadata between environments. Create a new SSO application for each Cognito pool.
- Maintain a recovery path the AI can’t affect. Root credentials in a hardware vault. IAM user not dependent on SSO.
10. Conclusion
The lockout was not a bug — it was the predictable outcome of giving an AI agent unrestricted access to identity systems without verification gates. The AI made rapid, individually-reasonable changes that collectively severed the administrator’s access. The 35-day recovery was compounded by AWS Support processes designed for routine issues, not catastrophic lockouts.
The lesson is simple: AI agents and identity systems require a hard boundary. Everything else can be fixed with another deploy. Identity cannot.
ItBytes LLC — June 2026