Shadow AI apps: the internal tools your team built with AI are now in NIS2 scope

TL;DR: AI-built internal tools security has become a compliance issue, not just a technical one. Vibe coding, building applications by describing them to an AI model, has filled many companies with tools IT does not know about: quote calculators, forms, reporting dashboards wired into the CRM. Some of them process customer data. Research from 2025 and 2026 shows that most such applications have security flaws, most often in access control. For any company covered by NIS2, each of those tools is an asset that must be inventoried and controlled. This article explains where the risk comes from and how to bring AI-built tools under control in six steps without banning them.

This post is part of our guide to NIS2 software requirements and the Cyber Resilience Act, which covers every duty that lands on software.

Key facts:

• In a review of 200 deployed repositories built with AI coding tools, 90% had at least one vulnerability.
• Veracode found that 45% of AI-generated code samples failed security tests based on the OWASP Top 10.
• A scan of 5,600 publicly deployed vibe-coded apps found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets and 175 instances of exposed personal data.
• NIS2 requires asset inventory, access control and vulnerability handling, with no exception for tools employees built themselves.

What is vibe coding and why is it in your company?

Vibe coding is a way of building software where a person describes what they need and an AI model writes the code. Andrej Karpathy popularised the term in 2025 to describe building apps without reading the code. Tools such as Lovable, Bolt, Replit and Cursor now let anyone build a working application with a database and sign-in in an afternoon, with no programming background.

Inside companies, vibe coding solves a real problem. IT has a quarter’s worth of tickets in the queue, and a salesperson needs a quote calculator by tomorrow. If they can build it themselves, they do. That is how useful tools appear: they work, they save time and they often genuinely help. The trouble starts when a tool connects to the CRM, takes in customer data and goes live on the internet, and nobody has checked who can reach it.

AI-built internal tools security: what does the research show?

The data on AI-built internal tools security from 2025 and 2026 is consistent: applications built with AI and shipped without a security review have flaws far more often than their creators assume.

• The Cloud Security Alliance found that 62% of AI-generated code solutions contain design flaws or known vulnerabilities, even with the latest models. It also documents a January 2026 case in which a single Firebase misconfiguration in an AI-built platform exposed 406 million records.
• Veracode tested more than 100 language models on 80 coding tasks; 45% of the code samples failed security tests based on the OWASP Top 10.
• Escape scanned more than 5,600 publicly deployed vibe-coded applications and found over 2,000 high-impact vulnerabilities, more than 400 exposed secrets such as API keys and database passwords, and 175 instances of exposed personal data.
• In the August edition of Vibe Coding Security Monthly, 180 of 200 deployed repositories (90%) had at least one vulnerability, most often broken access control, and 57% of reachable Supabase-backed apps allowed unauthenticated table reads.
• IBM, citing GitGuardian, reports that commits made with one popular AI coding assistant exposed secrets more than twice as often as human-only commits.

The lesson is not “AI writes bad code”. It is that AI writes code that works, and security is rarely part of the prompt. The model will build the form and the database, but if nobody asks for table access rules, there will be none.

Why do AI-built tools fall under NIS2?

NIS2 and national laws such as Poland’s KSC Act do not distinguish between applications written by a software house, bought from a vendor or built by an employee in a browser. For a company in scope, each one is an asset of its information system, and the law requires the company to:

• know its assets, meaning an inventory of applications and the data they process,
• control access to its systems,
• develop and maintain software securely, including fixing vulnerabilities,
• assess suppliers, including the platforms on which these tools are built and hosted,
• detect and report incidents, including a data leak from a tool IT never knew about.

The key point for AI-built internal tools security is that essential and important entities must have an information security management system in place by 3 April 2027. A tool missing from the inventory is covered by nothing in that system.

The GDPR applies regardless. If a quote calculator stores customer contact details in a database anyone can read without signing in, a leak is a personal data breach that must be reported to the data protection authority.

Shadow AI apps: how do you know you have them?

Shadow AI means AI-based tools and applications a company uses without IT’s knowledge or control. A few signs that AI-built apps are already running in your business:

• subscriptions to platforms such as Lovable, Bolt, Replit or Vercel appear in expenses, paid on a department card,
• staff send customers links to forms or calculators on domains the company does not recognise,
• the CRM or shared spreadsheets have integrations added by people outside IT,
• someone says “I built a little app for that” and nobody asks where it runs or who can access it.

None of these signs means bad intent. They mean people are solving problems faster than the company’s rules can keep up.

Six steps to AI-built internal tools security

1. Find the tools. Run a short, no-blame survey (“what have you built with AI and what do you use it for?”), and review subscriptions in expenses and sign-ins through company accounts. No-blame matters: if people are afraid, they will hide their tools.
2. Assess the risk. Ask three questions about each tool: what data does it process, who can reach it from the internet, and what does it connect to? A public tool holding customer data and linked to the CRM goes to the front of the queue.
3. Secure the urgent issues. Turn on table access rules in the database (for example Row Level Security in Supabase), enforce sign-in, rotate API keys that may have ended up in code, and take public URLs offline. For a self-check, use [a 12-point security checklist for AI-built apps – link after the January publication].
4. Decide each tool’s future. There are three options: hand the tool to IT and maintain it like any other application, rebuild it properly if it matters to the business, or switch it off if it is no longer needed.
5. Set the rules. An approved list of platforms, minimum requirements (sign-in through a company account, no customer data without IT approval, a review before anything is shared externally) and a simple way to register a new tool.
6. Keep the inventory current. New tools go into the application inventory just like systems bought from vendors. Once a quarter, a short review: what has been built, and what is no longer used.

Banning vibe coding rarely works. People keep building tools; they just stop talking about them. Giving them a safe route does more for AI-built internal tools security than pushing the problem further into the shadows.

What does a security review of an AI-built tool involve?

Checking AI-built internal tools security does not have to be a big project. It starts with a conversation with the person who built it: what the tool does, where its data comes from and who sees it. A developer then checks the platform and database configuration: whether tables have access rules, whether sign-in is enforced and whether public URLs give data away. Next comes the code itself, checked for secrets, dependencies with unpatched vulnerabilities and places where the application trusts user input without question.

The result is a short list: what must be fixed now, what can wait a few weeks and whether the tool is worth keeping at all. For a simple calculator or form, a review usually takes one to a few days. For a company covered by NIS2 it has a second benefit: it is evidence that the tool was assessed and brought into the information security management system rather than left out.

From shadow AI to managed tools: inventory, review and handover

Sanddev helps companies take control of AI-built tools: we inventory and review them for security, fix the gaps, and rebuild or take over maintenance of the tools that matter to the business. See what taking over an internal tool nobody fully understands involves.

FAQ