Data leakage and AI: how to reduce risk in the enterprise

November 4, 2026

Generative Artificial Intelligence has been adopted across businesses much faster than other corporate technologies were in the past. It has not required major implementation projects or months of integration. In many cases, all it has taken is opening a browser.

Today, it is common to use AI to summarise a document, review a contract, analyse code, prepare a presentation or search for information. The problem is that this is not always done using tools that the company has assessed and authorised. And sometimes it is not even obvious that AI is being used: it may be embedded in a SaaS application, a browser extension, a development tool or behind an API.

This range of uses that fall wholly or partly outside the company's control is what we call shadow AI. And it raises a particularly important question for Cybersecurity teams: what information are we sharing with these systems and what happens to it afterwards?

The company needs to know what information it shares with AI and what happens to it afterwards.

Data leakage can start with a prompt

There is no need to imagine a sophisticated attack. Potential data exposure can begin with something as routine as copying and pasting.

A developer enters a few lines of code into an assistant to find an error. Someone in Finance uploads a spreadsheet to generate a summary. A sales professional asks an AI system to improve a proposal before sending it to a customer.

These are perfectly understandable actions from the user's point of view. The problem arises when that content also contains credentials, personal data, customer information, proprietary code or internal documentation.

From a technical perspective, entering information into an AI system means transferring data so that it can be processed. This may happen directly through a prompt, by attaching a file or by granting access to a corporate repository. From a security perspective, what matters is understanding what data leaves the organisation, where it goes, under what conditions and with what safeguards.

■ In addition, data does not flow in only one direction. An assistant connected to internal documentation may also retrieve information that the user making the query should not be able to access if repository permissions are not properly enforced throughout retrieval and response generation. This becomes particularly important as AI connects to document management systems, code repositories, knowledge bases and other enterprise applications.

Security starts with knowing what data we share with AI.

Shadow AI extends beyond AI chatbots

One common mistake is to reduce shadow AI to the use of unauthorised public chatbots. The reality is much broader.

It may involve a personal account being used for a work-related task, but it may also be an AI feature built into an application that the company has already approved. It could be an extension capable of reading the contents of a web page or email, an internal application that accesses a model through an API, or an agent with permission to retrieve information and perform actions in other systems.

Public models, enterprise services and models deployed on the company's own infrastructure may also coexist.

This means that blocking a list of domains is only of limited effectiveness. Even an approved tool can present very different risk profiles depending on the account being used, its configuration, the connectors enabled, the data it receives or the provider's terms governing the retention and use of that information.

■ The question should therefore not simply be which AI applications are allowed. It is also necessary to consider what they can be used for and what data they can handle.

Approving a tool does not mean authorising every possible use.

Before applying controls, understand how AI is actually being used

It is difficult to protect what you cannot see. An AI security strategy should begin by building a sufficiently accurate picture of how AI is being used across the company.

This means more than simply creating an inventory of applications. It is important to understand which users and business areas use them, whether they access them through personal or corporate accounts, whether they upload files, how much information they share and which internal applications are accessing models through APIs.

The arrival of agents also raises new questions. Which repositories can they access? What permissions do they have? Can they only retrieve information, or can they also modify it? Can they send an email, create a file or initiate a process?

To build this picture, organisations can combine data from browsing activity, network traffic, endpoints, identities and Cloud applications. The aim is to understand actual usage before deciding where controls should be applied.

■ This analysis often reveals something else that matters: some AI tools may already be embedded in teams' day-to-day workflows, even though they have never undergone a formal assessment.

It is not enough to know which AI tools are being used: you also need to know who is using them and what information they are sharing.

Not all use cases carry the same level of risk

Translating into English a text already published on a corporate website does not present the same risk as uploading a customer database, analysing proprietary code or summarising confidential documentation.

That is why an effective AI policy needs to take into account both the characteristics of the tool and the context in which it is used.

There are technical questions that should be reviewed: where information is processed, how it is encrypted, how long it is retained, what identity and administrative controls the service provides, whether data may be used to improve or train models, and whether the company can disable specific features.

Based on those factors, a tool may be authorised for certain types of information, allowed only through enterprise accounts, restricted to specific users or blocked altogether when it does not provide the necessary safeguards.

■ The simpler this policy is for users, the better. When someone is about to paste a document into an assistant, they are not going to consult a twenty-page procedure. The rules need to translate into concrete decisions: which tool can I use, what data can I use with it and for what task?

Controls should reflect the AI tool, the data it receives and the task it performs.

AI controls need to be applied closer to the data

Once actual usage is understood, controls can be applied at different layers.

Web and Cloud application security solutions can help identify AI services and control how they are accessed. Depending on the technology used, it may be possible to distinguish between corporate and personal accounts or apply controls to specific actions, such as uploading a file or pasting information into an application.

Data protection adds another layer. DSPM helps discover where sensitive data is located, classify it and understand who can access it, while DLP can take action when that information is shared with AI services, ranging from a warning to blocking the action.

■ Applications developed by the company itself introduce another control point: the AI Gateway. Centralising model access through the gateway makes it possible to authenticate applications, control which providers and models may be used, manage quotas and costs, log requests and apply policies to prompts and responses. It also helps avoid a common problem in rapidly expanding environments: the proliferation of access keys across multiple applications and teams.

Protecting data also means controlling how it reaches AI.

With AI agents, controlling prompts is not enough

The shift towards agentic systems changes part of the security problem.

A traditional chatbot receives information and returns a response. An agent can go much further: query a database, access a repository, send an email, modify a record or initiate a process.

At this point, the issue is no longer only about protecting information, but also about controlling actions.

Least privilege, credential separation and traceability become essential. An agent should not automatically inherit all the privileges of the user or application running it. Retrieving information and acting on it should require separate permissions.

For certain operations, it will also be necessary to require human approval before an action is executed. Not because every decision made by an agent is necessarily dangerous, but because the impact of an error changes fundamentally when the system stops generating text and starts modifying real systems.

■ Something similar applies to RAG architectures. If an assistant queries corporate documentation, the permissions defined in the original repository should continue to be enforced throughout retrieval and response generation. Otherwise, we may build a technically sound system that ends up showing valid information to the wrong person.

Authorising an AI agent to retrieve information does not mean authorising it to modify or send it.

Log only what is needed without creating new risks

Traceability is necessary for investigating incidents and checking whether policies are working, but indiscriminately storing prompts and responses can create additional copies of sensitive information.

Wherever possible, logging should be limited to metadata (user, application, model, date, type of information and action taken), and the content should be appropriately protected when retaining it is unavoidable. Integrating these events with monitoring and response capabilities can also help detect anomalous behaviour or repeated attempts to circumvent controls.

Logging everything sent to AI systems and everything they return can create unnecessary copies of sensitive information.

From visibility to control

The aim is not to slow AI adoption, but to bring it into the enterprise without losing control of information. Blocking all AI tools does not necessarily eliminate shadow AI: it may drive users towards personal accounts, unmanaged devices or less visible services.

A more practical approach is to start by identifying which tools are being used and for what purpose, classify them by risk and provide approved corporate alternatives before applying graduated controls. Warnings may be sufficient in some cases, reserving blocking for clear risk scenarios such as sending credentials, regulated information or sensitive documentation to unauthorised services.

With the arrival of agents, the question is also no longer limited to what information AI can access, but what actions we allow it to perform.

■ Managing this balance will become an increasingly important part of Cybersecurity strategy: enabling the company to benefit from AI capabilities while keeping information, permissions and actions within known and controlled boundaries. More information →

To benefit from AI without losing control of information, organisations need to understand how it is being used and apply controls according to the risk of each use case.