Last week we looked at shadow IT: colleagues building their own internal apps because the official route is too slow. This week is about its faster cousin. A colleague asks an AI assistant for a small expense tracker, gets working code in ten minutes, and deploys it before lunch. Another pastes a customer list into a chatbot to clean it up. A third connects an AI agent to the shared drive "just to try it".
That is shadow AI. IBM defines it as the unsanctioned use of any AI tool or application by employees without the formal approval or oversight of IT. It is shadow IT with a new engine: the tools are easier to reach, and the output can be a whole working app.
Why it happens
The motives are the same as for shadow IT, only stronger. The NCSC's guidance on shadow IT notes that people turn to unofficial tools when sanctioned ones are missing or get in the way. IBM lists productivity and faster experimentation as the main drivers for shadow AI. AI lowers the bar so far that "I can't code" is no longer a reason to wait for IT.
That is genuinely useful. It also means your company now has apps, scripts and agents that nobody reviewed, running somewhere nobody listed.
Three risks worth taking seriously
1. Company data in prompts
Whatever goes into an AI tool leaves your control unless the tool is approved and configured for it. OWASP's LLM02:2025 Sensitive Information Disclosure names personal data, confidential business data and security credentials as the kinds of information at risk, and warns that users may share sensitive data that later shows up in model output. NIST's Generative AI Profile (AI 600-1) lists data privacy, meaning leakage and unauthorized use or disclosure of sensitive data, as one of twelve risks specific to generative AI.
For internal apps this shows up in a concrete way: an AI-built app that calls a public AI service with whatever data a user types in, using an API key pasted into the code.
2. Generated code nobody reviewed
AI writes plausible code, not necessarily safe code. In Veracode's 2025 GenAI Code Security Report, AI-generated code introduced risky security flaws in 45% of their tests, and larger, newer models did not do better on security.
There is also a supply chain angle. Researchers analysing 576,000 generated code samples found that models regularly suggest software packages that do not exist: on average at least 5.2% of suggested packages for commercial models and 21.7% for open source models. If someone later registers such a name with malicious code, an unreviewed app installs it without complaint.
A typical AI-built internal app has a login form the model invented, no access control beyond "you need the URL", and dependencies nobody checked. Usually not from carelessness, but because nobody asked those questions.
3. Agents with too much access
The newest form of shadow AI is the agent: an AI that can take actions, not just answer. OWASP calls the risk Excessive Agency: damaging actions triggered by unexpected, ambiguous or manipulated model output, typically because the agent has too much functionality, too many permissions or too much autonomy. An agent connected with a colleague's full personal access can do everything that colleague can do, at machine speed, without anyone seeing it.
Ban or channel?
Banning AI tools is even harder than banning shadow IT. They run in a browser tab, on a phone, inside tools people already use. The NCSC's lesson for shadow IT applies here too: a blame culture makes people hide what they do, so you lose the little visibility you had.
Regulation points the same way. Article 4 of the EU AI Act, applicable since 2 February 2025, is about the AI literacy of staff who work with AI systems. Its wording has since been amended, so check the current text, but the direction is clear: help people use AI well rather than pretend they don't.
A practical approach:
- Name a few approved AI tools, configured for company data, so people have a safe default.
- Be explicit about what never goes into a prompt: personal data, credentials, customer records.
- Give AI-built apps a sanctioned place to run, with the company login in front.
- Give agents their own scoped access, never a person's full keys.
- Keep a person in charge of anything risky.
How cyantula solves this
Cyantula does not control what people paste into a chatbot; that part is policy and approved tools. What it handles is the step where AI output becomes a running internal app or an agent with access. It is an internal app platform: an authenticating gateway plus a runtime on a VM you control, with your existing company login in front of every app.
| Problem | How cyantula handles it |
|---|---|
| AI-built apps nobody knows about | Publish from a repo, a zip or a conversation; every app lands in a portal with an owner, usage and a catalog |
| A login form the model invented | The gateway uses your company login; the app never implements passwords |
| "Anyone who has the URL" | An access list per app: people, groups, or approved requests |
| API keys pasted into generated code | Integrations are switched on per app; credentials stay in the platform, not in code |
| Forged identity | The gateway strips client-supplied identity and passes verified identity headers plus a signed identity token |
| Agents with a person's full access | Agents manage apps through MCP behind the same door and the same access lists |
| A bad AI-generated change | Blue/green deploys, nightly backups and one-click restore of an earlier version |
| The builder moves on | Access follows the company account; quiet apps get flagged for archive |
The colleague keeps the speed AI gives them. IT gets an inventory, a door and a lifecycle for what gets built, and a person stays in charge of anything risky.
cyantula is free to install for one app builder and up to five users. If shadow AI in your company increasingly looks like useful apps without a door, read more at cyantula.app.