By Kasper Ravn Breindal
Original article in Danish. English translation by M365 Copilot
Your CASB logs show traffic to AI services you’ve never authorized. An employee tests a browser plugin. A developer uses a new, smart code agent. A specialist uploads a customer document to a free chatbot.
It looks and feels like increased productivity, and it probably is, but maybe, in reality, it’s exposure of confidential data?
This article should actually have been about tangible tools to combat cyberattacks (e.g. log analysis in SIEM systems). But with the development of AI in recent months, I find myself spending more time on a very different beast. Namely, “Shadow AI” and how to handle it without killing innovation and initiative in the process.
Precisely because it is nothing new as such, we can fortunately also use a lot of the knowledge and experience we have from “old-fashioned” shadow IT. And here it is fundamentally true that you cannot control the risk if you cannot keep up with the use of the technologies.
The term “Shadow AI” covers employees using AI tools on their own outside the official channels, thus opening the back door for data leaks, compliance breaches or a cyber attack.
But is it something new? Seen through my IT security glasses, “Shadow AI” is a classic security problem in a new form. But it is developing alarmingly fast and governance simply can’t keep up with the needs and demands of the business.
Precisely because it is nothing new as such, we can fortunately also use a lot of the knowledge and experience we have from “old-fashioned” shadow IT. And here it is fundamentally true that you cannot control the risk if you cannot keep up with the use of the technologies. And if you only respond with blocks, usage just moves.
Therefore, I advise my clients to get three things in place, before anything else:
- Create technical visibility across networks, endpoints, SaaS, and identities
- Tie AI usage to data, roles, and business context
- Agree on a decision model for blocking, restricting, or controlled onboarding
Let’s take a look at what this can mean in practice.
Create technical visibility
Start with the controls you already have. Shadow AI rarely requires a completely new security program – it requires you to use your existing telemetrics better.
Typically, I and my colleagues at VENZO work in four tracks.
First, traffic. CASB, SSE, DNS, proxy, and firewall can detect calls to known AI domains and API endpoints. Many platforms already have categories for generative AI applications. Use them actively. Not only for blocking, but also for discovery.
Next, identity. IdP logs show who logs in where. OAuth consent shows which apps have been granted access. This is often where the silent problems appear: small SaaS tools, AI plugins, and private accounts used for work data.
The third track is endpoints. EDR and MDM can display installed clients, browser extensions, and on-premises models. That’s important because not all AI usage goes through clear web domains.
The fourth track is data. DLP and data classification must be linked to the AI traffic. Otherwise, you only know that someone is using a tool, but not what they are sending there.
Many organizations stop at application names, but this is not enough. ChatGPT, Claude or an unknown SaaS-AI is only half the story – the other we find by covering who, what and why – i.e. who uses the application, what data have they thrown into it, and for what purpose.
Tie AI usage to data, roles, and business context
Once you have found the use, it should not just end up in a spreadsheet but must of course be anchored into a governance model.
I recommend my clients a central AI catalogue that shows observed tools, data types, capabilities, user groups, risk level, and decision, for example, blocked, restricted, under assessment, or onboarded as an approved solution.
In addition, the risk assessment must be specific. Where is data stored? Is input used for training? Is there a data processing agreement? Which jurisdiction applies? Can logs be exported? Can access be controlled centrally? Can capacity be scoped down?
This is where governance, security and compliance meet. GDPR requires control of personal data. NIS2 increases the pressure on risk management and documentation. The EU AI Act further pushes the need for an overview. You need to be able to explain what is being used, by whom, for what, and with what controls.
Compliance is often involved too late and it creates unnecessary headaches if (or rather when) AI is used for something it should not be used for.
Agree on a decision-making model
Now comes the hard part, which is to act on what you have found.
In short; no one gains by letting it go, but you also don’t win by blocking everything. The right path lies somewhere in the middle, where you decide what to block, what can be accommodated with restrictions, and what should be securely integrated into the platform.
Think in three simple categories: block, restrict, or onboard.
- Block when the risk is clearly too high or the value too low. Example: a free AI service with no controls, where confidential data can easily leak – it belongs in the red category.
- Limit when a tool provides real use but is only justifiable with sharp frames. For example, developers can be allowed to use an AI code agent – but only on insensitive code, and never on customer data. This goes in the yellow category.
- Onboard when a shading tool has become indispensable and can be brought under full control. Then it makes sense to make it an official, controlled part of your setup – for example via an enterprise version or an internal implementation. Put this in the green category.
In practice, this requires a decision-making process that is both quick and consistent. Ideally, you have a small cross-functional team or AI Governance Board that continuously evaluates new AI findings and can quickly determine which categories the tools are.
Once you have defined what should be blocked, restricted or onboarded, remember to state it clearly. Employees need to know what they can use. In addition, they must of course also know what types of data they are never allowed to put into external AI tools, which tools are okay to experiment with – and which are totally no go. Remember to tell them what you do if you have already used something outside the shop!
Next step: 30 days discovery
Just as shadow IT is an old phenomenon, Shadow AI is not going to disappear either. On the contrary, it is becoming more and more difficult to handle as more and more tools, applications and wishes come from employees.
And as mentioned, you do not reduce the risk by only prohibiting. You reduce it by creating visibility, linking usage to data, and by being good (and fast) at making decisions about AI.
And what now, you ask?
Hopefully, the above does not come as lightning from a clear sky. So, a realistic next step could be to complete a 30-day discovery of your AI traffic, using the data sources you have available. Then build the first version of your AI catalogue, make sure you have an AI Governance Board of some kind – and take an active stance on what you want to block, limit, or bring out of the shadows and into the light.
