When business departments create AI apps without involving IT

AI has changed the way shadow IT is born. Previously, a department would purchase a SaaS without informing IT. Today, they can build a small app, a workflow, a dashboard, or an internal tool in a few days, connect it to spreadsheets, CRMs, emails, tickets, documents, or databases, and start using it as if it were an official corporate system.

The problem is not that the business wants to solve its own issues: it is that a useful solution can become invisible. No inventory, no technical owner, ungoverned access, data uploaded outside the perimeter, personal API keys, public links, no retention policy, and no plan if something breaks.

For CIOs, CISOs, IT managers, and business leaders, the concrete question is: which AI-created apps already exist, what data do they process, and which ones must be regularized before they become critical?

Why AI accelerates the proliferation of shadow IT

AI app builders and “vibe coding” tools significantly lower the technical barrier. A marketing team can create a tool to segment leads, Finance can automate reconciliations, HR can build a form with an approval workflow, and Operations can connect spreadsheets, emails, and tickets in a few days. Many of these initiatives are born for legitimate reasons: long IT backlogs, operational urgency, limited budgets, or the need to prototype quickly.

The critical point is that as soon as the app handles real data, users, integrations, or operational decisions, it is no longer just an experiment. Unlike traditional shadow IT, the app is custom-built rather than purchased as a finished product: this makes it harder to inventory and makes it even more important to understand how it is made — including code, configurations, storage, workflows, APIs, credentials, domains, logs, and data.

The first check: does the app exist in the inventory?

The first step is to know that the app exists. If IT cannot see it, it cannot apply SSO, backups, logging, vulnerability management, data policies, incident response, or decommissioning. A useful inventory must include at least these elements:

• App name and owner department
• Operational purpose
• Tool used to create it
• Internal or external users
• Data processed
• Integrations and APIs
• URLs, domains, previews, and environments
• Credentials and accounts used
• Criticality to the business process

You don’t need to start with a perfect census. You need a repeatable process: surveys to departments, discovery on domains and SaaS, review of OAuth apps, repository checks, cloud cost analysis, and a simple channel to declare existing apps without fear of immediate blocking.

Classifying data and assessing impact

Not all shadow IT apps present the same level of risk. A tool that reformats public text is very different from a dashboard containing customer data, invoices, tickets, HR data, or health information. Classification must answer a few essential questions:

• Does it process personal or customer data?
• Does it contain confidential, commercial, financial, HR, or contractual data?
• Does it read from or write to corporate systems?
• Does it send data to external providers or AI models?
• Does it produce operational decisions or just reports?
• Is it used by multiple people, departments, or external parties?
• What happens if it stops, loses data, or exposes information?

The answers determine the path: tolerate with minimal controls, regularize, test, migrate to an approved platform, or decommission.

Access: shared links, personal accounts, and missing roles

Many apps born in business departments start with simple access — shared links, common passwords, personal accounts, manual email lists, or “editor” permissions for everyone. As long as usage is restricted, it seems to work, but when a new team, a consultant, or an external user joins, the model fails. The minimum controls to apply are:

• Named accounts
• SSO and MFA where possible
• Removal of shared accounts
• Revocation of access when a person changes roles or leaves the company
• Roles consistent with reading, editing, exporting, and administration
• Logs on access and critical actions

For apps with customer or multi-department data, it is also useful to test direct access: can a user change an ID, URL, filter, workspace, or parameter and see data that does not belong to them?

Integrations and API keys: the hidden risk

To be useful, a shadow IT app often connects to something: Google Workspace, Microsoft 365, CRM, ticketing, email, storage, ERP, databases, Slack, webhooks, or payment services. The connection typically occurs via personal tokens, copied API keys, unapproved OAuth apps, or service accounts with excessive permissions. This is one of the most critical points: a small app can have broad access to corporate data, and if it is compromised, the damage does not remain confined to the app itself.

Practical controls to apply include:

• Inventory of tokens, OAuth apps, service accounts, and webhooks
• Minimal scopes for every integration
• Corporate credentials, not personal ones
• Periodic key rotation
• Segregation by environment
• Audit logs on the most sensitive calls
• Revocation of unused integrations

Public exposure, previews, and temporary domains

App builders make it easy to publish a preview or a temporary domain. The business department might share it with colleagues, partners, or customers without perceiving it as exposure on the internet. Elements to check include:

