Finding the AI vendors no one formally approved

Shadow AI is AI being used within an organisation without a formal security review having been completed. This covers a spectrum: from an individual using ChatGPT to draft internal documents, to a team that has built a product feature on a third-party LLM API using a personal credit card, to a SaaS administrator who enabled an AI feature in an approved tool without realising it warranted review.

The governance concern is not the existence of AI use — it is the data flows that AI use creates without corresponding review. Customer data processed by a personal ChatGPT account is not governed by any DPA. An LLM API key in a code repository may be sending production data to a model provider under consumer terms rather than enterprise data protection terms.

Shadow AI concentrates in four locations:

Browser extensions. AI-powered browser extensions are ubiquitous. Grammar and writing assistants, summarisation tools, meeting note-takers, and coding assistants all have browser extension equivalents that can access content in any open browser tab — including internal systems, customer data in web applications, and documents in cloud storage accessed through the browser.

API keys in code repositories. Engineering and data science teams frequently integrate LLM APIs directly into internal tools, scripts, and product features. When these integrations are done under individual API keys rather than enterprise accounts, the data sent to the LLM API may not be covered by an enterprise data processing agreement.

AI features in approved SaaS tools. Many SaaS tools the organisation already approves have AI features that were added after the original vendor assessment. Teams that administer those tools may enable the AI features without triggering a security review — particularly when the features are presented as standard product updates.

Consumer AI tools for internal document processing. Teams use general-purpose AI assistants — ChatGPT, Gemini, Claude — to draft documents, summarise meeting notes, analyse data, and process internal information. When this happens under consumer accounts rather than enterprise agreements, there is no DPA and no data protection commitment.

Discovery of shadow AI requires combining automated techniques — which identify the signals of AI usage in technical infrastructure — with human techniques, which surface the AI use that does not leave obvious technical signals.

The automated discovery techniques find the technical signals. The human techniques find the use that teams don't think to report because they don't realise it requires reporting. Both are necessary — neither is sufficient alone.

The discovery approach has three components: code repository analysis, SaaS feature audit, and team surveys. Each surfaces a different category of shadow AI.

Browser extension audits identify AI-powered extensions installed on managed devices. The audit requires access to the MDM or endpoint management tool that can inventory installed browser extensions across the fleet.

The audit process:

• Extract the list of all browser extensions installed on managed devices from the endpoint management tool.
• Identify extensions with AI capabilities — any extension that uses an LLM API, processes document or page content with AI, or has AI-powered features.
• For each identified AI extension, determine: who installed it, what data it can access, what permissions it has, and whether it is covered by an enterprise AI governance agreement.
• Identify extensions that have access to content on internal systems (internal web apps, cloud storage accessed through the browser) — these carry the highest data exposure risk.

The output of the browser extension audit is a list of AI extensions with their access scope and governance status. Extensions that can access internal content under consumer terms are priority items for remediation.

LLM API keys in code repositories are discoverable through repository scanning. The scan should search for API key patterns associated with major LLM providers — OpenAI, Anthropic, Google, Cohere, and others — in code repositories across the organisation's source control systems.

The scan should cover:

• Active repositories across all source control systems (GitHub, GitLab, Bitbucket, internal).
• Commit history as well as current content — keys that were committed and then removed may still be active.
• Configuration files, environment files, and CI/CD configuration that may reference LLM API keys.
• Infrastructure as code that may provision or configure LLM integrations.

For each LLM API key discovered: determine whether it belongs to an individual account or an enterprise account, what data the integration using the key sends to the LLM provider, and whether that data flow is covered by an enterprise data processing agreement. Individual API keys sending production or customer data are a material governance gap.

SaaS AI feature audits require access to the SaaS inventory and administrative accounts for each tool. The audit identifies AI features that are enabled in tools the organisation uses — whether those features were enabled by the security team, by the tool administrator, or by the vendor as a default.

For each AI feature identified: determine when it was enabled, by whom, whether it was enabled during an existing vendor assessment or after, what data it accesses, and whether the current vendor assessment covers the AI feature. AI features enabled after the original vendor assessment was completed without triggering a supplemental assessment are a common finding.

Shadow AI is typically not the result of deliberate circumvention of security processes. It is the result of teams working productively with the tools available to them. Addressing shadow AI requires a response that acknowledges this.

The framing that works: “We want to make it easier to use AI in ways that are formally approved. Here is a fast-track process for AI tools that teams are already using or want to use. We are not trying to stop AI use — we are trying to make it governable.”

The remediation approach for identified shadow AI:

• For individually adopted tools that pass a lightweight review: provide enterprise accounts under proper DPA terms and close the governance gap.
• For tools that cannot be brought under enterprise terms or present unacceptable risks: work with the team to identify an alternative that meets their need within governance.
• For tools that teams are unwilling to give up and that cannot be governed: make the governance gap explicit in a risk acceptance record with a named acceptor.

Discovery is the first step. The governance process that follows discovery turns shadow AI into assessed AI. For each item discovered, the outcome should be one of: formally assessed and approved, formally assessed and prohibited, or risk accepted with a named acceptor and documented rationale.

Ongoing governance requires a lightweight intake process for new AI tools — something fast enough that teams prefer to go through it rather than around it. The intake process should surface whether the proposed AI tool has been previously assessed, whether it requires a new assessment, and how quickly a decision can be reached.

For the vendor assessment framework that handles newly discovered AI tools, see The AI section your vendor security questionnaire is missing.