AI
While many companies are intentionally rolling out AI to boost quality and efficiency, unsanctioned AI tools are cropping up in corporate environments even faster. Software vendors are baking AI right into products companies already use (think Microsoft Copilot and Google Gemini), while employees are taking matters into their own hands and installing tools on the sly. As a result, businesses are staring down a poorly managed data leak channel: staff paste information from corporate systems into AI chatbots, sending data not just to the SaaS vendor, but straight to the developers behind the underlying AI model. Both the risks and the mitigation strategies vary depending on the type of AI system in play. We break down this broad topic, focusing heavily on tools for spotting and blocking AI at two distinct levels.
Types of unwanted AI systems
Depending on the type of AI in question, managing and blocking its use requires a different playbook. It’s essential to break down AI into four distinct categories:
- Platform-native AI capabilities. Think Microsoft Copilot, Google Gemini, and Apple Intelligence, along with AI features baked right into browsers. The tricky thing about these is that they’re built into everyday essentials, are instantly available to every user (sometimes popping up aggressively), and most importantly, vendors try to turn them on by default.
- AI companions embedded in business apps. This bucket includes Slack AI, Zoom AI Companion, Notion AI, Jira’s Rovo assistant, and the like. These are tied to a single application and are completely inseparable from it.
- Standalone web and app-based chatbots. ChatGPT, Claude, Perplexity, Character AI, local setups like LM Studio, browser extensions, and agentic browsers like Comet. Apps and services in this category are usually adopted by employees on their own without permission: classic examples of shadow AI.
- Desktop-native multi-functional agents. This group features tools like OpenClaw, NanoClaw, NemoClaw, and others. They pose the biggest threat because they come with broad access rights by default and actively process untrusted data from the open web.
How to deal with unwanted AI
Every company, depending on its industry, appetite for innovation, and risk tolerance, needs to draw its own line in the sand between recommended, approved case-by-case, and completely banned use cases for specific AI products. Regulated sectors like healthcare play by one set of rules, while retail businesses operate under an entirely different playbook. Either way, after analyzing exactly which AI tools have already slipped into the organization, corporate policies need to be fine-tuned. That’s why the first order of business is employing existing infosec and logging tools to scan corporate infrastructure.
Depending on the chosen strategy, the uncovered AI systems can be:
- Disabled or restricted by using the built-in corporate policy settings within the tools themselves
- Hard-blocked at the endpoint or network level to create a safety net against policy workarounds or configuration errors
- Transitioned to managed access, where the tool isn’t completely blocked but instead routed through a dedicated corporate gateway that checks access permissions, and monitors usage patterns
Detecting AI systems
Spotting AI requires a multi-layered approach, as different detection methods complement each other and work best against specific types of AI.
| Technology | What it can detect |
| DNS | Any AI tool with an identifiable domain |
| Web Gateway or NGFW | Any AI tool with a recognizable request-and-response fingerprint (API endpoint paths, domains, and other indicators). Web filters can inspect traffic content, and many gateways/NGFWs now feature a dedicated category for detecting and blocking generative AI |
| EPP/EDR | Locally deployed LLMs (running via Ollama, LM Studio, and similar shells), native desktop apps for ChatGPT or Claude, agentic browsers, and open-source AI agents. An indirect but strong red flag is the presence of Node.js, Python, Git, Docker, or other containerization tools on machines belonging to non-technical staff |
| Application control | Similar to EPP/EDR, this allows to immediately block unwanted applications right out of the gate |
| Browser control | AI-focused browser extensions and visits to AI-themed websites. This is a lifesaver if the corporate web gateway can’t inspect encrypted traffic |
| SaaS Security Posture Management (SSPM) / Identity Governance | OAuth permissions requested by AI apps and services, as well as any third-party integrations plugging into core productivity hubs (Microsoft 365, Google Workspace, and others) |
Naturally, almost all of these tools allow to do more than just spot AI — they let to block it entirely, or at the very least, sound the alarm for the team in charge.
Keeping an eye on OAuth
Popular office AI solutions — especially meeting assistants, email and calendar automation agents, and the like — gain access to corporate data by requesting OAuth permissions directly from communication, document workflow, or video conferencing platforms. If a user has the green light to grant these permissions to third-party apps, the resulting data leaks completely bypass the organization’s perimeter. Tools like EDR and NGFW won’t see a thing when a tool like Read.ai grabs recordings of every single meeting in, say, Microsoft Teams.
The most drastic — and often best — move is to block standard users from granting OAuth consent in the first place. Here’s how to handle the technical heavy lifting (Global Administrator, Application Administrator, or equivalent rights are needed):
Microsoft 365 / Entra ID
In the Microsoft Entra admin center, head over to <em>Identity > Applications > Enterprise apps > Consent and permissions > User consent settings</em>. There <em>User consent for applications</em> can be disabled (check out Microsoft’s full guide).
Google Workspace
In the Google Admin console, navigate to <em>Security > Access and data control > API controls</em>. Under <em>Manage App Access</em>, the trust level for all apps can be set: <em>Trusted</em>, <em>Limited</em>, <em>Specific Google data</em>, or <em>Blocked</em>. However, the real kicker here is the <em>Unconfigured app settings</em> subsection, which dictates what happens when a user tries to connect an unknown app. To seal this loophole, select <em>Don’t allow users to access any third-party apps</em>.
A separate subsection, <em>Manage Google Services</em>, permits fine-tuning exactly how third-party apps interact with Google Workspace and Google Cloud services. This allows to cut off access for each individual Google product (see Google’s official guide).
Salesforce
In <em>Setup</em>, use the <em>Quick Find</em> box to search for connected apps, then select <em>Manage Connected Apps</em> from the results. While settings are configured for each external app individually, all users can approve access by default. There isn’t a blanket block switch here; instead, Salesforce allows to opt for <em>Admin approved users are pre-authorized</em> (see the full Salesforce guide on this).
Slack
From the <em>Admin</em> settings menu, head to <em>Apps and workflows -> App Management Settings</em>. Tweak the <em>Require approved apps</em> setting by selecting <em>Only allow pre-approved apps</em>. Once that’s locked in, double-check that no rogue AI tools have slipped onto the approved list.
Tips