Somewhere in your company, a colleague has built a small web app: a warehouse status board, a form that fills a spreadsheet, a dashboard that used to live in five tabs. It works. IT did not approve it, does not host it, and often does not know it exists.
That pattern has a name: shadow IT. The UK's National Cyber Security Centre (NCSC) defines it as unknown assets used for business purposes that sit outside asset management and corporate IT processes. The FFIEC puts it similarly: devices, software or services running without IT management's knowledge, approval or control.
This post covers colleagues building their own internal apps (often with AI help), why a hard ban usually fails, and how to make those apps safe instead of driving them underground.
Why people build in the shadows
The NCSC is clear that shadow IT is rarely malicious. People adopt unofficial tools when sanctioned ones are missing, slow to request, hard to share with a partner, or simply do not do the job.
For internal apps the story is familiar. Waiting for IT to ship a small tool can take weeks. Buying SaaS for a niche workflow feels heavy. A colleague who can write a bit of code, or ask an AI assistant to generate it, can have something running by Friday. IBM's overview makes the same point at team level: business units often feel procurement is too slow, so they go around it.
If your first response is "that is forbidden", those apps do not disappear. They move to a laptop, a personal cloud account or a forgotten URL. The NCSC warns that a blame culture makes people less willing to report what they are doing, which leaves you with even less visibility.
What actually goes wrong
Shadow IT is an unmanaged risk, not automatically a critical one. You simply do not know. Across NCSC, FFIEC and industry guidance, the failure modes for self-built apps look like this:
- No inventory. You cannot protect what you cannot list. NIST's Cybersecurity Framework 2.0 puts maintained inventories of software, services and systems at the heart of Identify (ID.AM-02). An app on a colleague's laptop never enters that list.
- Weak or missing login. Homemade password tables, shared links, or "it is on the intranet so it is fine" skip the MFA and offboarding path your company login already has.
- Data in the wrong place. Files and databases live outside backups, retention rules and access reviews. The NCSC highlights that you cannot be sure where data is processed or whether it is recoverable. FFIEC adds legal risk when data sits on services the organisation does not control.
- No patching or ownership. Unknown software does not get updates. When the builder leaves, the app often stays. ISACA's 2024 piece stresses the offboarding gap: local accounts on shadow systems do not follow the leaver process that disables company SSO.
- Compliance blind spots. Rules such as GDPR assume you know which systems process personal data. An unsanctioned app is an easy way to create processing you never documented.
Colleagues should not stop building. Building without a door, an owner and a lifecycle is the expensive part.
Ban versus channel
Banning shadow IT sounds clean. In practice it fights the reason the apps appeared: a real job that needed doing. The NCSC's advice is to learn from those workarounds, refine policy so people are not forced into insecure paths, and bring useful tools above board. FFIEC says to understand why the tool exists and which processes it supports before ripping it out, because a blunt removal can break delivery.
A healthier pattern for internal apps:
- Make a fast, sanctioned path to publish a small app.
- Put the company login in front of every app by default.
- Give every app an owner and a readable access list.
- Keep hosting, backups and credentials where IT can see them.
- Treat discovery as ongoing, not a one-off audit.
That matches how people already work, instead of pretending they will wait six weeks for a calculator.
How cyantula solves this
Cyantula is built for this gap: colleagues who can build faster than IT can review every tool by hand. 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.
Mapped to the problems above:
| Problem | How cyantula handles it |
|---|---|
| Apps nobody knows about | Every app lands in a portal with an owner, usage and a catalog colleagues can browse |
| Homemade or missing login | The gateway uses your company login (for example Google Workspace or Microsoft); the app never implements passwords |
| Forged identity | The gateway strips client-supplied identity and passes verified identity headers plus a signed identity token |
| "Anyone who finds the URL" | An access list per app: people, groups, or approved requests |
| Secrets bolted into the app | Integrations are switched on per app; credentials stay in the platform, not in code |
| Backups and rollback | Nightly backups, blue/green deploys and one-click restore of an earlier version |
| Builder leaves | Access follows the company account; quiet apps get flagged for archive |
| AI-built apps and agents | Publish from a repo, a zip or a conversation; agents can manage apps through MCP behind the same door and access lists |
The builder's job stays simple: say what they built and who should use it. A person stays in charge of anything risky. IT gets visibility without becoming the bottleneck for every small tool.
cyantula is free to install for one app builder and up to five users. If shadow IT in your company mostly looks like useful apps without a door, you can read more at cyantula.app.