An employee pastes a customer escalation into a public chatbot to draft a response. A developer sends source code to an API model through a personal account. A marketing team turns on an AI feature inside a SaaS platform that was never reviewed. None of these actions may trigger a traditional security alert, but each can create material exposure. Learning how to uncover unauthorized LLM usage starts with seeing the behavior that existing controls were not built to recognize.
Unauthorized LLM use is not limited to a short list of public chatbots. It includes browser-based AI assistants, direct model APIs, AI capabilities embedded in approved SaaS products, locally installed developer tools, and extensions that route content through third-party inference services. The security problem is not simply that employees are using AI. It is that security teams often lack the evidence to determine which models are in use, what data reaches them, who is responsible, and whether the activity violates policy or creates a reportable risk.
Visibility first. Then control.
Why unauthorized LLM usage is difficult to detect
Most enterprise monitoring was designed around applications, endpoints, identities, and network destinations. LLM usage cuts across all four. A user can access a web-based model from a managed browser, call an API from a build pipeline, or invoke an AI feature inside a sanctioned business application. Each path produces different telemetry, and no single data source tells the full story.
The destination alone is also not enough. An approved AI vendor can be used through an unapproved personal tenant. An approved SaaS application can enable a new generative feature that changes its data handling profile. A developer may call a permitted API model from an unmanaged script with an exposed key. Security teams need context, not just a domain match.
There is a second challenge: usage is not automatically misuse. Blocking every AI interaction will drive activity further outside sanctioned channels and make investigation harder. The goal is to identify unapproved, anomalous, or high-risk activity with enough evidence to make a defensible response decision.
How to uncover unauthorized LLM usage across the enterprise
Effective discovery combines multiple signals into a usable picture of AI activity. Start by defining what counts as unauthorized in your environment. That may include unapproved providers, personal accounts, models that do not meet data residency requirements, API access outside approved projects, or sensitive-data handling that conflicts with policy.
Then collect evidence from the systems that reveal different parts of the interaction. The most useful sources usually include:
- Secure web gateway, proxy, DNS, and firewall telemetry that shows AI service access and traffic patterns
- Endpoint and browser telemetry that identifies installed assistants, extensions, local tools, and application activity
- Identity and SaaS audit logs that connect use to users, tenants, business units, and embedded AI features
- Cloud, code repository, and API gateway logs that expose model calls, service accounts, tokens, and automation workflows
These sources should be correlated rather than reviewed in isolation. A browser event may show that a user visited an AI service. Identity data can determine whether the user authenticated with a corporate or personal account. Data classification context can indicate whether the device, repository, or workflow handles regulated or proprietary information. Together, those signals turn a vague event into an investigation lead.
Establish an inventory from observed behavior
Do not begin with a questionnaire asking teams which AI tools they use. It can help, but self-reporting is incomplete by design. Start with observed usage and build an inventory that includes the provider, model or feature where identifiable, access method, user or service identity, business unit, environment, and first and last observed activity.
Separate direct model access from AI embedded in software the business already trusts. This distinction matters. A team may have an approved CRM platform, for example, while its new generative drafting feature has separate data retention, training, or cross-border processing implications. Treat AI capabilities as a distinct risk surface, even when they arrive inside an approved application.
Inventory should also distinguish personal from enterprise accounts. The same public LLM service carries very different control and evidentiary implications depending on whether the interaction occurred in a managed enterprise tenant with contractual protections or a personal account outside organizational control.
Identify the activity that deserves attention first
Once you can see usage, prioritize based on risk, not volume. The user who asks a public model for general meeting ideas is different from a service account transmitting large payloads to an unknown inference endpoint. The objective is to surface the activity most likely to expose sensitive data, intellectual property, credentials, or regulated records.
Useful risk signals include access from privileged users, engineering workstations, regulated business units, production environments, and devices associated with sensitive repositories. Watch for new or rare providers, rapid growth in usage, unusually large transfers, activity outside normal working patterns, and API keys used from unexpected hosts or geographies.
Developer workflows need particular attention. LLM integrations can be hidden in package dependencies, CI/CD jobs, IDE extensions, command-line tools, and internal scripts. A code assistant may be approved while a separate extension or API endpoint is not. Investigate the actual model destination, account ownership, key management, and data path instead of relying on the tool name alone.
Investigate with enough context to act
An alert that says “user accessed an AI site” is rarely sufficient. Analysts need an investigation record that explains why the event matters. At a minimum, connect the activity to the user or service account, device, application or browser, provider, account type, timeframe, business context, and applicable policy.
Where security and privacy requirements permit, add interaction-level context carefully. This does not mean indiscriminate collection of every prompt. It means applying proportionate inspection and classification controls to determine whether content categories such as credentials, source code, customer records, financial data, or health information may have been exposed.
Preserve the evidence needed for response. Record the observed destination, timestamps, authentication context, related endpoint events, and any relevant data classification findings. If an incident later requires legal, compliance, or leadership review, a defensible timeline is more valuable than an unsupported assumption that “shadow AI” occurred.
Investigation should lead to a clear disposition. The usage may be approved after validation, moved to a managed tenant, restricted pending review, or escalated as a potential exposure. When the risk is real, contain the specific pathway: revoke exposed credentials, remove an extension, block an unapproved endpoint, or require the workflow to use a sanctioned integration. Broad controls have a place, but targeted action reduces unnecessary disruption.
Turn discovery into an operating practice
Unauthorized LLM usage changes quickly. New model providers, features, extensions, and API integrations appear faster than most policy review cycles. A one-time discovery project becomes stale almost immediately.
Make AI visibility part of normal security operations. Review newly observed providers and high-risk usage patterns on a defined cadence. Feed confirmed findings into your approved-tool inventory, vendor assessment process, data handling standards, and incident workflows. Give business teams a practical path to request an approved alternative, because a policy without a usable option will not change behavior.
Metrics should measure exposure and response quality, not just total AI traffic. Track newly discovered services, personal-account use, high-risk users or environments, unreviewed embedded AI features, time to triage, and the percentage of activity mapped to an approved owner and use case. These measures show whether visibility is becoming actionable control.
Avoid the common discovery mistakes
The first mistake is treating a blocklist as discovery. Blocklists only identify destinations you already know, and they do not reveal approved services used through the wrong account or risky features embedded in sanctioned platforms.
The second is focusing only on web traffic. Direct APIs, local tools, cloud automation, and developer integrations can bypass the browser entirely. The third is collecting broad telemetry without a way to explain risk. Security teams need to move from raw events to a clear answer: what happened, who was involved, what data may be affected, and what action is required.
Finally, do not make policy enforcement the starting point. Restrictive controls before visibility create blind spots, workarounds, and friction with teams that may have legitimate needs. Understand real behavior first, then apply controls that fit the risk and the workflow.
The practical test is simple: when leadership asks where AI is being used, which activity is unapproved, and whether sensitive data is reaching external models, your team should be able to answer with evidence. That is the foundation for AI security that can withstand scrutiny and keep pace with adoption.