Shadow IT no longer appears only as unauthorized SaaS applications—it now manifests as cloud infrastructure built by engineers using AI agents, with no approval process, security ticket, or review. An article published August 13, 2026, on Webflow.com argues that this shift from SaaS sprawl to "code sprawl" fundamentally changes how organizations must detect and prevent ungoverned technology. The core problem: AI agents can now generate code, create infrastructure programs, and deploy cloud resources faster than any traditional review cycle, leaving security teams blind to what's running in their own accounts.
Unlike the old model of shadow IT—where someone signed up for a tool and connected it to Google Workspace, triggering an OAuth grant—agent-built infrastructure lives inside your cloud environment with IAM roles, potential access to production data, and no obvious detection point. An engineer asks an AI agent to automate a manual task for their team; the agent provisions resources in AWS, opens necessary ports, and deploys the application. No ticket gets filed because the process bypassed ticketing entirely. Six weeks later, a cloud security posture management tool flags a public endpoint with overly broad IAM permissions—but by then, the app has been running in production long enough that lateral movement becomes a realistic threat, not a theoretical one. The report describes detection surfaces that worked for SaaS—OAuth grants, network traffic, expense reports, SSO anomalies—as useless for code that originates from legitimate employees using legitimate tools within legitimate infrastructure.
The article states that the engineer building these tools "isn't trying to circumvent anything; they're trying to help," which makes enforcement alone insufficient. The report argues that "we've moved from SaaS sprawl to code sprawl" and that "the detection playbook for one doesn't translate to the other." According to the piece, vibe-coded applications present a "comprehension gate" problem: the engineer who built the tool may not fully grasp what they created, making code review more critical than ever—not merely a formality but a safeguard against shipping something the author themselves doesn't entirely understand.
The baseline Webflow is building internally has two layers: platform controls configured once at the organizational level, and process controls applied before anything ships. Platform controls include IAM least-privilege guardrails that scope permissions by default, secrets manager enforcement to prevent hardcoded credentials, and VPN-gated deployment targets so internal tools land behind the corporate VPN unless explicitly made public. Process controls involve an automated baseline check that runs code and infrastructure configuration against security standards before any human review, flagging violations and offering remediation guidance. Every internally built tool touching production infrastructure then requires a human reviewer with security context—either a peer engineer for lower-risk work, or formal Security team escalation for anything involving cloud infrastructure, direct data access, or novel IAM roles. The report explains that CSPM tools like Wiz will surface misconfigurations after deployment, but they only catch what's already running; the baseline and review process are meant to prevent problems before they're deployed. Detection becomes the safety net, not the front line. The harder challenge is knowing something exists at all—behavioral signals like IAM role creation outside normal pipeline activity, new public resources without change records, or API calls from developer machines directly into production accounts can indicate ungoverned tooling, though no single signal is definitive on its own.
The piece recommends making the security baseline available within the tools engineers already use—such as a Claude skill or similar AI-native tooling that reviews architecture against specific security standards at the point of building, delivering actionable feedback before human review. Platform controls are owned at the organizational or security engineering level and applied universally; process controls are distributed, with peer engineers handling lower-risk reviews and formal Security teams taking escalations. The article's closing advice: "Build the baseline before the CSPM finds it for you." The friction that once slowed ungoverned infrastructure is gone and won't return, so security baselines must catch up before monitoring tools discover the damage. Organizations without a dedicated application security team can still address this—what's required is a clear baseline, enforcement tooling, and engineers who understand what they're reviewing. The shift to AI-enabled development doesn't just accelerate delivery; it also redistributes security responsibility to the point of creation, demanding that guardrails become invisible defaults rather than visible obstacles.