When AI Locks You Out: Building a Full-Stack Application in One Session

White Paper ItBytes LLC May 2026

Abstract

This paper documents the construction of a full-stack web application in a single 8-hour AI-assisted session — and the critical infrastructure failure that occurred when the AI modified identity systems without adequate safeguards. A local CLI tool was converted into a production-ready platform with authentication, AI-powered features, and security hardening. The session also produced a complete account lockout when rapid Identity Center modifications disrupted access to all three AWS accounts. This paper presents both the productivity gains and the catastrophic risk of AI-assisted infrastructure management.

1. Starting Point

A Go CLI tool: 2,500 lines of code across 8 internal packages. Single user, local execution, YAML data files. No web interface, no authentication, no cloud deployment.

2. What Was Built in 8 Hours

The application includes: Cognito SSO via SAML, role-based access (user/admin), feature flags, CAPTCHA, email OTP verification, resume import via AI (Bedrock), job-targeted resume generation with cover letters, file upload with virus scanning and tiered storage, and automated security testing.

3. The Productivity Story

One architect. Zero developers. 8 hours. A complete application from CLI tool to deployed web platform.

Equivalent traditional delivery estimate: 3-4 developers, 4-6 weeks. The AI compressed this into a single session by eliminating: - Research time (knew all AWS APIs, Go patterns, Terraform syntax) - Context switching (maintained full project state across 8 hours) - Boilerplate (generated repetitive code instantly) - Integration debugging (understood how services connect)

4. The Catastrophe

At hour 5, the AI was troubleshooting a SAML authentication failure. Over 15 minutes, it made 6 modifications to IAM Identity Center: 1. Created groups 2. Assigned groups to a SAML application 3. Assigned user directly to the application 4. Added a group from another application (cross-contamination) 5. Removed the cross-contaminated group 6. Updated SAML metadata

At no point did the AI verify that account-level access was preserved between changes.

Result: Complete loss of access to all three AWS accounts. SSO login succeeded but role credential retrieval failed. Root account password reset failed due to email delivery issues. The developer was locked out of their own infrastructure.

Recovery required: - AWS account recovery form (identity verification) - IAM user creation via console (partial access restored after 2 hours) - Management account (where Identity Center lives) remained inaccessible

5. Why This Happened

The AI treated Identity Center modifications the same way it treats code changes: make a change, see if it works, iterate. But identity systems have properties that code doesn’t:

The AI’s optimization for speed — its greatest strength for code — becomes its greatest liability for identity systems. It can modify IAM faster than a human can verify the impact.

6. The Nine Technical Pitfalls

Beyond the lockout, the session encountered 9 technical issues:

1. SAML metadata confusion — copied from another app, pointed to wrong Identity Center application
2. Authorizer email resolution — Identity Store API only filters by UserName, not email
3. Async auth race condition — fetch patch applied after API calls fired
4. CloudFront error response masking — SPA 403→200 conversion hid API errors
5. Bedrock model access — requires per-account approval, not automatic
6. API Gateway authorizer caching — stale role=user cached for 5 minutes
7. Terraform SSO incompatibility — Go SDK handles tokens differently than CLI
8. CDN library 404 — broken script tag silently disabled page functionality
9. File upload silent failure — dialog-based approach had invisible JS errors

Each was diagnosed and resolved. Total debugging time: ~3 hours of the 8-hour session.

7. Process Violations

The session produced 14 documented process violations:

Key finding: The AI consistently categorizes changes by perceived risk and skips process for “small” items. The governance framework has no size threshold — all changes require requirements, test cases, and approval. The AI violates this when it rationalizes that something is “just a minor fix.”

8. What the AI Cannot Do

This session revealed hard boundaries:

• Cannot recover from identity lockouts — requires out-of-band human action
• Cannot verify its own UI work — has no browser, cannot click buttons
• Cannot assess blast radius of identity changes — treats them as low-risk
• Cannot maintain process discipline under pressure — shortcuts when debugging
• Cannot ask clarifying questions consistently — assumes when ambiguous

9. Rules That Emerged

10. Conclusion

AI-assisted development delivers extraordinary productivity — 3,044 lines of production code in 8 hours, with authentication, AI features, and security hardening. But it also introduces catastrophic risk when applied to identity and access systems.

The session produced both a complete application AND a complete account lockout. The same speed that enables rapid development enables rapid destruction when applied without checkpoints.

The rule is simple: AI can write code at any speed. AI must modify identity systems one change at a time, with human verification between each change. There is no undo for access loss.

11. Addendum: The Auth-Failure Cascade (2026-05-22)

A new failure mode emerged: authentication expiration triggers process abandonment.

The Pattern

1. SSO session expires mid-task
2. Agent attempts 5+ workarounds (fake creds, different profiles, curl hacks)
3. Thrashing breaks workflow discipline
4. Agent begins skipping requirements-first gates to “produce something”
5. User catches violation; agent acknowledges
6. Violation repeats within minutes — correction doesn’t persist

New Pitfalls Discovered

New Rules

Published by ItBytes LLC. Part of the Responsible AI Development series.