--- title: "Shadow AI: How to Detect Unsanctioned AI Agents and Tools on Endpoints" description: "Shadow AI is an endpoint inventory problem. Learn which signals to collect, how to phase a 90-day programme, and why managed configuration beats chasing traces." author: "Mara Voss" category: "Defensive Architecture & Security Controls" date: 2026-11-04T16:20:01.134Z canonical: "https://agenticcyber.co/blog/shadow-ai-detection-finding-unsanctioned-agents" --- # Shadow AI: How to Detect Unsanctioned AI Agents and Tools on Endpoints ![trees sunrise, shadow, nature](https://cdn.pixabay.com/photo/2018/11/05/14/29/trees-sunrise-3796183_1280.jpg?w=1200&q=75) > Shadow AI is an endpoint inventory problem. Learn which signals to collect, how to phase a 90-day programme, and why managed configuration beats chasing traces. Start with the register of AI tools your company approved. Then ask the endpoint team what is installed on developer laptops. The two never agree, and the difference between them is shadow AI. New editor plug-ins, terminal agents, local model runners and MCP servers appear far faster than any review board can meet. Below you will find what to collect, how to phase the effort, how to respect staff privacy, and which control to favour when detection and prevention pull apart. Two vendors, Straiker and Knostic, have published detection advice. We cite both, mark them as vendor content and rank no product. ## The widening definition Pasting company text into a chatbot in a browser tab was only the first wave. A September 2026 Straiker post sketches the current spread: coding add-ons for an editor, standalone AI editors, agents launched from a terminal on Node.js or Python, desktop chat apps, models served locally through Ollama or LM Studio, containers running agents, and MCP servers connected to other tools ([Straiker](https://www.straiker.ai/blog/why-firewalls-and-edr-miss-shadow-ai)). Knostic's January 2026 definition is shorter still: AI use nobody approved or supervises ([Knostic](https://www.knostic.ai/blog/shadow-ai-detection-program)). Under both, agents sit inside the scope. Straiker's key argument is that the problem is shifting toward endpoint inventory, and away from matching traffic against a list of AI websites. ## Why familiar tools see only pieces A firewall may notice a connection to an AI provider, yet it cannot name the program behind it or tell whether a local model is in play. Endpoint detection watches processes and files, and an ordinary scripting runtime tells it nothing about an agent hidden within. Straiker's point is that a pile of separate signals is not an inventory of installed AI tools ([Straiker](https://www.straiker.ai/blog/why-firewalls-and-edr-miss-shadow-ai)). It is a vendor's reading, and it fits the practical difficulty: detection rules built for malware were never meant to answer which AI tools sit on a given laptop. ## What ignorance costs A law firm's digest of IBM's 2025 breach-cost study says incidents involving shadow AI made up 20 percent of breaches, seven points above sanctioned AI models, that 11 percent of organisations were unsure whether they had suffered a shadow AI incident, and that 63 percent lacked an AI governance policy ([Baker Donelson summary](https://www.bakerdonelson.com/ten-key-insights-from-ibms-cost-of-a-data-breach-report-2025)). These are second-hand figures from a 2025 study, so verify them in IBM's own report before use. Agents bring another worry beyond leaked data, because every unsanctioned agent carries credentials and can take actions. Identity is the subject of [the piece on agents nobody deployed](/ai-spm-and-shadow-agents-finding-the-agents-you-did-not-deploy). ## Eight signals and their blind spots Where to lookWhat you learnWhat stays unseen Installed app identifiersWhich AI desktop programs are presentPortable or renamed copies Signing certificatesThe publisher of each programAnything unsigned Editor extension listsAI helpers living inside IDEsRegistries you do not query Tool config foldersThat a tool exists, plus MCP settingsWhether use is recent or abandoned Running processes, open portsLocal servers and agents in actionRuntimes with generic names Container imagesAgents and model servers in DockerMachines you cannot inspect Network and DNS recordsCalls to AI servicesWhich application made the call OAuth grants in SaaSAI apps tied into company dataApps that bypass your identity provider Straiker recommends keying on app identifiers and signing identities because filenames change when programs are moved, and it suggests stating how confident each finding is, so that an install is not confused with active use ([Straiker](https://www.straiker.ai/blog/why-firewalls-and-edr-miss-shadow-ai)). ## Ninety days in three phases Knostic publishes a three-phase plan that we find a sound shape, and we adapt it for agents ([Knostic](https://www.knostic.ai/blog/shadow-ai-detection-program)). - **Days 1 to 30, see.** The aim is visibility, with no enforcement yet. Catalogue AI touchpoints across endpoints and SaaS, then rate each by the sensitivity of the data it touches. - **Days 31 to 60, decide.** Draft policy from the facts you gathered. Release an approved list and a short request route, which removes the incentive to work around you, and add detection for risky domains and sensitive uploads. - **Days 61 to 90, run.** Tune alerts, hold weekly triage, track time to detect and time to fix, and feed findings into your risk register. ## Prefer managed configuration to chasing traces Most shadow AI programmes put their effort into detection: scan, alert, chase. My recommendation is to make prevention the main control wherever a tool offers it, and to use detection to find what slips past. Several tools now let an administrator decide what is allowed. Anthropic's Claude Code documentation describes managed MCP configuration, along with allow and deny settings for MCP servers that an organisation can push to its sessions ([Claude Code MCP docs](https://code.claude.com/docs/en/mcp)). On the identity side, Microsoft's Entra guidance recommends allowing user consent only for apps from verified publishers, which turns many silent app grants into visible requests ([Microsoft Entra, user consent](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent)). The reasoning is about failure modes. A detector is wrong in both directions: it misses renamed installs and it flags harmless leftovers. A managed allowlist fails closed, so an unapproved server simply does not load. It also gives staff a clear signal, which supports the fast approval path. The preference weakens in three situations: tools with no administrative controls, personal devices you do not manage, and offline local models that leave few traces. There detection is all you have, and its limits should be stated plainly in the report to leadership. Whether to apply managed controls to a given tool is also a policy and legal decision, not a purely technical one. ## Respecting the people you monitor Leave prompts uncollected. Straiker's design notes suggest examining sensitive material on the device, counting conversations or tokens without copying prompt text, and, for credentials, reporting just the type, a rough length and a one-way fingerprint ([Straiker](https://www.straiker.ai/blog/why-firewalls-and-edr-miss-shadow-ai)). The approach shields employees and leaves you less to protect. Explain to staff what is gathered and why, and bring in legal and HR before launch. ## What to do with each finding - **Approve:** list the tool with an owner and a fixed version. - **Constrain:** let it stay, but strip lasting credentials and limit its outbound traffic. - **Replace:** hand people a sanctioned substitute first, then block. - **Block:** reserve this for tools with a record of abuse, for example unreviewed MCP servers. The [pre-install checklist](/mcp-security-a-checklist-before-you-install-a-third-party-server) scores a server before you allow it. Combine this with the posture view in [AI-SPM compared](/ai-security-posture-management-ai-spm-vs-cspm-dspm) and the policy wording in the [governance guide](/agentic-ai-governance-and-compliance-guide). ## Who does which job The security operations team runs discovery, triages each week and tunes the rules. Endpoint management ships collectors and policy and enforces blocks. A governance lead grades tools and grants exceptions. Team leads ask for approval of tools their people need. Legal and HR check the privacy notice. Agree an approval turnaround before you start: if low-risk requests take weeks, people will skip the process, and a fast path is the best control against hidden use. ## Open questions - Neither vendor publishes detection accuracy figures in the posts we read. - The IBM figures are second-hand. - Local model servers and offline agents leave few network traces, so some use will stay hidden. ## Shadow AI questions ## FAQ ### Can a CASB find shadow AI? It finds some SaaS use. It does not see local agents, extensions or MCP servers, which is why endpoint inventory matters. ### Should we ban unapproved tools? Start with discovery and an easy approval path. Bans without an alternative push use out of sight. ### How often should we scan? Continuously where you can collect from endpoints, and review findings at least monthly. ### Should we collect employee prompts? No. Analyse sensitive content locally and report only types and counts, and tell staff what you collect. --- Source: https://agenticcyber.co/blog/shadow-ai-detection-finding-unsanctioned-agents