AI coding tools turned every knowledge worker into a developer. The monitoring stack you bought in 2020 was not designed to see what happens next.
We gave Claude Code a single instruction on a laptop with nothing pre-installed for tunneling:
Claude Code did exactly that. It checked whether the local service was listening. It confirmed cloudflared was available. It started an ephemeral quick tunnel. Thirty-seven seconds later, the laptop's localhost:3000 was reachable at a public URL: translation-commitments-cameras-tuner.trycloudflare.com.
No Cloudflare account. No config file. No authentication prompt. No approval step. No notification to anyone.
What a visitor sees when they visit the URL. No login, no gate. The browser is rendering a page served directly from the employee's laptop, reachable from any network on the internet.
Same URL, different path. Because the local server started with default settings, the root path returns a file index. Every file in the served folder is now browsable from the public internet. The employee did not intend this. The employee did not even see it. It is the default behavior of the server the agent chose.
Every step along the way was technically correct. The employee got what they asked for. The instruments the company bought to monitor SaaS exfiltration did not fire, because nothing was exfiltrated. The data stayed on the laptop. A tunnel opened a door to it.
Whether anything actually protects what sits behind the URL depends entirely on whether the employee thought to ask. Most employees don't know to ask. That welcome.txt in the screenshot could have been a customer list, a database backup, an exported contract, or a set of `.env` credentials. The tunnel treats them identically.
"Make my local app accessible to my team." No technical flags, no security clauses, no deployment knowledge required.
Runs lsof -iTCP:3000 -sTCP:LISTEN to confirm the service is listening. Confirms cloudflared is available on the system.
cloudflared tunnel --url http://localhost:3000 --no-autoupdate. No account required, no config, QUIC to the Cloudflare edge.
Random subdomain on trycloudflare.com, reachable from anywhere on the internet.
37 seconds from prompt to live URL. Employees notified: one. Security team notified: zero.
In 2015, shadow IT meant someone in finance saving a spreadsheet to personal Dropbox. The concern was access. Data went to a place IT didn't control.
What's happening now is different in kind. Every employee with a ChatGPT or Claude subscription can:
Run shell commands through natural language. Read local files, inbox, Drive, or Slack through MCP connectors installed in one click. Call any SaaS API they have credentials for. Deploy applications to the public internet in seconds. Install dependencies, write to disk, schedule background tasks.
Shadow IT took data somewhere. Shadow production builds pipelines, deploys services, and operates them in the employee's name, using the employee's credentials, touching corporate data, producing artifacts that outlive the session. The 2020 DLP playbook was written for the first. It was not designed for the second.
The defining shift of 2024-2026 is not that coding got faster. It is that coding became linguistically accessible to people who don't code. A person no longer needs to know Python to ship a Python script. They need to know the outcome they want.
That collapses the assumption inside most security programs: "developers are a bounded population, trained on secure coding, with access controlled by engineering management, producing artifacts that go through code review and CI/CD."
Each clause is getting weaker. Anyone with a laptop is a potential developer. The person writing the prompt usually has no training in credential handling, auth, or secure defaults. The tool is often acquired personally or included in a blanket SSO rollout. The person who wrote the prompt is the only human who reads the output. And the agent frequently deploys directly. No CI, no review, no gate.
The Stanford study by Perry, Srivastava, Kumar, and Boneh on AI-assisted coding found that developers using AI assistants wrote significantly less secure code and were more likely to believe their code was secure. That study used actual developers. Extend it to a non-developer using the same tool and the gap widens. The person writing the prompt typically cannot detect a SQL injection, a missing auth check, a hardcoded key, or a dashboard exposed without login. They can only detect whether the app appears to work.
The app often appears to work. It also often leaks.
A controller wants to reconcile three months of expense exports with the ERP. Opens ChatGPT Desktop on a personal-tier account, uploads CSVs (one contains vendor tax IDs), asks for a reconciliation script, runs it locally, hits an error, pastes a sample row back to debug. The script works. Whether that data sat on consumer servers under training defaults depends on account settings. Either way, there is no audit trail the employer can reconstruct later.
A paralegal wants to compare clauses across 300 client NDAs. Uses an AI coding tool to write a script that reads each PDF from SharePoint, parses locally, posts each clause to an inference API for classification. The spreadsheet is useful. Three hundred NDAs just made a round trip to an external endpoint over the course of an hour. Some clients may have contractual restrictions on where their documents can be processed. Nobody in legal ops was asked.
A manager wants a dashboard that tracks campaign ROI against a HubSpot account list. Claude Code builds it. When asked "how can my team use this," the agent reaches for the lowest-friction option, a tunnel. The URL lands in Slack. A few teammates bookmark it. Weeks later, an external attack-surface scan surfaces a *.trycloudflare.com host returning paginated CRM data. Whether there was authentication on that app depends on what the manager asked for when it was built. Usually they didn't know to ask.
In all three, intent was legitimate. Policies existed. DLP was running. EDR was running. None of those controls was designed to see the composite workflow, because the workflow lives across the employee's prompt, the agent's shell, SaaS API calls, and an ephemeral public URL. No single instrument in the stack watches that whole path.
The typical 2026 enterprise AI governance program funds a policy document, a managed ChatGPT Enterprise or Claude for Work SSO rollout, DLP rules that flag uploads to public LLM domains, security training, and an AI gateway that inspects outbound inference traffic. Here is what that stack watches versus what it does not.
Every action in the right column is the agent acting as the user, with the user's credentials, through sanctioned local processes. The 2020 instruments were not wired to tell these apart from legitimate work. The governance stack was built for a threat model where the concern was text going into ChatGPT. The operative threat now is arbitrary code executing as the user, driven by ChatGPT, at a speed and surface area nobody sized for.
Skip the big program. Four steps, each doable in weeks, that shift the conversation from "write a policy" to "see what's happening."
Not what IT provisioned. What is running. CLIs, IDE extensions, desktop apps, browser extensions with coding behavior. Combine survey with endpoint telemetry. The real number is usually several multiples of the formal count.
External attack-surface sweep focused on *.trycloudflare.com, *.vercel.app, *.netlify.app, *.fly.dev, *.ngrok.io, and similar one-command deploy domains, cross-referenced against company name, employee emails, and internal project names. Most enterprises running this scan for the first time find at least one live surface nobody knew existed.
Deploy telemetry that observes what coding agents actually do, not just what employees paste. That means instrumenting the agent itself (CLI and IDE) and watching the browser for web-based AI surfaces. HTTP proxies in front of model endpoints don't see the full picture. DLP doesn't either. The control surface is the agent.
Rewrite the AI policy to name actions, not products. "Reading /finance/* with any automated tool requires approval" is enforceable. "Do not misuse AI" is not. Name the actions that matter: reading credential files, calling production APIs, deploying to the public internet, installing unvetted MCP servers, writing to shared storage.
Your AI governance budget is probably tracking the wrong risk. You're worried about models hallucinating. Worry instead about every employee in your company having a shell, a credential store, a SaaS integration layer, and a one-command public deployment, all driven by plain English, all presented as productivity, most of it invisible to the instruments you already bought.
The next data leak in your company may not come from a developer. It may come from an employee in marketing, finance, legal, or ops who had a Monday-morning pain point and solved it with the tool they already had open. They will have done nothing wrong, by their understanding. Monitoring will show nothing unusual, by its design. The URL may stay up until someone notices.