Imagine a marketing coordinator at a mid sized company. She has never written a single line of code in her life, but she is tired of manually exporting Excel files into the CRM system every Monday morning. A colleague tells her about Lovable. One hour later, she has a small web interface connected to the HubSpot API, reading customer data and sending automated updates. It works perfectly.

What she does not know: The HubSpot API key is hardcoded directly into the source code. The app has been published without password protection. And because she used a free plan, the code is running on a shared server she does not control.

This is not a hypothetical scenario. It happens every day, in companies of every size.

The democratic side of AI coding

Tools like Lovable, Replit, Cursor, Bolt, and Claude have done something remarkable: They have made programming accessible to people who are not developers. You describe what you want in natural language, and you get working code back, complete with interfaces, logic, and integrations.

For businesses, this can feel like a dream. The IT queue shrinks. Employees solve their own problems. Internal tools appear in days instead of months. Productivity rises.

But there is a cost hidden behind the simple user experience. The person building the app does not necessarily understand what is happening under the hood.

4 things that typically go wrong:

1. API keys in the source code

Handling access keys correctly is technically challenging. Even experienced developers get it wrong sometimes. A non technical employee who asks an AI assistant to connect an app to Stripe receives code that works. What she does not see is that the access key, essentially a digital keycard that gives an app automatic access to a system without a username or password, is sitting openly in the code for anyone who gains access to the file.

Imagine someone writing the password to the company’s online banking system directly into a Word document and sharing it with the entire department. That is effectively what happens when an access key ends up in source code.

The consequences are concrete: A Stripe key grants access to all payment transactions. A Google key grants access to Drive. A Slack token allows someone to read every message across the entire workspace.

2. Missing authentication

“Build an internal portal where salespeople can see pipeline status” sounds harmless. But if the portal does not require login, or uses a simple password shared in a Slack message, it is effectively public. Search engines do not always index these apps, but they are searchable for anyone who knows what to look for.

Shodan and similar tools are used by security researchers, and attackers, to find exposed services on the internet. An internal sales portal without authentication is not “internal” simply because nobody told you it was accessible from the outside.

3. Insecure handling of user input

AI generated code is often functional, but rarely defensive. The database query may not validate input. The file paths may not check whether a user is trying to navigate to /etc/passwd. The form may accept JavaScript that executes in the next user’s browser.

SQL injection, XSS, and directory traversal are not exotic attacks. They are among the most commonly used techniques in the world, precisely because they target code written without security in mind.

4. Data leaving the company

Many AI coding tools send your code and, more importantly, the context you provide, to models running on external servers. “Here is our customer list, build an app that sorts them by revenue” may be a prompt containing sensitive business information.

This is not malicious on the platform’s side. But it does mean that data can end up in training datasets, logs, and systems the company has never evaluated in its data processing agreements.

Who owns these apps?

Here is a question IT departments rarely ask: Do we actually know which apps are being used?

Shadow IT is not new. Employees have spent years using Dropbox when the company insisted on SharePoint, or Slack when leadership preferred email. But they were typically storing files and sending messages. They were not running code with access to production systems.

AI driven shadow IT is different. An employee can now build something that connects to the company’s CRM, ERP, or accounting system, runs automated tasks on behalf of other employees, stores copies of sensitive data in a cloud database only she controls, and often either stops working, or keeps running unattended after she leaves the company. Nobody knows it exists. Nobody approved it. Nobody can shut it down.

It is not the employees’ fault

It would be easy to blame the marketing coordinator with the HubSpot key in the source code. But that is the wrong analysis. She solved a real problem, using the tools available to her, in a way that seemed reasonable. Nobody told her API keys should be treated like passwords. Nobody explained what SQL injection is. And nobody in the organization had given her a safe alternative.

The problem is structural, not individual.

4 things organizations can actually do

1. Build a sandbox, not a barrier

Ban AI coding tools, and you lose the productivity gains, while employees start using them anyway, just more secretly. A better approach is to create a dedicated environment where such tools are allowed, without access to production data and without the ability to connect to critical systems.

2. Give non technical users secure building blocks

If someone needs to connect to the Salesforce API, give them an internal gateway that already handles authentication correctly. Give them templates preconfigured with environment variables. Make it easier to do things correctly than incorrectly.

3. Monitor API usage

Most SaaS systems log which keys are used and from which IP addresses. An unusual pattern, such as a HubSpot key making 10,000 calls in the middle of the night, is a sign that something autonomous is running somewhere. It is possible to detect this, but only if someone is looking.

4. Build a culture where it is safe to ask

“I built something, but I am not sure whether it is OK” should be met with help, not punishment. Organizations where employees are afraid to admit they built something outside approved processes are exactly the organizations with the most dangerous type of shadow IT, the kind everybody knows about, but nobody talks openly about.

The real risk

What makes this topic important right now is not that employees are building insecure apps. That has happened before. What is new is the scale.

Two years ago, building an internal app with database integrations and API calls required at least basic programming knowledge. That created a natural barrier. Today, anyone with enough patience and a good AI assistant can produce functional, and potentially dangerous, code in a matter of hours.

The number of apps running inside companies without IT knowing about them is about to explode. Many of them are safe enough. Some are not. Do you know which apps are being used in your organization?

Do not shut down the tools. Give people the frameworks they need to use them responsibly.