AI adoption can outrun oversight. For security and risk leaders with lean teams, blocking unfamiliar tools solves only part of the problem. Personal accounts, new SaaS features, and autonomous agents can appear before anyone knows they need review.
That uncertainty is measurable. An Osterman Research survey of 750 enterprise leaders published in June 2026 found that 17.6% of respondents’ organizations could not determine whether employees were using unsanctioned AI tools. For unsanctioned AI-agent activity, the figure rose to 21.1%.
Closing that visibility gap requires partial evidence and business context. The process begins by defining what falls within the scope of shadow AI.
Shadow AI is any AI capability used outside approved organizational oversight. That includes standalone AI tools as well as models, integrations, workflows, and agents. The problem is not limited to employees signing up for unapproved chatbots.
It includes obvious examples, such as an employee using a consumer chatbot with a personal account. It also includes less visible cases:
That makes shadow AI different from traditional shadow IT. The software itself may already sit inside the approved technology stack. The concern may come from the information fed into it, the permissions granted to it, or the actions an agent can take.
Finding an unfamiliar AI service is therefore only the start of an investigation. Security teams still need to establish how it is being used before deciding whether the activity creates a material risk.
Most organizations do not have one system that shows every form of AI use. A personal AI account may never touch enterprise identity controls. Local models can run without generating a recognizable login event or network destination. An AI feature built into an approved SaaS platform may use the same infrastructure as the rest of the application.
Encrypted traffic creates another problem. A proxy log might show that someone connected to an AI service, but it does not necessarily reveal what they entered into it.
For that reason, shadow AI detection depends on correlation. Identity logs can tell you one part of the story. Endpoint data, network telemetry, OAuth permissions, procurement records, and conversations with business owners fill in other pieces.
Start by deciding who owns the process. Depending on the organization, that may sit with security, IT, risk, or an AI governance group.
Include employees and contractors, but do not stop there. Agents, service accounts, API keys, and other non-human identities can also introduce AI capabilities into the environment.
For each finding, the investigation should answer a few practical questions. What AI capability is being used? Which person or non-human identity is using it? Where is it running? What information or systems can it access? Who owns the use case? Has the organization approved it?
Set privacy and monitoring boundaries before collecting detailed activity. Security teams need enough visibility to investigate risk without collecting information that the organization has no legitimate reason to inspect.
You cannot identify an exception without knowing what normal looks like.
Build an inventory of approved AI capabilities. Include dedicated AI products and AI features inside software that the organization already uses. For each one, record the owner, approved tenant or account type, intended use, permitted data, integrations, and expected data flow.
Check existing SaaS products again even if they passed a security review in the past. Vendors continue to add copilots, assistants, summarization tools, model integrations, and agent features after deployment.
Include approved pilots and temporary exceptions, too. Otherwise, security teams may spend time investigating activity that the business has already reviewed.
SSO and SaaS audit logs provide a useful starting point for AI services tied to enterprise accounts.
Look for sign-ins to known AI platforms and activity inside AI-enabled SaaS products. Then review OAuth grants, delegated permissions, enterprise applications, and marketplace add-ons.
Small integrations deserve attention. A meeting assistant, summarization extension, or productivity add-on may gain access to calendars, email, documents, or other business data after a user clicks through a consent screen.
Agents require another check. Identify the credentials or non-human identity each agent uses, who authorized the connection, who owns it now, and which systems it can reach. Broad permissions, stale grants, shared accounts, and unclear ownership should move up the review queue.
Identity evidence will not catch everything. Personal accounts, anonymous services, and AI tools that sit outside enterprise authentication can remain invisible.
Managed endpoints can uncover AI activity that identity systems miss.
Review installed desktop applications, coding assistants, browser extensions, local model runtimes, API clients, and automation tools. Development environments may also contain AI-related packages, agent configuration files, model dependencies, or connections to code repositories and CI/CD systems.
Browser extensions deserve close attention because some can read page content, access the clipboard, interact with local files, or send information to external services.
Endpoint data still has limits. An employee working from an unmanaged computer, personal browser profile, or mobile device may sit outside corporate telemetry.
Treat endpoint evidence as one source among several rather than a complete inventory.
Next, examine the network evidence you already collect.
DNS, proxy, firewall, secure web gateway, CASB, cloud, and API logs can reveal connections to known AI services and unusual patterns of activity. Look for repeated model calls, unexpected uploads, large transfers, or systems communicating with AI services that have no documented business reason to do so.
Tie each event back to an identity, device, workload, and timestamp where possible.
Be careful with conclusions. A connection to an AI domain does not prove that someone exposed sensitive information. Encrypted traffic may hide the payload unless the organization uses inspection or content-aware controls.
Network monitoring can also miss local models, embedded SaaS features, unknown services, off-network activity, and personal devices. Use it to identify leads, then confirm what happened through other evidence.
Sometimes the clearest sign of shadow AI is the data moving toward it.
DLP and other data-security tools can surface attempts to send customer information, regulated datasets, source code, contracts, credentials, financial records, or other sensitive material into AI services.
Investigate the surrounding context rather than assuming that every alert represents misuse. Inspect content only when organizational policy, risk, and applicable law justify it.
Procurement records reveal a different class of activity. Expense claims and purchasing systems may show AI subscriptions that never appeared in identity or network data. They will not expose free accounts, bundled AI features, or subscriptions purchased with personal payment methods.
Employees themselves can fill some of those gaps. A simple self-reporting process, help-desk tickets, and conversations with business teams often explain why an unapproved tool appeared in the first place.
At this point, security teams should have several pieces of evidence rather than a single definitive signal.
Connect them.
Map the identity to the device, application, relevant network activity, permissions, data movement, and purchasing information. Then speak with the business owner to confirm the purpose of the tool or workflow.
Create a separate inventory record for each distinct AI capability, including integrations and agents. At minimum, record:
Evidence confidence matters. Security teams should distinguish a weak signal, such as a domain visit, from stronger evidence, such as an audit event tied to a named user and a confirmed business use case. Recording that distinction helps teams avoid treating assumptions as confirmed incidents.
The resulting AI inventory can support a broader NIST AI RMF implementation. The framework is voluntary, so organizations can adapt it to their environment and risk profile.
Choose the next data source based on the most important blind spot.
|
Signal |
What it can reveal |
Common blind spots |
|---|---|---|
|
SSO and SaaS audit logs |
Enterprise authentication and, when supported by the application, user activity or use of specific AI features |
Personal accounts, anonymous access, and applications that provide limited audit events |
|
OAuth grants and delegated permissions |
Applications, integrations, and agents authorized to access enterprise data; granted scopes; authorizing users; and consent history |
Tools that do not use OAuth, activity performed with separate credentials, and permissions that do not show how access was actually used |
|
Endpoint and software inventory |
Installed AI assistants, local model runtimes, development packages, API clients, and automation tools on managed devices |
Unmanaged devices, browser-only use, portable applications, and activity not captured by the endpoint platform |
|
Browser and extension telemetry |
AI destinations, installed extensions, and—depending on the controls deployed—page-level interactions, file transfers, or data-entry activity |
Unmanaged browsers, personal profiles, encrypted content, privacy constraints, and limited visibility into embedded SaaS features |
|
DNS, proxy, SWG, and CASB telemetry |
DNS lookups, routed sessions, known AI destinations, traffic patterns, and, where inspection or content controls are enabled, some upload activity |
Encrypted payloads without inspection, off-network activity, local models, embedded AI features, and previously unknown services |
|
DLP and data-security telemetry |
Potential movement of classified, regulated, proprietary, or otherwise sensitive data toward AI tools or workflows |
Incomplete coverage, false positives, encrypted or unsupported channels, and activity outside monitored environments |
|
API, cloud, and workload logs |
Model calls, API-key or workload-identity usage, service principals, automated workflows, agents, and access to connected cloud services |
Shared credentials, unmonitored accounts, incomplete logging, local execution, and limited context about the business purpose |
|
Development and CI/CD telemetry |
AI-related packages, coding assistants, agent configurations, repository integrations, pipeline activity, and model or API dependencies |
Developer-owned environments, personal tokens, local experimentation, and activity outside governed repositories or pipelines |
|
Procurement and expense records |
Paid subscriptions, team purchases, AI-related vendor relationships, and business owners associated with spending |
Free tiers, personal payment methods, bundled AI features, and tools acquired outside standard purchasing channels |
|
Surveys, help-desk records, and business validation |
Business purpose, ownership, unlogged tools, policy confusion, and legitimate demand for new capabilities |
Incomplete reporting, inaccurate recollection, reluctance to disclose use, and activity unknown to the respondent |
Treat each signal as an indicator rather than proof. Confirm findings by correlating identity, device, application, permissions, data movement, business purpose, and account ownership before assigning an approval or risk status.
Once discovery starts working, the problem can shift from too little information to too many findings.
Do not give every item the same priority. Start with the data involved. Exposure of regulated information, customer records, credentials, proprietary source code, or other sensitive material deserves more attention than experimentation with public information.
Then examine permissions and access. An AI tool that can read a limited document set presents a different risk from an agent with persistent credentials and write access to production systems.
Other factors include regulatory and contractual exposure, vendor data-processing and retention terms, permission breadth, credential persistence, level of autonomy, downstream systems, business criticality, human review, approval status, and confidence in the available evidence.
Unknown agents handling sensitive data should sit near the top of the queue. Excessive OAuth scopes, persistent credentials, and write access to critical systems can push a finding higher.
The response should fit the risk. Security teams may:
An IT risk assessment can connect the technical evidence to likelihood and impact. It also gives leadership a clearer basis for deciding which control gaps and remediation priorities need attention first.
First, confirm the facts and preserve relevant evidence. Urgent exposure may justify revoking a grant or rotating a key. In other cases, the immediate step may be suspending an agent identity or restricting sensitive data movement.
Once the situation is stable, assess the vendor and account tier. Review data processing and retention, model-training terms, active integrations, and relevant incident history.
Decide whether to approve, conditionally approve, replace, or prohibit the use case. When possible, give employees a workable, approved alternative and a fast review path; blanket bans can drive useful activity further out of sight.
Use the investigation to improve policy and training. Clarify ownership, and repair the exception process if users lacked a practical route to approval. Approved tools and agents should return to the inventory with monitoring and review dates. Mature AI governance controls turn discovery into a repeatable remediation program that continues beyond the initial cleanup.
Set a monitoring cadence based on risk and change velocity. A new SaaS feature or agent should trigger reassessment. So should a material change in permissions, data sources, or the scope of an approved use case. Revisit the decision when vendor terms change, or an incident exposes a weakness.
Keep the measurement set small. Track unknown assets, ownership, approval status, time to validation, and remediation of high-risk identities or grants. Repeat use after redirection can show whether approved alternatives are working.
A lean team can start within 30 days:
These findings can feed a living cybersecurity roadmap and keep AI oversight connected to wider security priorities.
Shadow AI detection requires continuous correlation and validation across multiple data sources. A sanctioned baseline gives the evidence meaning. Business validation turns that evidence into a defensible risk decision, while ongoing monitoring keeps the inventory useful as technology changes.
Vistrada’s team-based vCISO model can pair executive ownership with specialists who assess the environment and shape the response. That support can extend from policy and controls through hands-on remediation.
Speak with Vistrada about evaluating shadow AI within your broader cybersecurity risk program and turning identified gaps into a prioritized governance and remediation roadmap.