Ready to bolster your defenses
Uncover how we can help put your resilience to the test.
This site uses cookies to enhance your browsing experience and analyze site usage. By continuing, you agree to our use of cookies. Read our Privacy Policy
There was a time when security teams worried about Shadow IT.
There was a time whensecurity teams worried about Shadow IT.
Employees wouldinstall Dropbox because the corporate file server was, well, annoying. Someonewould spin up an AWS instance because getting infrastructure approved wouldtake a lifetime—technically three weeks, but still.
Developers wouldinstall some open-source package they had picked out of a Secret Santa hat fromGitHub because, naturally, it worked on their machine.
Security teamseventually learned to accept it, document it, and occasionally cry about it.
Then came AI.
And apparently, wedecided that giving employees access to systems capable of writing code,analysing confidential documents, summarising emails, interpreting source code,generating potentially dangerous content, making decisions and, if the platformplays nicely, taking actions on their behalf was a perfectly reasonable thingto allow through a browser tab.
Welcome to ShadowAI.
What Is Shadow AI?
Shadow AI is the useof artificial intelligence tools, models, plugins, agents or services within anorganisation without appropriate security approval, governance or visibility.
It can includeeverything from an employee pasting a confidential document into a publicchatbot to a developer connecting an AI agent directly to internalrepositories, APIs or cloud infrastructure.
And the particularlyuncomfortable part?
You probably alreadyhave it.
The AI Nobody ToldSecurity About
The traditional ShadowIT problem was relatively easy to understand.
Someone used anunauthorised application.
Shadow AI isconsiderably more complicated.
An employee may use anapproved AI platform but connect it to an unapproved data source. A developermay install an AI coding assistant and give it access to an entire repository.Someone in HR may upload employee information into a consumer AI service. Asalesperson might paste customer information into a chatbot to generate aproposal.
Technically, everyonemay be using the same approved AI application.
But they are notnecessarily using it in the same way.
That distinction isbecoming increasingly important.
The conversationaround Shadow AI is shifting from simply identifying which AI applicationsare approved toward understanding what those applications can access andwhat they are allowed to do.
The application itselfmay not be the problem.
The permissions, data,integrations and actions surrounding it might be.
The Accidental DataBreach
Consider a completelyharmless, almost Teletubbies-level scenario.
An employee receives aspreadsheet containing:
They need to analyseit, so they upload the spreadsheet to an AI service and ask:
"Can you find theanomalies and summarise this for me?"
Poof.
They have theiranswer.
From the employee'sperspective, this is simply what getting things done looks like.
From the securityteam's perspective, however, the questions start arriving at approximately thespeed of a production incident:
The employee wasn'ttrying to be malicious.
They were trying to dotheir job.
And that's what makesShadow AI particularly unpleasant from a security perspective.
The attacker doesn'talways need to trick an employee into violating security policy.
Sometimes, they justneed to convince the employee that AI is helpful.
Shadow AI Is More ThanYour Friendly Little Chatbot
One of the biggestmistakes organisations can make is defining Shadow AI as:
"Employees usingChatGPT without permission."
That's far too narrow.
Shadow AI can includea surprisingly large ecosystem of technologies.
Generative AIPlatforms
Public orconsumer-facing chatbots being used for business purposes.
AI Coding Assistants
Tools capable ofreading repositories, generating code and potentially interacting withdevelopment environments.
Browser Extensions
AI-powered browserextensions can potentially observe webpages, documents, prompts and otherbrowser-accessible information.
AI Plugins andConnectors
Integrations thatallow AI systems to interact with SaaS platforms, databases, repositories andAPIs.
Autonomous AI Agents
Systems capable ofperforming multi-step tasks rather than simply generating text.
Locally InstalledModels
Open-source orprivately downloaded models running on corporate endpoints or infrastructure.
AI-Powered SaaSFeatures
Perhaps the mostdifficult category of all: AI functionality quietly appearing insideapplications the organisation has already approved.
Your organisation mayhave approved an application six months ago.
The application maynow have an AI assistant, an autonomous agent, connectors to external servicesand an entirely different data flow.
Congratulations.
Your approvedapplication just became part of the Shadow AI problem without anyone installinganything.
The New Attack Surface
This is where ShadowAI becomes particularly interesting for cybersecurity professionals.
Traditionalapplications generally have relatively well-defined boundaries.
A user entersinformation.
The applicationprocesses it.
The applicationreturns something.
AI systems introduce aconsiderably more complicated trust relationship.
An AI system may haveaccess to:
Suddenly, the questionisn't simply:
"Can this useraccess the application?"
It's:
"What can this AIaccess on the user's behalf?"
That is a verydifferent security problem.
The Employee May NotBe the Attacker
This distinctionmatters.
Imagine an employeegives an AI assistant access to a corporate knowledge base.
The assistant canretrieve documents the employee is authorised to access.
Now imagine anotherintegration has been improperly configured.
The AI can retrieveinformation belonging to another user, department or tenant.
The employee didn'thack anything.
The AI didn'tnecessarily "turn evil."
The organisationsimply created an enormous new trust boundary and failed to secure it properly.
OWASP identifies riskssuch as Sensitive Information Disclosure, Prompt Injection, Supply Chainvulnerabilities, Data and Model Poisoning, Excessive Agency, and weaknessesinvolving retrieval and embeddings within its work on LLM and generative AIsecurity.
That becomesparticularly concerning when an AI system is connected to real corporate data.
Because now a promptisn't necessarily just a question.
It can become arequest to retrieve information from an entire enterprise.
And Then There AreAgents
Chatbots are onething.
AI agents are another.
A chatbot might tellyou how to reset a password.
An agent mightactually reset it.
A chatbot mightgenerate SQL.
An agent might executeit.
A chatbot mightexplain how to deploy infrastructure.
An agent might havethe credentials required to deploy that infrastructure itself.
And suddenly we arriveat everyone's favourite AI security problem:
Prompt injection.
The difference is thatthe consequences can become much more significant when the model has tools,credentials and the ability to take action.
The AI doesn'tnecessarily need to be compromised in the traditional sense.
An attacker mayinstead influence what the AI sees, what it believes it should do, or whatinstructions it follows.
When an AI system hasaccess to enterprise data and external tools, that becomes a security problemrather than simply an interesting AI quirk.
The Compliance Problem
Shadow AI also createsan ugly governance problem.
Organisations may havepolicies governing:
But policies are onlyuseful if organisations know where their data is going.
If employees arequietly sending corporate information into dozens of AI services, theorganisation may have effectively created a distributed network of third-partydata processors without deliberately designing one.
NIST's Generative AIProfile recommends that organisations identify, assess and manage risksthroughout the AI lifecycle rather than treating AI governance as a one-timeapproval exercise.
That distinction isimportant.
AI governance cannotsimply mean maintaining a list of approved AI applications.
Organisations need tounderstand:
Because AIfunctionality is evolving considerably faster than most security approvalprocesses.
So ShouldOrganisations Just Ban AI?
Probably not.
And realistically,good luck.
Trying to completelyban AI inside a modern organisation is likely to produce the technologicalequivalent of putting a "DO NOT USE THE INTERNET" sign on theoffice door.
People will use itanyway.
They will just becomebetter at hiding it.
The better approach isto make secure AI use easier than insecure AI use.
That meansorganisations should consider the following.
1. Establish an AIInventory
Find out what AI toolsare actually being used.
Not what employees saythey're using.
What they're actuallyusing.
2. Classify AI byCapability
A chatbot thatsummarises public information is not equivalent to an autonomous agent withaccess to production infrastructure.
Treat themdifferently.
Risk should be basedon capability, access and potential impact—not simply whether something has"AI" in the product description.
3. Control the Data
Define whatinformation can be submitted to external AI services.
Sensitive data shouldnot become training material simply because someone had a particularlyproductive Tuesday afternoon.
4. Control Permissions
Apply least privilegeto AI systems just as you would to humans and applications.
An AI assistant doesnot need administrator privileges merely because someone thinks it is"smart."
5. Monitor AI Activity
Organisations shouldunderstand what AI systems are accessing, what data they are retrieving andwhat actions they are taking.
This includesmonitoring interactions, retrieval activity, memory access, tool calls andother events where appropriate.
Strong identitycontrols and least-privilege permissions should extend to AI systems and theirintegrations.
6. Secure theIntegrations
The AI model may beperfectly secure.
The connector someoneattached to it might not be.
APIs, plugins, MCPservers, vector databases, repositories and external tools all become part ofthe attack surface.
An organisationtherefore needs to assess the entire AI ecosystem rather than focusingexclusively on the underlying model.
7. Test AI SystemsLike Applications
AI systems needsecurity testing.
That includes testingfor:
These aren't simplytheoretical buzzwords anymore.
They are becoming partof the practical AI security testing landscape.
The Future of ShadowAI
Shadow IT happenedbecause employees wanted to work faster than security processes allowed.
Shadow AI is likely tofollow the same pattern—but with considerably higher stakes.
The difference is thata traditional unauthorised application might store your files.
An AI system canpotentially read them, summarise them, transform them, combine them withother information and act on the resulting information.
That changes theequation.
The biggest Shadow AIthreat may therefore not be an employee deliberately trying to circumventsecurity.
It may be an employeetrying to be productive.
They find an AI tool.
They connect it tosomething useful.
They give it access.
They start automatingtasks.
And somewhere between "Thiscould save me three hours" and "Look what I got the AI todo," the organisation accidentally creates a new privileged systemthat nobody has properly threat-modelled.
That, ladies andgentlemen, is Shadow AI.
And unlike Shadow IT,it isn't necessarily hiding in the corner anymore.
It may be sitting inthe middle of your identity system, your source code, your data lake, your SaaSapplications and your cloud environment—wearing an approved application's logoand very likely laughing.
The scary part isn'tthat employees are using AI.
The scary part is thatsecurity teams may not know what the AI has been given permission to do.
And that's a muchharder problem to patch.
Uncover how we can help put your resilience to the test.
