Shadow AI in company: how to reduce the risk

Your employees have already deployed AI — you just do not know it

Shadow AI in company environments does not begin with a large, secret project. More often, it starts with a simple sentence: “I will just upload this document to ChatGPT so that I can summarise it more quickly.”

Next comes a spreadsheet containing a model-generated macro, an automation with access to an email account, a small application built over a weekend, or an agent capable of retrieving data from several systems.

“I only uploaded the contract to an AI tool. I did not publish it anywhere.”
“I built an application with AI over the weekend. It works, so the team is already using it.”
“The agent has access to the mailbox and CRM, but only for testing at the moment.”
“I am not allowed to paste source code into an AI tool, but I can always photograph it and use a private service.”

From an employee’s perspective, this is rarely an act of rebellion against security controls. It is usually an attempt to complete a task faster, cope with a large volume of messages, or eliminate a manual activity that has impeded work for months. From the organisation’s perspective, however, a new data-processing activity, a new supplier dependency and, in some cases, a new production application have appeared. Nobody has simply called it a deployment.

AI may already be present in a company even when nobody has officially deployed it. It is sufficient for employees to begin using AI to work with data, make decisions or perform everyday tasks.

Your employees are probably not waiting for the organisation to finalise its AI strategy. They are already using models, creating automations and building applications through vibe coding.

The practical question is how to regain visibility, establish proportionate rules and avoid turning the cybersecurity team into an office that merely issues prohibitions.

What is Shadow AI in a company?

Shadow AI is the use of AI tools, models, applications and agents outside an organisation’s approved governance processes.

Such use takes place without formal approval, risk assessment, supplier due diligence, documentation, security controls or a clearly designated owner.

Shadow AI does not refer exclusively to the use of a private account with a popular chatbot. The phenomenon may involve several levels of activity:

entering corporate data into an AI tool;
creating repeatable prompts that influence a business process;
building automations and workflows;
developing applications through vibe coding;
using retrieval-augmented generation and corporate knowledge bases;
deploying agents with access to email, CRM platforms, files or other systems;
allowing AI to perform actions without human approval.

Each successive level increases access to data, organisational dependency on the solution and the system’s capacity to cause harm.

The tool itself does not determine the level of risk. What matters is the data, purpose, integrations, permissions, degree of autonomy and potential impact of an error.

For more information about a practical approach to artificial intelligence, you can read: AI for business – from idea to a working solution.

When does seemingly harmless Shadow AI become a serious problem?

A common mistake is to assume that no deployment has occurred unless an employee publishes something or launches an official production application.

If an employee regularly uses AI to analyse contracts, make decisions, prepare quotations or support customers, the tool has become part of a business process.

The company may have no contract with the supplier, no project in its portfolio and no corresponding configuration item in its CMDB. Even so, AI-generated output is already influencing real-world decisions.

The consequence does not have to be a conventional security incident detected by the SOC. It may instead result in:

signing an unfavourable contract;
disclosing trade secrets;
proposing an incorrect price;
performing an unauthorised operation;
infringing the rights of a customer or employee;
making a decision based on a manipulated source;
being unable to establish why a system behaved in a particular way.

Five scenarios demonstrating the consequences of Shadow AI

The following test scenarios are based on common architectures and security weaknesses found in applications that use large language models, RAG and AI agents.

1. A hidden instruction in a contract under review

An employee receives a contract and asks an AI assistant to summarise its risks.

The document contains white text that is invisible to a human reader against the white background. The hidden instruction tells the assistant to state that the legal department has approved the contractual terms.

The model follows the instruction embedded in the document and produces a plausible response. The employee then makes a decision based on a false recommendation.

This is an example of indirect prompt injection. The attacker does not need to compromise the system or install malware. It is sufficient to place an instruction in content that will subsequently be processed by the model.

I have discussed prompt injection and jailbreaking at several conferences. You can read more about these threats in the article: AI Jailbreaking and Injection: Threats & Mitigations.

2. A poisoned discount policy in a RAG Knowledge Base

An unapproved document resembling an official commercial policy is added to the corporate knowledge base.

The document is split into chunks, converted into embeddings and stored in a shared vector index. A RAG-enabled assistant begins to treat it as a trusted source.

Consequently, the system repeatedly recommends discounts above approved thresholds. Technically, the application is functioning as designed. The problem is that it relies on a manipulated source.

This may lead to lost margin, an incorrect quotation or a commercial precedent that is difficult to reverse.