• Public URLs and previews still active
• Custom domains and temporary subdomains
• Indexing by search engines
• Webhooks reachable without authentication
• Admin or debug endpoints
• Public storage
• Overly broad CORS and callbacks

When the app is reachable online and handles logins, APIs, real data, or roles, an inventory is not enough: a technical test is required. In these cases, Web Application Penetration Testing verifies the actual behavior of the application, not just the declared configuration.

Logs, exports, retention, and deletion

Apps created by the business often revolve around exports and spreadsheets: CSVs from CRMs, financial reports, customer lists, tickets, attachments, uploaded files. The risk is not just unauthorized access, but the ungoverned accumulation of sensitive data. It is necessary to know where logs and outputs are saved, who can export data, how long files and transcripts remain, if backups exist, how to delete data, and what happens when the project is abandoned.

An app that is no longer used but still connected to corporate data is a silent risk: it continues to have active credentials, links, and storage, but no longer receives operational attention.

Regularizing without blocking value

If IT only arrives to forbid, shadow IT will hide. An effective path must classify and regularize, producing a clear decision for every app: maintain, correct, migrate, test, or shut down. It is not enough to “fix it sooner or later.”

Class	Example	Action
Low risk	Tool without real data, individual use	Register owner and expiration
Medium risk	Internal dashboard with non-critical data	SSO, access, retention, backup
High risk	App with customer data, APIs, or operational workflow	Risk Assessment, technical review, test
Critical	Public app, multi-user, sensitive data	WAPT/VA, remediation before extended use
Unacceptable	Shared credentials, prohibited data, unapproved vendor	Decommission or migrate

Checklist for AI-created shadow IT apps

• Is the app registered in an IT/security inventory?
• Is there a business owner and a technical owner?
• What data does it process and where does it come from?
• Does it use personal, customer, HR, financial, or contractual data?
• Is it accessible from the internet, by partners, or only from the internal network?
• Does it use SSO/MFA or shared accounts?
• What API keys, OAuth apps, webhooks, or integrations does it use?
• What roles exist and who can export data?
• Where do logs, files, exports, backups, and transcripts end up?
• Are there previews, temporary domains, or old versions still active?
• Has at least one access test been performed with different users?
• Is it clear what to do if the app is compromised or needs to be decommissioned?

When to involve ISGroup

The starting point can be a lightweight assessment: inventory, data, exposure, owners, integrations, and risk. The subsequent control depends on what emerges.

Scenario	Main risk	Recommended control
Many uninventoried apps created by departments	Weak governance and absent ownership	Virtual CISO
Need to classify data, impacts, and priorities	Risk not understood or not prioritized	Risk Assessment
Apps, hosts, domains, previews, or services exposed	Known vulnerabilities and open configurations	Vulnerability Assessment
Web apps or APIs with logins, data, roles, or real users	Application abuse from the outside	Web Application Penetration Testing

The choice is not “do security on everything.” It is deciding which apps are tolerable, which must be regularized, which require a technical test, and which must be shut down — before they become an operational or regulatory problem.

Useful evidence for a verification

To start a structured verification, it is useful to collect: list of apps, owners, URLs, tools used to create them, data processed, users, roles, integrations, API keys, OAuth apps, involved providers, logs, exports, backups, domains, previews, environments, and process criticality. Concrete examples are also useful, such as screenshots, exports, workflows, data schemas, access configurations, lists of connectors, user lists, and descriptions of what happens if the app is unavailable.

Frequently asked questions

• Should AI-generated shadow IT always be blocked?
• No. It must be discovered and classified. Some apps can remain operational with minimal controls, while others must be regularized, tested, migrated, or decommissioned based on the risk they present.
• What is the first check to perform?
• The inventory. Without knowing which apps exist, what data they process, and who uses them, any technical control arrives late and without context.
• When is a Web Application Penetration Test needed?
• When the app is reachable online, exposes APIs, handles logins, real data, roles, uploads, payments, or workflows used by multiple users.
• When is a Risk Assessment sufficient?
• When the main problem is deciding priorities, owners, data processed, business impact, and the regularization path before starting technical tests.
• Who should be responsible for the app?
• You need at least one business owner for processes and data, and an IT/security owner for access, controls, integrations, and the regularization path.

Sources and references

• NIST Cybersecurity Framework
• NIST AI Risk Management Framework
• CIS Control 1: Inventory and Control of Enterprise Assets
• OWASP ASVS
• OWASP SAMM