What AI visibility and control means.
AI can be used inside a company through approved platforms, features built into existing software, personal accounts, APIs and automated workflows. Visibility means knowing which AI systems and tools are being used, who uses them, what data they receive and which systems they can access. Access means understanding which information, accounts, applications and resources an AI system is able to reach. Control means defining what those systems are allowed to do, where their permissions end and which actions require additional approval. Responsibility means knowing who owns the system, who can change it and who is responsible when its use, permissions or behavior need to be reviewed.
Which AI systems and tools are being used?
What data, accounts and systems can they access?
What are they allowed to do?
Who is responsible for them?
These questions apply to very different forms of AI use. A company may have centrally managed AI systems, AI features inside existing software, employee-selected tools and automated or agentic workflows at the same time. The first step is therefore not to assume that every form of AI use is the same. It is to understand what actually exists.
How often do employees use AI tools their company did not provide?
AI use at work does not always begin with a formal company-wide rollout. Employees can start using generative AI through tools they already know, personal or non-corporate accounts, and services that are available without a central implementation project.
Research from different countries and datasets shows that this type of use is already common. The studies below measure different populations and behaviors, so the percentages should not be treated as directly comparable measures of one single phenomenon.
of AI users said they bring their own AI tools to work.
Microsoft and LinkedIn's 2024 Work Trend Index found that 78% of AI users were bringing their own AI tools to work. The figure was 80% among users at small and medium-sized companies.
The underlying survey question asked whether the generative AI tools people use at work were provided by their organization. It does not mean that 78% of all employees use unauthorized AI, and it does not by itself prove that the employer has no visibility into the tool.
of German companies reported or suspected private generative-AI use by employees.
In a representative Bitkom survey of 604 companies in Germany with at least 20 employees:
- 8% said private AI-tool use was widespread.
- 17% reported individual cases.
- 17% were not certain but assumed employees were using private AI solutions for work.
Together, those groups make up 42% of surveyed companies that reported or suspected private generative-AI use.
In the same survey: 23% had established rules for the use of generative AI. 26% provided employees with access to generative AI. Among companies with 20–99 employees, company-provided access was 23%.
These figures describe Germany, not the global market. They are useful as a regional example of a broader international issue.
of users accessing AI services on corporate devices used non-corporate accounts in Verizon's dataset.
The 2026 Verizon Data Breach Investigations Report states that 67% of users accessing AI platforms on corporate devices used non-corporate accounts.
The same report says that 45% of employees in its dataset were regular AI users on corporate devices, whether the AI use was authorized or not, up from 15% in the previous year.
Verizon also reports that Shadow AI had become the third most common non-malicious insider action detected in its data-loss-prevention dataset, representing a fourfold increase in share from the previous year.
This is important because it differs from a survey: Verizon is discussing activity observed in its security and DLP datasets. It is still not a universal census of all companies or employees.
What this means
AI use can exist before an organization has a complete inventory of the tools, accounts and data involved. A company can have several forms of AI use at the same time: centrally approved AI systems, AI features inside existing software, employee-selected or personally accessed AI services, APIs and developer tools, AI-enabled automations, and agentic systems connected to business applications. Knowing that these different forms of use can coexist is the starting point for visibility.
The Microsoft, Bitkom and Verizon figures above should not be placed on one chart as if they measure the same population. Microsoft measures self-reported BYOAI among AI users. Bitkom asks companies about private generative-AI use by employees. Verizon analyzes observed activity in security and DLP datasets. They support the same broad observation — AI can be used through channels outside centrally provided tools — but they reach that observation through different methods.
What does Shadow AI actually look like?
Shadow AI generally refers to AI applications, services or tools used for work without the organization's formal approval or oversight. It does not require a large technical deployment. It can begin with one employee using an unapproved AI service for an ordinary work task. It can also involve APIs, AI coding tools, model-provider services or more autonomous systems introduced outside the organization's normal approval process.
Microsoft currently describes Shadow AI as unsanctioned AI applications and tools used in an organization without IT approval. Its examples include generative-AI applications, model-provider frameworks and APIs, SaaS MCP servers and AI-related tools.
Microsoft technical reference
An employee uses a personal or non-corporate AI account for work without company approval or oversight.
The task itself may be ordinary: drafting an email, summarizing a document, preparing text, analyzing information, generating an image, or getting help with code. The defining issue is not that the task is unusual. It is that the AI use happens outside the organization's approved or managed environment.
A personal account is not automatically Shadow AI. If an organization has explicitly approved a specific form of personal-account use and understands how it is being used, the situation is different. The relevant question is whether the use is sanctioned and subject to the organization's oversight.
A team or employee starts using an AI application that has not been reviewed or approved.
This can include AI chat applications, coding assistants, document tools, browser-based AI services, AI-enabled SaaS products, or specialized applications for a particular department.
The application may be useful and may not be insecure. The visibility issue is that the organization may not yet have a reliable record of its use, data handling, ownership or access.
A developer or team can connect to an external model API, create an automated workflow or deploy an AI agent without it becoming part of the formal AI inventory.
Shadow AI is not limited to websites or chat interfaces. Programmatic AI use can be connected to business data and applications even when there is no obvious "AI app" visible to the rest of the organization.
Employees can paste or upload work information into AI services that the organization does not manage.
The information can include text, documents, images, source code or structured data.
Verizon's 2026 DBIR reports that, in its DLP data, source code was the most common data type submitted to external AI models, followed by images and other structured data. The executive summary also states that 3.2% of DLP policy violations involved research and technical documentation being uploaded to unauthorized AI systems.
That does not mean every use of an external AI tool results in a data breach. It shows that company information can move into AI services outside the organization's normal control environment.
View original reportNot every visibility gap is Shadow AI.
Shadow AI specifically concerns AI use outside an organization's approval or oversight. An approved AI system can still create visibility and control questions. For example: Which data does it access? Which user or system identity does it operate under? Which other applications is it connected to? What actions can it perform? Who can change its permissions? Who is responsible for it? These questions can exist even when the AI system is fully approved. Shadow AI is therefore one part of AI visibility and control, not the whole subject.
What can an AI system actually access?
An AI system does not automatically have access to everything inside a company. What it can see and do depends on how the system is designed, which data and tools it is connected to, which identity it uses and which permissions have been granted. One system may only be able to retrieve information. Another may be able to update records, send messages, invoke APIs or change the state of another application.
NIST's work on AI agent tool use explicitly distinguishes between read-only, constrained write and broader write capabilities when describing tool-access patterns.
NIST technical source
Data — What information can the system read?
Depending on its purpose, an AI system may be connected to documents, databases, knowledge bases, emails, customer records, support tickets, product information, source code, analytics data, or other company information.
The relevant question is not simply whether the AI has "data access." It is: Which information can it access, through which connection, under which identity, and for what purpose?
Systems and Tools — Which applications can it interact with?
AI systems and agents can be connected to other software through APIs, integrations, tools and connectors.
These are examples, not a list of systems that every AI deployment can or should access. The set of connected tools determines part of the system's practical capability.
Identity — Under whose authority does the system operate?
An AI agent or application needs a way to authenticate when it accesses protected resources. Depending on the architecture, it may act on behalf of a signed-in user using delegated permissions, act as an application without a signed-in user, or use a distinct workload or agent identity.
Microsoft's identity guidance for AI agents distinguishes these access patterns and recommends scoping permissions to what the workload actually needs. The distinction matters because the identity helps determine what resources the system can access and how its actions can be attributed.
A simplified access model
The system can retrieve information.
Example: Read a customer record or retrieve a document.The system can modify information.
Example: Update a CRM record or change the status of a support ticket.The system can cause something to happen in another system.
Example: Send a message, initiate a workflow, create an order or call another application.The difference between these levels matters because the potential consequence of an error or manipulated instruction changes when an AI system can alter external state rather than only return information.
Functionality, permissions and autonomy are different.
OWASP's 2025 guidance on Excessive Agency separates three important dimensions:
Which tools and functions are available to the AI system?
An integration may technically contain functions for reading, creating, changing or deleting information.
Which resources and actions is the system actually authorized to use?
A tool can support many functions while the identity used by the AI has permission for only a subset of them.
Which actions can the system perform without a person approving them first?
A system may be able to prepare an action but still require explicit human approval before that action is executed.
OWASP identifies excessive functionality, excessive permissions and excessive autonomy as root causes of Excessive Agency.
OWASP — LLM06:2025 Excessive AgencyExample: an AI email assistant
Consider an AI system designed to help with email.
- Data access
- It may be able to read incoming messages.
- Tool access
- It is connected to the company's email environment.
- Identity
- It may operate on behalf of a signed-in user or through a dedicated application or agent identity.
- Permissions
- It may have permission to read messages. Depending on its design, it may also have permission to send, move or delete them.
- Autonomy
- It may draft a response and wait for approval, or it may be permitted to send some responses automatically.
Two systems can therefore support the same broad use case while having very different control boundaries. OWASP uses a similar mailbox example to illustrate why a tool intended only to summarize emails should not automatically receive unnecessary send or delete functionality.
Where does a person need to approve an action?
Not every action has the same consequence. A system can be designed so that some steps happen automatically while higher-impact steps require review.
May run automatically.
May be presented for review.
May require explicit approval depending on the system, data and business impact.
This is not a universal rule for every AI system. It is an example of how approval boundaries can be designed. OWASP recommends human approval for high-impact actions where appropriate, and Microsoft guidance emphasizes scoped permissions, policy checks, approvals and auditability for agent access.
Microsoft — Access patterns and controlsWhat changes when AI can act, not just answer?
A text-only AI assistant may only produce an output: an answer, summary, recommendation or draft. An agentic system can go further. Depending on its design, it can use tools, access connected resources, choose between available actions and carry out multiple steps toward a task.
NIST describes AI agents as software systems that use data and algorithms to autonomously perform tasks and highlights the importance of identity and authorization when those agents access data, tools and applications.
Not every agent has the same level of autonomy.
The term AI agent is not used identically by every vendor, product or research framework. Some systems follow a tightly defined workflow. Others can choose among several tools and decide which step to perform next. Some require frequent human approval. Others are designed to operate in the background without a user present.
For that reason, the word "agent" alone does not tell you what the system can access, what it can change, which identity it uses, how much autonomy it has, or how much human approval is required. Those properties need to be examined separately.
A useful explanatory model
PERSON → AI → OUTPUT
The AI generates something for a person.
Examples: draft an email, summarize a document, answer a question.PERSON → AI → TOOL → RESULT
The AI can use a connected function or retrieve information from another system.
Examples: look up an order, search a knowledge base, retrieve a customer record.INPUT → STEP 1 → STEP 2 → STEP 3 → RESULT
The AI participates in a predefined sequence.
Example: Receive request → identify customer → retrieve order → prepare response → send for approval.GOAL → AI → SELECT TOOL → ACT → OBSERVE → NEXT STEP
The system can determine which available tool or step to use next based on the task, context and information it receives.
Its practical capability is still bounded by the tools, permissions, identities, policies and approval mechanisms built around it.Example: a refund request
The same business task can involve very different levels of system authority.
A customer asks for a refund. The AI reads the request and drafts a response. It does not change the order.
The AI can retrieve the customer's order and check its status. It can read information from another system.
The system can prepare or initiate a refund, update an order status or prepare a customer notification. It can change external state if its permissions allow it.
The system may be allowed to determine which steps are required, use several connected tools and complete part of the process without asking for approval after every step. Its authority still comes from the capabilities and permissions the surrounding system gives it.
An agent can become another actor inside a business system.
Once an AI system can use tools and perform actions, it becomes useful to think about it as an actor within the business process. That actor needs: an identity or execution context, defined access, permissions, limits, attribution of important actions, and, where appropriate, human approval.
NIST's 2026 concept paper focuses specifically on identification and authorization for software and AI agents because agents may access diverse data sets, tools and applications. Microsoft's current agent-identity guidance similarly treats agent access, permissions, lifecycle and auditing as distinct governance concerns.
Microsoft — Identity for AI agentsWhat has happened in practice?
Visibility and control questions are not limited to hypothetical scenarios. Real workplace incidents have involved sensitive information being entered into external AI services. Real agent deployments have also demonstrated why permissions and environment boundaries matter.
Employees entered sensitive company information into ChatGPT.
In 2023, reporting by Bloomberg and TechCrunch described Samsung employees entering sensitive internal information into ChatGPT, including code-related material.
Samsung subsequently temporarily restricted the use of generative-AI tools on company devices. A Samsung spokesperson told TechCrunch that the company was reviewing measures to create a secure environment for using generative AI and was restricting the tools on company devices while those measures were being prepared.
Questions raised by the case:
- Which AI services may be used for company work?
- Which types of information may be entered into them?
- Which accounts are being used?
- Does the organization know when sensitive information leaves its managed environment?
Important limitation: This case should not be described as proof that the submitted information was later exposed to competitors or publicly reproduced by ChatGPT. The documented point is that sensitive company information was entered into an external generative-AI service and Samsung reacted by restricting use while it reviewed safer approaches.
Source type: Journalistic reporting with Samsung spokesperson confirmation of the restriction.
An AI agent deleted data from an application database during development.
Replit publicly documented an incident involving SaaStr founder Jason Lemkin in which Replit Agent deleted data from the application's database. Replit explained that, at the time, the development and production application used the same underlying database. This meant changes performed during development could affect the production application.
Replit also stated that the database was ultimately fully restored using its rollback functionality, so the incident should not be described as permanent data loss.
What changed afterwards:
Replit introduced separate development and production databases. Under the newer architecture, changes made during development occur against the development database, and the Agent cannot modify the production database during development.
Two different control questions
The two cases above involve different mechanisms.
An employee sends company information to an external AI service.
Question: What AI usage is visible and approved inside the organization?
An AI agent has the technical ability to change a database.
Question: What is the system actually allowed to modify, and where are the environment boundaries?
AI visibility and control is therefore not one single issue. It involves people, tools, identities, data, permissions, architecture and the path from input to action.
What should a company be able to answer?
A company does not need every employee to understand every technical detail of every AI system. But for AI used for work or connected to company resources, some basic questions should have clear answers.
Which AI tools and systems are currently being used?
- Which teams or employees use them?
- The purpose is not to track every individual prompt. It is to understand where AI has become part of work.
- Are personal or non-corporate AI accounts being used for work?
- If yes, is that use approved, restricted or outside formal oversight?
- Which AI APIs, automations or agents exist?
- AI use can be embedded in technical workflows even when employees are not interacting with a visible AI application.
What company information can each system receive or retrieve?
- What company information can each system receive or retrieve?
- Documents? Customer information? Email? Source code? Internal knowledge? Financial information?
- Which applications, databases or internal systems can it connect to?
- An inventory of the AI system without its integrations is incomplete.
- Which identity or account does it use?
- Does it act on behalf of a user, as an application, or through a dedicated workload or agent identity?
- Are its permissions limited to what it actually needs?
- A system that only needs to read a resource does not necessarily need permission to modify or delete it.
What can the system read, create, change, send or delete?
- What can the system read, create, change, send or delete?
- The answer should be based on actual tool capabilities and permissions, not only on what the system was intended to do.
- Which actions can happen automatically?
- Some systems only recommend. Others can execute.
- Which actions require human approval?
- Approval points can be especially important where actions affect customers, money, sensitive data, production systems or irreversible changes.
- Who can change the system's permissions, tools or integrations?
- Control over the AI system includes control over the environment around it.
Who owns the system inside the company?
- Who owns the system inside the company?
- There should be a person or function responsible for decisions about the system.
- Who reviews meaningful changes?
- A new model, integration or permission can materially change what an AI system is capable of doing.
- Who is informed if something goes wrong?
- The answer may differ between technical incidents, data issues, policy violations and customer-facing failures.
- For systems that take actions, are important actions recorded and attributable?
- The level of logging should fit the system and its impact. A simple text assistant and an autonomous agent that changes business records do not require identical controls.
That does not automatically mean an AI system is unsafe or that an incident has occurred. It means that parts of the AI environment are not yet fully understood, documented or attributable. The purpose of visibility is to make those unknowns visible enough that the organization can decide what should happen next.
How to read the numbers on this page.
The research on this page does not measure AI use in one uniform way. Some sources survey employees. Some survey companies. Some analyze network, security or data-loss-prevention activity. Some study real incidents. Others deliberately attack AI agents in controlled research environments. The evidence is useful because these methods illuminate different parts of the same subject. The figures should not be mixed as if they were all measuring the same population and the same behavior.
Self-reported use is not the same as observed use.
Microsoft's Work Trend Index and Bitkom's study rely on survey responses. They tell us what workers or companies report. Verizon's DBIR includes observed security and DLP data. That can reveal activity that was detected technically. Neither type of evidence is automatically "better." They answer different questions and have different limitations.
"AI use" does not mean the same thing in every study.
One study may count the use of a public generative-AI chatbot. Another may measure AI integrated into a business process. Another may focus on agents. Another may analyze security events involving AI services. Adoption percentages from different studies should therefore not be compared as if they describe identical systems or behaviors.
BYOAI is not identical to Shadow AI.
Microsoft's BYOAI statistic is based on whether the AI tool used at work was provided by the organization. A tool that was not provided by the employer is not automatically proven to be unauthorized or invisible. Shadow AI is a narrower governance concept concerning AI use outside organizational approval or oversight. This distinction should remain explicit.
Shadow AI is not automatically a security incident.
The use of an unapproved AI tool creates a visibility and governance question. It does not automatically mean data was leaked, an attacker was involved, the AI service itself was insecure, or the company suffered a breach. The actual risk depends on what information was shared, what the service does with that information, what the system could access and how it was used.
Broad access does not automatically mean a system is unsafe.
Some AI systems legitimately need access to company data or other applications in order to perform their purpose. The relevant questions are: Is the access necessary? Is it appropriately limited? Is the identity understood? Are important actions attributable? Are higher-impact actions subject to suitable controls? Can permissions be changed and reviewed? The goal is not "no access." The goal is understood and intentional access.
Controlled research is not the same as a production incident.
Red-team studies deliberately try to make systems fail. They can demonstrate that a behavior is possible under attack and reveal weaknesses that deserve attention. They do not tell us how often that failure will occur during ordinary production use. For that reason, this page labels controlled research separately from real workplace or product incidents.
Regional data should be read as regional data.
Autorea operates internationally, and the subject of AI visibility and control is international. Some of the strongest available evidence on this page comes from Germany, including Bitkom's representative company survey. Those figures should be described as German data, not generalized to every country. They are used as a regional evidence point alongside global or cross-market sources such as Microsoft and Verizon.
Source policy
For important factual claims, this page prioritizes:
- Original research
- Official technical documentation
- Government or standards bodies
- First-party incident disclosures
- Reputable reporting where a primary public source is unavailable
Statistics should show the year, geography and study population where that information is available. Predictions should be labelled as predictions. Controlled research should be distinguished from real incidents. A source should never be used to support a stronger claim than it actually measured.
Sources used for data and cases
Microsoft & LinkedIn — 2024 Work Trend Index Annual Report
Global survey. N=31,000 knowledge workers across 31 markets. Survey period: 15 February–28 March 2024. Research firm: Edelman Data & Intelligence.
- 78% BYOAI among AI users
- 80% BYOAI at small and medium-sized companies
- Survey methodology and population
Bitkom — Beschäftigte nutzen vermehrt Schatten-KI
Representative company survey. Germany. N=604 companies with at least 20 employees. Method: Telephone survey. Fieldwork: Calendar weeks 27–32, 2025.
- 8% widespread / 17% individual cases / 17% suspected private generative-AI use
- Combined 42% reported or suspected private use
- 23% with rules for generative-AI use / 26% providing company access
- Size breakdown for company-provided access
Verizon — 2026 Data Breach Investigations Report
Security / incident / DLP dataset analysis. International security data.
- 67% of AI-service users using non-corporate accounts on corporate devices
- 45% regular AI use on corporate devices
- Shadow AI as third most common non-malicious insider action in DLP dataset
- Fourfold year-over-year increase
- Source code as most common data type submitted to external AI models
- Research and technical documentation in 3.2% of relevant DLP policy violations
Samsung / TechCrunch reporting
Reported workplace incident. Employees entered sensitive internal information into ChatGPT. Samsung temporarily restricted generative-AI tools. Editorial note: Treat this as reported incident coverage, not a first-party Samsung incident report.
TechCrunch reportingReplit — Database / Agent incident and control changes
First-party product disclosure. Agent deleted data from application database. Rollback restored the database. Development and production previously used same database. Replit introduced separate development and production databases afterwards.
UK AI Security Institute — Security challenges in AI agent deployment
Controlled red-team research. 22 agents, 44 deployment scenarios, 1.8 million attacks, 60,000+ successful policy violations. Demonstrates that AI agents can be induced to violate deployment policies under adversarial attack.
Technical sources and further reading
NIST — Tool Use in Agent Systems
Tool access, read-only vs. constrained-write vs. write capabilities, relationship between tool permissions and agent environments.
NIST sourceNIST — Identity and Authority of Software Agents
AI agents as software systems that autonomously perform tasks, access to data/tools/applications, identification and authorization as agent-control concerns.
OWASP — LLM06:2025 Excessive Agency
Excessive functionality, excessive permissions, excessive autonomy, limiting agent tools and permissions, human approval for higher-impact actions.
OWASP sourceMicrosoft — Shadow AI discovery
Unsanctioned AI applications and tools, examples of AI services outside IT approval, technical discovery of Shadow AI activity.
Microsoft sourceMicrosoft — Access patterns and controls for AI agents
Delegated access, app-only access, workload/agent identity patterns, scoped permissions, policy checks, approvals, auditability.
Microsoft sourceMicrosoft — Agent identities
Autonomous access, delegated access, agent-specific identities, access to web services and organizational resources.
Microsoft source