You can learn more about working with RAG in the article: Add your data for RAG with Azure OpenAI Service.

3. RAG returns data beyond the user’s authorisation scope

A user signs in to an application successfully. The interface verifies their identity, but a shared vector index retrieves confidential document fragments before access controls are applied.

The content enters the model context. The model does not need to reproduce it verbatim. It may disclose the information in a summary, paraphrase or response to a follow-up question.

Successful authentication does not guarantee correct data authorisation. Access controls must be enforced before documents are retrieved, not merely when an answer is displayed.

4. An agent issues an unauthorised refund

A customer service agent receives an order number and calls a correctly functioning refund service.

The backend validates the format of the order number but does not verify that the order belongs to the authenticated customer. The agent uses the correct tool but performs the operation on the wrong object.

The company has therefore executed a technically valid but unauthorised financial transaction.

A system prompt instructing the model to “perform permitted actions only” is not a substitute for server-side authorisation. The model must never be the sole component deciding whether an operation is allowed.

5. An internet-enabled AI agent causes corporate data exfiltration

Data exfiltration is the unauthorised and often concealed copying or transfer of confidential information from an organisation’s IT environment to an external location controlled by an attacker.

An agent has access to both the internet and corporate documents. It visits a webpage containing a hidden instruction to find the names of internal projects and send them to an external address.

The data leaves the organisation as a URL parameter or tool-call argument.

Meanwhile, the final answer displayed in the chat window may appear entirely harmless. It may contain neither the project names nor any indication that information has been transmitted.

Monitoring the final response alone is insufficient. The organisation must log data sources, intermediate agent steps, tool calls, operation arguments and network destinations.

These scenarios correspond to risks such as prompt injection, sensitive information disclosure, data poisoning, excessive agency and vector-related weaknesses described in the OWASP Top 10 for LLM and Generative AI Applications.

Practical testing of similar vulnerabilities is also covered in ZALNET’s training on AI and LLM security and penetration testing.

How can an organisation address Shadow AI?

A ban will not solve the absence of governance or the Shadow AI problem

An organisation may block popular domains, restrict application installation and prohibit the use of private accounts. Such measures may reduce visible traffic, but they will not eliminate the underlying business need.

If official approval takes several weeks while a tool can solve a problem in an hour, some employees will take a shortcut.

An effective AI policy should not be merely a list of prohibited products. It should state clearly:

what data may be entered into AI tools;
which use cases are prohibited;
which tools have been approved;
when a use case must be reported;
who is authorised to make a decision;
which requirements must be met before deployment;
how errors and incidents must be reported;
when a solution must be reassessed.

The most important part of the policy is a secure, usable path from idea to deployment. Without it, the policy becomes a catalogue of restrictions whose observance the organisation cannot verify.

Prevent Shadow AI data leaks with Microsoft

How should an organisation introduce an AI Policy?

In practice, governance should be combined with technical visibility. In its guidance on preventing data leakage through Shadow AI, Microsoft describes the following process:

Discover the AI applications being used. The organisation should first determine which AI tools its employees actually use and how they interact with them.
Block access to unsanctioned applications. Tools that have not passed the organisation’s assessment may be blocked completely or made available only to selected users.
Protect data sent to sanctioned tools. The fact that an AI application has been approved does not mean that employees may send any information to it. Microsoft recommends preventing sensitive data from being transmitted.
Monitor and control AI usage. The organisation should be able to audit interactions, retain prompts and analyse potentially risky behaviour.

An AI policy is essential

Introducing an AI usage policy should be one of the core elements of artificial intelligence governance within an organisation.

Employees frequently begin using AI tools independently. Consequently, the absence of clear rules may lead to uncontrolled processing of corporate data, confidential information, customer data or fragments of source code.

An effective AI policy should clearly define:

which tools employees are permitted to use;
what data may be entered into those tools;
which use cases require prior approval or consultation;
who is responsible for approving new tools and AI use cases;
how incidents should be reported;
which security, privacy and regulatory requirements must be satisfied.

Importantly, the policy should not be treated as a document created once and then forgotten.

AI tools, models and related threats evolve rapidly. Rules governing their use should therefore be reviewed and updated regularly.

Employee training is equally important. Staff should understand not only what they are prohibited from doing, but above all how to use AI safely and responsibly.

A ready-to-use AI Policy Template

Organisations may use the template prepared by ZALNET: AI Usage Policy Template.

