The numbers being circulated this week originate with a Barndoor.ai survey released on March 18, not newly conducted research. Auto Service World republished the findings on August 21, but Barndoor’s original announcement says the research was conducted in January and February among 155 professionals at mid-sized and enterprise companies. That small, vendor-commissioned sample cannot establish that 91% of all enterprise workers use AI or that half of every corporate workforce has granted AI access to business systems.
It does, however, describe a problem that larger recent surveys from Okta, PagerDuty and Protiviti have independently found: employees are adopting AI faster than companies are defining approved tools, data-handling rules, access controls and accountability. For Windows administrators and Microsoft 365 teams, the practical issue is no longer whether employees can open a browser-based chatbot. It is whether an AI service can read a mailbox, query SharePoint, retrieve customer data, invoke an API, create a ticket, modify a record or trigger a workflow under a user’s authority.
That is a permissions problem before it is an AI problem.
Barndoor’s survey is a warning, not a census
Barndoor.ai says 91% of respondents used AI at work, 60% used it daily or more often, and 28% used agentic AI — tools able to complete multistep work rather than merely generate text. The company also says 50% of respondents had connected AI to a work-related application, while 48.4% had used a non-approved AI tool.
Those figures are striking, but the methodology matters. The survey covered 155 people and included a virtual focus group through Remesh, a research platform. Barndoor sells AI governance software and, in the same announcement, promoted Venn.ai, a product designed to give ChatGPT, Claude, Cursor and Visual Studio Code controlled access to business applications. The company’s commercial interest does not invalidate the responses, but it does mean IT leaders should not treat the percentages as a statistically durable measure of their own environment.
The survey’s specific examples are more useful than its headline number. Respondents described using AI to summarize support tickets, manage GitHub builds, prepare financial reports, automate invoicing and analyze sales pipelines. These are operational tasks with inputs and outputs inside systems of record. An AI tool that summarizes a ticket from copied text presents one kind of exposure; an agent that can search a support platform, draft a reply, update ticket fields and send follow-ups presents a different class of risk.
The difference is delegated authority. Once an AI tool is connected through OAuth, an API token, a browser extension, an automation connector or an MCP server, the security question becomes: what can that connection read, write, share or delete?
Shadow AI is becoming an identity and access management issue
Okta’s 2026 research reaches a similar conclusion from a larger survey: workers are routinely sharing company information with AI tools and granting access to internal systems, while executives substantially overestimate their visibility into that activity. PagerDuty’s survey of 1,250 office professionals at companies with at least $500 million in annual revenue also found widespread use of tools employees believed were not permitted. Protiviti, meanwhile, reports that roughly two-thirds of surveyed companies had seen employees use AI without proper oversight.
The exact percentages vary widely because the surveys ask different people, in different countries, using different definitions of “approved,” “AI,” “agent,” and “work use.” The consistent finding is more important than any one percentage: unauthorized use is not confined to a few technically adventurous employees.
For Microsoft shops, this complicates a familiar distinction. Microsoft 365 Copilot, Copilot Chat, GitHub Copilot, Azure AI services, Power Platform copilots and third-party assistants can all coexist in a single organization, while employees may separately use personal ChatGPT, Claude, Gemini, Perplexity or coding-assistant accounts. “We have Copilot” is therefore not an AI governance strategy. It does not establish which data classifications can be submitted to which model, whether personal accounts are allowed, which connectors can be authorized, or whether an employee can use an approved model through an unapproved integration.
A business can have strong Entra ID conditional access policies and still have weak AI oversight if users can authorize third-party applications with broad delegated permissions. It can have a written AI policy and still be blind to browser extensions, personal accounts, shadow automation flows and API credentials issued outside the central identity process.
The emerging risk is also not limited to data being pasted into a chat window. A tool with read access can expose information. A tool with write access can change it. An agent with permission to call multiple services can turn a simple request into a chain of actions across email, cloud storage, CRM, ticketing and finance systems.
Microsoft 365 administrators need to inventory connections, not just apps
The Barndoor findings make a useful operational point: users choose unapproved tools because they believe those tools work better or help them finish work faster. In the company’s survey, 42% of people who used non-approved tools said those tools produced better results, while 40% cited pressure to get work done quickly.
Blocking every external AI website may reduce one route for data loss, but it does not solve the demand for automation. Employees can shift to personal devices, consumer accounts, browser add-ons, embedded AI features in SaaS products, copied files or unsanctioned workflow services. Blanket bans can also drive the activity further out of view.
The first response should be an inventory tied to identity and permissions. IT teams should establish which AI services are in use, whether they are accessed through managed identities or personal accounts, and whether they have permission to reach company data. This should include OAuth enterprise applications, API keys, Microsoft 365 add-ins, browser extensions, Power Automate connectors, GitHub integrations and apps authorized through departmental SaaS platforms.
A practical review should answer four questions for every AI-enabled connection:
- The organization should identify whether the tool can access mail, files, Teams data, SharePoint sites, calendars, CRM records, source code, ticket queues or other regulated information.
- The organization should determine whether access is read-only, write-capable, or able to execute actions across more than one system.
- The organization should establish whether the access is granted by individual users, administrators, service accounts or application credentials.
- The organization should document who owns the business process and who can revoke the connection when an employee leaves, a vendor changes terms, or a security incident occurs.
This is routine access governance work, but AI makes poor visibility more consequential. A traditional SaaS app might be used occasionally by one team. An agent can act continuously, at speed, using a user’s permissions and reaching several services through connectors.
Policies fail when they do not name permitted paths
Barndoor says only 46% of its respondents worked for an organization with a defined AI policy, and nearly one in five did not know their company’s AI rules. Okta found a similar gap between leaders who thought policies were clear and workers who disagreed.
A usable policy cannot stop at “do not upload confidential information to public AI.” Employees need to know which services are approved, which account type they must use, what categories of data are prohibited, how to request a new integration and what must happen before an AI tool gains write access to a production system.
For example, an organization may allow Microsoft 365 Copilot under its existing tenant controls for internal documents, prohibit consumer AI accounts for customer and employee information, permit AI coding tools only through managed organization accounts, and require security review before any agent receives access to shared mailboxes, production repositories, finance systems or HR data. Those are enforceable instructions. “Use AI responsibly” is not.
The policy must also cover what happens when a vendor adds AI to an existing product. An approved CRM, project-management system or support platform can introduce an AI assistant that changes data flows or enables new connectors without a separate procurement event. Vendor-management and security teams need a process to assess those changes instead of assuming an old approval covers new model access and agent behavior.
The immediate risk is unmanaged delegation
The Barndoor survey should not be read as proof that half of all enterprises have lost control of their AI use. Its sample is too small and its sponsor is selling a product built around the problem it describes. But its core observation is supported by broader research: the boundary between an AI assistant and a business-system operator is disappearing faster than many organizations’ approval processes.
The immediate task for IT is to find where AI has already been delegated access, remove unnecessarily broad permissions, and give employees approved tools that are useful enough to compete with the services they are bringing in themselves. A policy written after the connections are already in place will not restore visibility; identity logs, app-consent records and connector inventories might.