Most security and compliance leads cannot answer the question that triggers every AI governance program: what AI tools is our organization actually using? Not the sanctioned ones procurement approved. Every tool, including the one a marketing analyst signed up for with their work email last Tuesday, the one engineering enabled inside Cursor, and the dozen embedded in SaaS products your sales team already pays for.
The honest answer at most orgs is "we don't know." That gap is where unauthorized PHI ends up in ChatGPT consumer, where contracts get redlined by an AI tool that signed no DPA, and where audit trails go missing when regulators ask for them.
Aguardic's Shadow AI Discovery engine exists to close that gap fast. One Word report from a five-minute form for the initial inventory, then a continuous process inside the Aguardic platform once you're ready to govern what you found.
This post walks through how the engine actually works: the three signals it combines, the catalog match it runs against them, and the bridge from "we now have an inventory" to "every AI request gets a policy decision and an audit record."
Three Signals Make Shadow AI Visible
Any honest discovery engine has to combine multiple signals because no single source catches everything. Aguardic Discovery uses three.
Signal 1: Self-Reported
The most underrated signal. Ask the team what AI tools they're using, in a Slack thread, a quick form, or as a section on a vendor inventory you already maintain. People will tell you. Not everything, but enough to seed the matcher with the obvious ones.
The free tool accepts a free-text list at submission. One per line, comma-separated, paste from a Notion doc, anything goes. A hospital ops lead might list ChatGPT, Notion AI, Otter, Grammarly. A startup CTO might list Cursor, Copilot, Claude, Linear AI.
Self-reported has one advantage no automated source has: the user knows what they are using the tool for. The catalog match tells you what BAA path exists for ChatGPT; the user knows whether they are pasting patient names into it. Discovery preserves the self-reported source on every matched tool so the report can flag the gap between "yes I use this" and "no BAA available."
What self-reported misses: shadow tools the user genuinely forgot about, embedded SaaS AI features they don't think of as "AI tools" (Notion AI, Linear AI, Slack AI), and anything someone signed up for with a personal email that bypasses sanctioned auth.
Signal 2: Network Logs
DNS resolutions and HTTP egress are the highest-fidelity automated source. Every AI tool that runs in a browser or talks to a public API leaves a trace.
The free tool accepts a CSV export from your DNS or zero-trust gateway: Cisco Umbrella, Cloudflare Zero Trust, NextDNS, or even Pi-hole. Aguardic's parser auto-detects the hostname column (header variations like host, hostname, domain, fqdn, query_name all work) and matches each unique hostname against a curated catalog of 100+ AI tool hostnames using suffix-ending logic.
That suffix logic matters. The catalog stores entries like openai.com, anthropic.com, notion.so. A network log will contain chat.openai.com, api.openai.com, cdn.openai.com, auth.notion.so. All of those should match. The matcher tries a longest-suffix match against catalog hostnames, so any subdomain of openai.com resolves to the OpenAI catalog entry without listing every subdomain manually.
What network logs miss: AI tools that ride on existing sanctioned connections (Notion AI traffic looks like normal Notion traffic, same hostnames), tools accessed only over BYOD or off-network, and AI features inside vendor APIs your stack already calls (for example, a Salesforce integration that quietly invokes Einstein).
Signal 3: OAuth Grants
When an employee clicks "Sign in with Google" or "Sign in with Microsoft" inside an AI tool, the IdP records the grant: application name, scopes requested, number of users. That registry is the highest-value shadow signal for a category of tools network logs miss. AI products that ride on Google/Microsoft OAuth instead of making outbound calls from the user's browser.
The free tool accepts a CSV export from your IdP admin console. Google Workspace ships an OAuth-grants report under Security → API controls → Manage Third-Party App Access. Microsoft 365 / Entra exports the enterprise-applications list. Okta has an applications export. Auth0 has a logs query for consent grants. The parser auto-detects common app-name column headers (app, application name, display name, oauth client, etc.).
OAuth grants catch the long tail of meeting-AI tools (Otter, Fireflies, Granola), document-AI plugins (Grammarly, ChatPDF), browser extensions that ask for Drive scope, and the productivity-AI layer most teams forget about (Glean, Mem, Dust). They also catch adoption. A tool with one grant is a curiosity. A tool with 200 grants is in production use whether IT approved it or not.
What OAuth grants miss: tools using their own auth (employee logged into ChatGPT with personal email), direct-API tools your code calls without OAuth (your engineers using OpenAI API keys), and anything that has not gone through your IdP at all.
The three signals catch overlapping but distinct categories. A real shadow AI inventory needs all three.
Catalog Matching: Hostname Suffix, Alias, Token Overlap
Once Discovery has the three input streams normalized into a flat list of candidates, it matches each candidate against the catalog using three strategies in priority order.
Hostname suffix match. For network log entries, the matcher walks each catalog entry's hostname list and checks whether the candidate ends with any registered hostname. chat.openai.com matches openai.com. app.notion.so matches notion.so. This handles subdomain proliferation without manual catalog upkeep.
Alias exact match. For OAuth grant entries (which are app names, not hostnames) and for self-reported entries, the matcher checks lowercased exact equality against the catalog's aliases array. The catalog entry for ChatGPT has aliases ['chatgpt', 'chat gpt', 'open ai chat'], so user input ChatGPT, chat gpt, or OpenAI Chat all resolve to the same entry.
Token overlap match. The fallback for fuzzy self-reported entries. When a user types "Open AI's chat product" or "the Otter thing for meetings," the matcher tokenizes both the input and each catalog alias, then resolves to the entry with the highest token overlap above a confidence threshold. Below threshold, the input is bucketed as unknownInputs and surfaced in the report so the user can manually triage.
Every match preserves the source signal. The report's per-tool card shows whether ChatGPT was discovered via self-reporting, network logs, OAuth grants, or all three. A tool found via network log but not in the user's self-reported list is the load-bearing "shadow" finding. That is the gap discovery exists to close.
From Inventory to Enforcement
A Word doc with 47 matched tools is a useful artifact. It is not, by itself, a governance program. Discovery as a free tool stops at the inventory. It tells you what is there and what each tool's BAA, framework exposure, and policy gap looks like.
The Aguardic platform extends each finding into continuous enforcement. The mechanism operates at the integration layer, not the discovery layer.
Once you connect Google Drive via OAuth in the Aguardic app, every file event (upload, share, download) flows through the policy engine. A document that contains chat.openai.com URLs in its content body, or that has been shared with a *@chatpdf.com email, or that triggers any rule in the active policy pack, gets evaluated in real time. The policy decision (ALLOW / WARN / BLOCK) writes to an audit log. The discovery list informs which patterns the policy pack matches against.
OpenAI integration works the same way at the API layer. Your code calls Aguardic's drop-in proxy instead of api.openai.com directly; every prompt is evaluated against the policy pack before the model runs (PII detection, framework-specific blocked patterns, custom rules from your own compliance docs uploaded as a knowledge base). The model output is evaluated again on the way back. A HIPAA org's policy might block prompts containing PHI patterns; a financial services org's policy might warn on prompts containing PII. Both produce the audit trail that turns "we use AI" into "here is exactly what we asked it and what it returned, every time."
Slack, Gmail, GitHub, Dropbox, OneDrive, and the rest of the sixteen supported integrations follow the same pattern. The discovery list (free tool) tells you which integrations to prioritize connecting first. The policy packs (recommended on each tool's discovery card) configure the enforcement rules that apply once the integration is live.
The split is deliberate. Discovery is a one-time scan that requires zero infrastructure setup. The platform is the continuous version with policy enforcement and audit evidence. The discovery report lists, per tool, "Recommended Aguardic policy pack," the explicit link from inventory finding to enforceable rule.
What Discovery Alone Cannot Do
A few honest limits worth naming.
It cannot see tools that do not appear in any signal. A developer running Ollama locally on a laptop, an analyst pasting data into a personal-account ChatGPT off the corporate network, an AI tool installed via a personal email on a managed device. These do not appear in IdP grants, will not show up in your DNS logs (or will look like generic Cloudflare traffic), and will not get self-reported. Discovery is exhaustive within its three signals. It is not omniscient.
It cannot distinguish "in production" from "tried once." A tool with one OAuth grant might be someone's experiment from six months ago. A tool with one network log hit might be a single page load. The free report surfaces grant counts and connection counts where present, but actual usage telemetry lives at the integration layer, which is the platform's job, not discovery's.
It cannot make policy decisions about whether a finding is acceptable. That is a human plus counsel call. Discovery flags BAA gaps, framework exposure, and recommended packs; the org decides what to enable, what to migrate off, and what to accept residual risk on.
Catalog coverage is finite. Aguardic's catalog covers 100+ of the most common AI tools across consumer LLMs, enterprise LLMs, productivity AI, dev tools, voice/meeting AI, and healthcare verticals. New tools appear weekly. Anything not in the catalog falls into the unknownInputs bucket, surfaced in the report so the user knows we saw it but could not classify it.
The Pattern
Inventory first. Three signals, self-reported, network logs, OAuth grants, combined against a catalog that knows the BAA path, framework exposure, and policy fit for each tool. Word report in five minutes, no signup. That is the free tool.
Then continuous enforcement. Connect the integrations the report flagged as highest-risk. Activate the recommended policy packs. Every AI request from that point forward gets a policy decision in under 200ms and writes an audit record. That is the platform.
The first half is what most teams get stuck on. They want to govern AI but cannot enumerate what they have. The second half is what makes the inventory useful instead of a static spreadsheet that goes stale the day someone signs up for a new tool.
Try the free tool at aguardic.com/shadow-ai-discovery. When the inventory raises questions worth answering with continuous evidence rather than a one-time scan, the platform is the same engine running 24/7 against live integrations instead of CSVs.
I'm building Aguardic, an AI governance platform that enforces policies at the runtime decision point — deterministic rules for speed, semantic AI for nuance, and custom knowledge for your organization's context. If you're dealing with AI compliance, check it out or drop a question in the comments.
Originally published at www.aguardic.com.