The document can serve as a starting point for developing internal rules tailored to the organisation’s characteristics, the types of data it processes and the AI solutions it uses.

The first step should not be a search for people to blame. If employees fear disciplinary consequences, they will continue to conceal the tools they use.

What can an organisation achieve within the first 90 days?

First month — days 0–30: establish visibility

conduct a no-blame survey;
identify tools and use cases;
review network traffic and active integrations;
identify business-critical processes;
inventory agents, automations and vibe-coded applications.

Second month — days 31–60: define the rules

prepare a concise AI usage policy;
define risk thresholds;
appoint decision owners;
create an inventory of AI systems and use cases;
establish a fast-track process for submitting ideas.

Third month — days 61–90: validate the controls in practice

select two or three controlled pilots;
perform security testing and AI red teaming;
verify monitoring and emergency shutdown capabilities;
test behaviour with incorrect, malformed and malicious inputs;
review decisions and approved exceptions.

The objective of the first 90 days is not perfect documentation. It is visibility and the ability to make informed, accountable decisions.

AI enables employees to build simple software solutions — Vibe Coding introduces a new category of risk

Vibe coding makes it possible to build a form, dashboard, integration, reporting tool or small business application in a short time.

The risk emerges when a prototype moves into production without:

a source-code repository and change history;
code review;
authorisation testing;
secrets management;
dependency controls;
monitoring;
a designated maintenance owner;
a rollback, recovery or decommissioning plan.

AI-generated code must meet the same requirements as code written manually. In addition, teams must verify the model’s assumptions, selected libraries and error-handling mechanisms.

The answer is not to stop experimentation. Organisations need a lightweight secure software development life cycle that supports rapid proof-of-concept development while defining explicit production-readiness criteria.

Lack of decision-making authority is also a risk

In many organisations, the difficulty is not a shortage of experts. It is the absence of a person empowered to say: “Yes, provided that these conditions are met.”

The business asks IT. IT refers the question to cybersecurity. Cybersecurity asks the legal team. Legal requests documentation for a solution that nobody has formally approved.

The project remains in a queue, but the business need does not disappear. In the meantime, an employee builds an unofficial solution.

Responsibilities should therefore be allocated explicitly:

the business owner is accountable for the objective, process outcome and impact of an error;
the data owner decides which uses of information are permissible;
IT or the product team is responsible for architecture and maintenance;
cybersecurity defines the required controls;
the legal team and Data Protection Officer assess regulatory and privacy obligations;
a person with the appropriate mandate decides whether to accept the residual risk.

Without a named decision owner, even the best policy will fail in practice.

The EU AI Act does not replace Risk Assessment

The EU AI Act follows a risk-based approach, but a system’s legal classification is not the same as an organisation’s internal risk assessment.

A system that is not classified as high-risk may still:

disclose customer data;
expose trade secrets;
generate an incorrect quotation;
cause financial loss;
perform an unauthorised operation;
damage the organisation’s reputation.

Risk should therefore be assessed from at least four perspectives:

Regulation — the organisation’s role, use-case classification, obligations and applicable dates.
Rights and privacy — affected individuals, personal data, discrimination, a DPIA and, where applicable, a fundamental rights impact assessment.
Cybersecurity — trust boundaries, access, vulnerabilities, misuse, monitoring and incident response.
Business — potential impact, reversibility of decisions, risk ownership and pilot conditions.

According to the current implementation schedule following amendments introduced through the AI Omnibus, most applicable provisions and enforcement mechanisms began to apply on 2 August 2026. Requirements for high-risk systems listed in Annex III are expected to apply from 2 December 2027, while requirements for systems integrated into products covered by Annex I are expected to apply from 2 August 2028. The current dates are published by the European Commission’s AI Act Service Desk.

Classification and implementation schedules should nevertheless be reviewed periodically because the regulatory environment and supporting guidance continue to evolve.

Case study: Risk Assessment for a Customer Service Agent

Assume that a company plans to deploy an agent that:

reads customer emails;
identifies customers in the CRM platform;
retrieves price lists and commercial terms;
prepares quotations;
generates documents;
hands messages over for sending.

The objective is to reduce response preparation time. The problem is that an untrusted external email passes through a model with access to internal resources.

The primary risk scenarios are:

