Shadow IT is not a new problem. For years, organisations have dealt with employees signing up for cloud storage, messaging platforms and other applications without going through the usual IT approval process.
Now, the same problem is happening with artificial intelligence, except at a much faster pace.
An employee no longer needs to install software or request a new system. They can open an AI service in a browser, paste in an email, upload a document or connect it to another application and immediately start using it for work.
This is what we are increasingly calling Shadow AI.

The productivity benefits are obvious. But when AI adoption outpaces IT governance, organisations may find sensitive information and system access being given to tools they don’t even know are being used.
From Shadow IT to Shadow AI
Traditional Shadow IT was largely about applications.
Someone might sign up for an unapproved file-sharing service or project management platform because it helped them work faster. The security questions were relatively familiar: Where is the data stored? Who can access it? How long is it retained? What happens when the employee leaves?
Shadow AI brings many of the same questions, but introduces new ones.
Consider some very normal activities at work.
An employee receives a long document and uploads it to an AI assistant for summarisation. Someone pastes a customer email into AI to help draft a response. An engineer provides logs or configuration information to troubleshoot a problem. A developer gives an AI coding assistant access to a repository.
None of these actions necessarily have malicious intent. People are simply trying to get their work done faster.
But the information involved could include customer information, internal architecture, source code, commercial information or other sensitive data.
The employee may not even think of this as sharing company information with an external AI service. From their perspective, they are simply asking AI for help.
Whether that creates an actual exposure depends on the service, deployment model, contractual protections and how the provider handles the data.
The Risk Is Moving Beyond Chatbots

The bigger concern, in my view, is that AI is rapidly moving beyond simply answering questions.
AI agents can increasingly interact with email, calendars, document repositories, CRM systems, ticketing platforms, development tools and other enterprise applications.
Integration approaches such as APIs and the Model Context Protocol (MCP) are increasingly standardising how AI applications connect to external data sources and tools.
This creates tremendous opportunities for automation, but every connection also creates another trust relationship.
Imagine an AI agent with permission to read email, retrieve documents and access customer records. Each permission may seem reasonable individually. The risk changes when all those permissions are combined.
The next step is even more significant: giving the agent permission to act.
Instead of simply drafting an email, it could send one. Instead of recommending a change to a record, it could update it. Instead of generating a script for an engineer to review, an autonomous system could potentially execute an action itself.
There is another dimension to agent security. AI does not only receive instructions directly from employees. It may also process emails, documents, websites, tickets and other external content. Malicious or misleading content could potentially influence how an agent behaves or which tools it attempts to use. This is one reason permissions and approval controls remain important even when the AI platform itself is approved.
At that point, AI security is no longer only about what employees type into a chatbot.
It also becomes an identity, access and governance problem: which systems the agent can reach, which identity it acts under, what permissions it has and which actions it is allowed to perform.
These controls must sit alongside AI-specific protections against risks such as prompt injection, unsafe tool use and unintended agent behaviour.
Blocking AI Is Not the Answer
The obvious response might be to block unapproved AI services.
That may reduce some immediate risks, but I don’t think blocking AI alone is a sustainable strategy.
Employees are adopting these tools because they genuinely improve productivity. If the approved corporate alternative is too restrictive, difficult to access or simply not useful enough, some users may turn to unmanaged alternatives.
We have already seen this behaviour with Shadow IT.
The goal isn’t to stop AI use, but to enable it safely.
That requires organisations to understand that not every AI use case carries the same level of risk.
Using AI to improve the wording of a generic presentation is very different from uploading a customer database.
Asking AI to generate a PowerShell script for an engineer to review is different from allowing an autonomous agent to execute that script against a production environment.
The controls should reflect those differences.
Building Practical Guardrails for AI
Organisations do not necessarily need an entirely new security philosophy for AI. Many of the principles we already use still apply.
1. Provide approved AI tools
If employees have a useful and secure corporate AI option, there is less reason for them to turn to unapproved services.
2. Define what data can be shared
Employees need practical guidance on what information is acceptable to use with AI. Simply telling people not to share “sensitive data” is often too vague.
3. Apply least privilege to AI agents
An AI agent should receive only the data and system permissions required for its purpose. Access should not automatically expand simply because an integration is technically possible.
4. Keep humans involved in important actions
Higher-risk actions should have meaningful approval points. The more autonomy an AI agent has, the more important clear boundaries, audit trails and accountability become.
5. Build visibility
Organisations need to know which AI applications and agents are being used and what corporate resources they can access. If IT and security teams cannot see them, they cannot properly assess the risk.
The objective should be guardrails rather than roadblocks: enough control to protect the organisation without removing the productivity benefits that caused employees to adopt AI in the first place.
Best Practices
A few simple principles can help organisations approach Shadow AI more practically:
- Maintain an inventory of approved AI applications and agents.
- Define clear rules for what corporate information can be submitted to AI services.
- Review AI integrations and permissions using least-privilege principles.
- Require human approval for actions that could have significant business or security impact.
- Log and monitor important AI activity where possible.
- Educate employees about AI risks using realistic examples rather than relying only on policies.
- Regularly review AI access as tools, capabilities and business requirements change.
Most importantly, organisations should make the secure way of using AI the easiest way.
If security controls make legitimate AI use unnecessarily difficult, Shadow AI may simply move somewhere that IT cannot see.
Conclusion
AI is becoming the new Shadow IT because adoption is happening faster than traditional governance processes can keep up.
The answer is not to stop AI adoption. Organisations should provide employees with safe ways to experiment and improve productivity while maintaining appropriate control over corporate data and systems.
As AI moves from answering questions to taking actions, visibility, least privilege and human accountability will become increasingly important.
The organisations that manage this well will not necessarily be those that restrict AI the most. They will be the ones that find the right balance between innovation and control.
If your organisation is exploring how to adopt AI securely while protecting corporate data and systems, speak to Netrust to find out how we can help.
Follow us on LinkedIn for the latest happenings/updates.



