As AI capabilities become embedded across enterprise applications, security teams can no longer determine risk simply by knowing which applications are approved. The real question is how those applications are being used, by whom, with what data and with which connected AI capabilities.
At 9:03, an employee opens an approved AI assistant using a corporate account and asks it to summarise launch notes.
At 9:27, a feature the employee needs is unavailable in the enterprise version. They switch to a personal account and continue working.
At 10:11, the CRM introduces an AI sidebar following a routine SaaS update. It can summarise customer records, draft follow-ups and connect with the calendar.
At 11:06, a browser extension offers to move meeting notes between applications. One click later, another AI service has entered the workflow.
Nothing about the morning necessarily looks like a conventional security incident. There is no obviously malicious application, suspicious download or deliberate attempt to circumvent corporate controls.
Yet the security state of the employee’s workflow has changed several times.
The application name may have remained familiar, but the identity, feature, integration, data path and actions available to the AI have changed.
This is where the approved-app blind spot is emerging.
Approval is only a snapshot
Application approval remains an important enterprise security control. Security, legal, privacy, procurement and IT teams can assess a service, establish contractual terms, configure controls and define acceptable use.
But that assessment captures a particular version of reality.
It reflects the accounts, features, integrations, data-handling practices and business purposes understood at the time of approval. AI-enabled SaaS applications are changing rapidly. Productivity platforms are adding copilots and agents, browser extensions are acquiring connectors, and enterprise and personal versions of the same service can expose materially different capabilities.
As a result, an application can remain on the approved list while the way it is being used moves outside the assumptions under which it was originally assessed.
The traditional model is relatively simple: approved applications are trusted; unknown or prohibited applications are shadow IT.
AI makes that distinction considerably harder.
An approved application can create an ungoverned path when an employee switches identities, activates a newly introduced AI capability, connects an external service, feeds sensitive information into a workflow or gives an AI system the ability to take actions on their behalf.
The logo remains the same. The risk does not.
Shadow AI is increasingly about state changes
One way to understand the problem is to treat Shadow AI not simply as an application category but as a change in security state
Several transitions can move an otherwise approved interaction outside established governance.
Identity: An employee switches from a managed enterprise account to a personal or unmanaged credential.
Feature: An approved SaaS platform introduces a generative AI assistant, autonomous workflow or agentic capability that was not part of the original security assessment.
Integration: A browser extension, plug-in, connector, MCP server or external agent gains access to the workflow.
Data: An interaction that initially involved generic information begins to include customer records, source code, credentials, contracts or other sensitive material.
Purpose: A tool approved for drafting or summarisation is used to analyse regulated information or support a consequential business decision.
Action: An assistant moves from generating text to retrieving records, sending messages, modifying systems or triggering downstream processes.
Each transition changes the risk profile. Several can occur during a single browser session.
Identity is particularly important. An organisation may have negotiated enterprise protections, retention terms, administrative controls and auditability for an AI service. A personal login to the same service may sit outside those arrangements.
To the employee, the interface may look almost identical. From a security perspective, it can represent a very different environment.
The application logo is no longer enough
Asset inventory remains foundational. Security teams need to know which AI applications and agents are being used, who is using them and what systems they connect to.
But AI requires that inventory to become more contextual.
Knowing that an organisation uses a particular AI service does not reveal whether an employee is signed into the managed tenant, which AI feature is active, what information is being supplied, whether a connector can retrieve enterprise data or where the resulting information can travel.
Much of that information exists inside the interaction rather than at the application level.
This creates a significant challenge for organisations that have already started formalising AI adoption.
According to Check Point’s research cited in the supplied material, high-risk GenAI prompts increased from 2% to 4% over the previous year. The underlying behavioural shift is understandable: employees tend to provide AI systems with more context when they want more useful answers.
A request to summarise a customer issue can quickly become a prompt containing the customer’s history, internal correspondence, contract terms and proposed resolution.
The AI response may become better.
The data boundary becomes much harder to define.
Embedded AI creates another layer of complexity
The rise of embedded AI makes the approved-app blind spot even more difficult to manage.
Employees no longer need to visit a dedicated AI service to use generative AI. Capabilities are increasingly appearing inside productivity suites, CRM platforms, development environments, meeting applications, browsers and other enterprise software.
Microsoft’s 2026 Work Trend Index, referenced in the supplied material, describes the growing integration of AI and agents into everyday workflows.
For security teams, this means the parent application may be familiar and approved, while the newly introduced AI capability may bring a different model provider, retention mechanism, integration, permission structure or ability to act on enterprise data.
Consider a CRM platform
An employee may already have legitimate access to individual customer records. An embedded AI assistant could potentially summarise multiple records, combine that information with email history and feed the resulting context into another connected workflow.
The risk does not necessarily originate from an unapproved application.
It emerges from how approved systems combine data, intelligence and actions.
Inventory needs interaction context
This makes continuous classification increasingly important.
Rather than asking only “Is this application approved?”, security teams need to understand the context of the interaction.
Six questions provide a practical starting point:
- Who is using the AI capability?
- Which account, identity, device and tenant are involved?
- Which assistant, model, extension, integration or agent is active?
- What data is entering or being retrieved by the interaction?
- What business purpose is the employee pursuing?
- Where can the information or action go next?
This approach allows organisations to distinguish between very different scenarios.
An employee using a governed enterprise AI assistant to polish public-facing content is not equivalent to an employee using a personal account to analyse unreleased financial information.
Similarly, an AI assistant that generates a draft email presents a different risk from an agent that can access CRM records and send the email without further human intervention.
The policy therefore needs to follow the interaction, rather than simply the application.
Governance has to move beyond approved-tool lists
The challenge is not to prevent employees from using AI. In many organisations, that would be neither practical nor desirable.
Instead, controls need to become more dynamic.
Low-risk activity can continue with minimal friction. A personal login could trigger a prompt directing the employee towards the enterprise tenant. Sensitive information could be detected and redacted. An unapproved connector could be blocked. An agentic action involving a critical system could require additional approval.
This is where AI governance increasingly intersects with identity, data security, endpoint security and application security.
IBM’s Cost of a Data Breach Report 2025, referenced in the supplied material, highlights the governance gap: among organisations reporting an AI-related security incident, 97% lacked proper AI access controls, while 63% of organisations in the broader study lacked governance policies capable of managing AI or limiting the spread of shadow AI.
The implication is significant.
An AI policy and an approved-vendor list remain useful foundations, but they cannot provide complete visibility into rapidly changing AI workflows.
The interaction may become the new unit of governance
Consider the employee from the morning again.
The corporate AI account may be properly governed.
The personal account may not be.
The CRM’s new AI assistant may require a fresh assessment.
The browser extension may introduce another model and data path.
And an AI agent may eventually be able to act on the employee’s behalf.
The work itself has not necessarily become malicious. What has changed is the security state of the interaction.
That is the fundamental challenge with shadow AI in the enterprise.
It is no longer confined to unknown applications operating outside the corporate environment. It can emerge inside approved platforms, through legitimate identities, following routine software updates and ordinary employee behaviour.
For security teams, the question is therefore moving from “Is this application sanctioned?” to a much more granular set of questions: Who is using it? Under which identity? Which AI capability is active? What data is involved? What other systems are connected? And what can the AI do next?
As AI becomes embedded across the enterprise, sanctioned and shadow AI are increasingly temporary states rather than permanent application categories.
The organisations that recognise that shift will be better positioned to enable AI adoption without allowing familiar applications to become unfamiliar security paths.