ID	Scenario	Propobility	Impact	Risk score
R1	Prompt injection in an email manipulates the agent	4	5	20
R2	The agent retrieves data outside the customer’s authorised scope	3	5	15
R3	An incorrect price or contractual term reaches the recipient	4	4	16
R4	Data leaks to the model provider, logs or an integration	3	5	15
R5	No audit trail identifies who approved the response	4	3	12

In this configuration, the agent should not immediately be authorised to send messages autonomously.

A proportionate decision might instead approve a restricted pilot subject to defined conditions.

Essential safeguards include:

treating email content and attachments strictly as data, never as trusted instructions;
limiting CRM and pricing-system access to read-only operations;
filtering retrieved data to the specific customer record;
calculating prices and discounts in a deterministic business service rather than in the model;
requiring human approval of the recipient, price, content and attachments;
logging the model version, retrieved sources, tool calls and human approvals;
enforcing limits on the number of steps and execution cost;
providing an emergency stop mechanism;
reassessing risk after the pilot.

A similar approach to designing, testing and deploying solutions is used in ZALNET’s cybersecurity and AI implementation services.

The NIST AI Risk Management Framework and its Generative AI Profile can also help structure the assessment process.

AI Audit Checklist

I recommend conducting a structured risk assessment before deploying AI tools and agents within a company using this sample document.

An AI audit checklist can help identify the systems, data flows, integrations, permissions and business processes that may be affected by an AI tool or agent.

My attendance in a webinar about Shadow AI in a company

Shadow AI was one of the principal topics of the webinar “AI in the hands of (creative) users — how to reduce the risks of the new normal”, organised as part of Advanced Threat Summit 2026 conference.

On 10 September 2026, together with Zbigniew Dawydzik, CEO and Founder of ZibiSec Consulting, I discussed what happens when employees adopt generative AI faster than organisations can establish procedures, policies and security controls.

The session examined Shadow AI in company environments — the use of AI tools outside the organisation’s formal oversight. The problem is no longer limited to employees entering corporate data into ChatGPT or other chatbots. Staff increasingly use multiple external AI tools, browser extensions, agents, code generators and SaaS services that may remain entirely unknown to IT and security teams.

The webinar also addressed vibe coding and AI-generated applications created outside the conventional SDLC. If a user can generate an application within a few hours, connect it to corporate data and launch it outside the approved IT environment, an entirely new category of risk emerges.

The key question is no longer: “Are our employees using AI?”

It is rather:

“Do we know which tools they use, what data they share with those tools and what solutions they build with them?”

Shadow AI does not disappear simply because an organisational policy says that it is prohibited.

Organisations need discovery capabilities, risk classification, appropriate technical safeguards, employee education and clear rules for using AI.

The presentation slides are available from the my GitHub repository (polish version).

Shadow AI in company environments is a global challenge

The Microsoft and LinkedIn 2024 Work Trend Index Annual Report, published on 8 May 2024, demonstrated the scale of this phenomenon:

75% of the knowledge workers surveyed were using AI at work;
78% of AI users were bringing their own AI tools;
52% were reluctant to admit using AI for their most important tasks.

These figures are historical and do not describe every organisation in 2026 precisely. Nevertheless, they show that adoption has outpaced corporate strategies and decision-making processes.

These are not hypothetical stories from reports about the future. They increasingly reflect statements heard during training courses, consulting engagements and conversations with organisations.

Employees are not waiting for their employers to define a formal artificial intelligence strategy. They use publicly available models, create automations, connect corporate data to AI tools, build applications through vibe coding and deploy agents.

Employees use AI because they want to work more efficiently. They build applications, automate tasks and test agents because these technologies offer genuine business value.

2024 Work Trend Index Annual Report - AI at Work Is Here. Now Comes the Hard Part — 2024 Work Trend Index Annual Report – AI at Work Is Here. Now Comes the Hard Part

Summary

AI has already been deployed. The board, IT department, legal team and cybersecurity function may simply be unaware of it.

The cybersecurity function should not attempt to stop every experiment. Its role is to create a framework that distinguishes safe experimentation from use cases capable of exposing the company to serious harm.

First, establish how AI is actually being used. Next, identify and describe the risk. Finally, make a decision and preserve an auditable record of it.

ZALNET supports organisations with use-case analysis, risk assessment, policy development, security testing of AI agents and LLM-powered applications, and the secure implementation of AI solutions. An engagement can begin with a consultation, an audit or a focused Proof of Concept.

Explore ZALNET’s AI and cybersecurity training courses.