When AI coding tools arrived, they delivered exactly what they promised. Developers started shipping faster. Non-engineers started building things they never could have built before. Entire workflows got automated in an afternoon. That momentum is worth supporting.
Research published this week by The Hacker News gives that momentum some useful context. The Shadow Builders report analyzed over 2,000 apps built with AI coding tools and found them sitting on the public internet, wired into company systems, with no security review and no IT oversight. The employees who built them were solving problems. The gap is a process one, and it's one security teams and builders can close together.
This Is a Different Category From Shadow IT
For years, shadow IT meant someone signing up for a SaaS tool without going through procurement. The security concern was data exposure: an employee connecting Google Drive to an unvetted app via OAuth. Teams built discovery tools to find those connections, and governance programs to manage them. That work mattered and still does.
AI-built apps sit in a different category entirely. When an employee uses an unsanctioned tool, the exposure tends to be bounded by what that tool can access. When that same employee builds and deploys an app, they've created something new: a persistent system with its own login page, its own API keys, its own connection to internal data. That system can live on the internet indefinitely, long after the person who built it has moved on to a different project.
Tom Levi, Field CISO and Director of Cyber-Risk Strategy at CYE, has seen this play out repeatedly. "They may share a link without realizing it can be forwarded. They may connect an entire folder when the tool only needs five fields. That is where a small workflow shortcut can become a material business exposure."
For organizations in regulated industries, these apps are also worth factoring into compliance programs. An app pulling customer records through a hardcoded credential can carry SOC 2 or GDPR implications that weren't part of anyone's original intent.
Standard discovery methods don't catch these apps. OAuth audits surface connected third-party tools. Browser extension scans find what's running on managed devices. Neither has visibility into an app sitting on a third-party hosting platform, built outside the normal review process by someone focused on shipping something useful.
What These Apps Look Like in Practice
To make this concrete: picture a sales operations analyst who needs a faster way to flag deal risk for the revenue team. She spends a Saturday with an AI coding tool and builds a lightweight dashboard that pulls from Salesforce and posts a daily digest to Slack. It works. She deploys it on a free hosting platform and shares the link.
Six months pass. Nobody remembers she built it. The Salesforce API credentials are hardcoded in the repository. The repository went public when she changed an account setting. The app is still running, still pulling data, still accessible to anyone who finds the URL.
Krti Tallam, Senior Member of Technical Staff at KamiwazaAI, has documented this pattern firsthand. "The composite version of a case I've seen more than once: a small internal dashboard pulling from a CRM extract, deployed via the platform's default publish to web flow. API key embedded directly in the front-end bundle. No auth gate."
This scenario is illustrative, but the pattern it reflects is documented. The Shadow Builders report found these exact characteristics across thousands of apps: hardcoded credentials, public repositories, live connections to internal systems. The employees who built them were talented and solving legitimate problems. They built without a security partner in the process, and that's the piece worth addressing.
Why Existing Controls Have a Blind Spot Here
These apps live on personal GitHub accounts and free-tier hosting services, entirely outside the corporate perimeter. They don't appear in identity provider logs unless someone is actively using them, and traditional asset discovery tools have no way to find them.
The governance picture underneath that is telling. ISACA's 2026 AI Pulse Poll found that a third of organisations don't require employees to disclose when AI has been used in work products at all, leaving security teams with no reliable way to know where AI is being applied across the business. As Chris Dimitriadis, Chief Global Strategy Officer at ISACA, put it: "The gap between deployment and governance is not closing; it is growing."
Existing security programs were built for a different landscape. The tools employees now use to build and deploy software in hours simply didn't exist when most enterprise security architectures were designed. Extending visibility to cover the new surface means building alongside what's already there, adding coverage where the current architecture has no reach.
Four Things That Work
- Register what's running. Give employees a low-friction way to log what they've built: a shared channel, a short form, a named owner for each app. Pairing that form with an assigned reviewer and a defined turnaround time keeps the process moving and gives employees a clear path forward. The goal is a live inventory of what apps are running, what they connect to, and who is responsible.
- Embed guardrails into tools employees already use. Enterprise-tier AI coding tools like GitHub Copilot and Cursor support configurable policies that flag hardcoded secrets and warn against public repository settings. GitHub Advanced Security's secret scanning catches exposed credentials before code goes public. Building those defaults into the approved toolchain puts guidance at the moment of decision, without adding a formal review step to every project.
- Audit what's already deployed. For most security teams, the more immediate problem is the apps already out there. Scanning public repositories for company-associated credentials, monitoring for API keys tied to internal systems, and reviewing free-tier hosting accounts gives a starting point. Remediation becomes manageable once the inventory is scoped: an app connected to internal HR data is a different priority than one pulling from a public spreadsheet.
- Build app ownership into offboarding. When an employee leaves, their AI-built apps rarely leave with them. A lightweight ownership transfer step, added to standard offboarding, ensures someone reviews what's running and hands it off or shuts it down. This single process change eliminates a significant share of the exposure that builds up quietly over time.
Security as a Builder's Partner
The partnership model is the right goal, and it tends to take shape around speed. When security teams can offer a quick assessment and point to approved options, employees naturally bring them in earlier. That reputation builds over time, and the payoff compounds: earlier involvement means more opportunities to catch something small before it grows.
Tom Scholtz, Distinguished VP Analyst at Gartner, puts it plainly: "Security becomes an enabler of innovation rather than a constraint because it is embedded in decision-making rather than applied after the fact."
Teams that earn it catch hardcoded credentials before repositories go public. They suggest secure hosting while there's still time. They handle incidents faster because they have full context on what's running. Fewer surprises, faster response, cleaner offboarding when people leave.
The Work Ahead Is Collaborative
AI is going to keep making it easier for people across every function to build software. The Stanford AI Index 2026 found that security and risk concerns are the number one barrier to scaling agentic AI, cited by 62% of organizations. Security teams that close that gap, while staying fast enough to be a useful partner, will move through this with confidence.
Adaptive's risk monitoring gives security teams continuous visibility into the AI tools, apps, and behaviors running across their organization, including apps connecting to internal systems through exposed credentials. It integrates with your existing stack and surfaces prioritized risk, so teams spend less time searching for exposure and more time closing it.
Contents
