How to build shadow AI discovery

What matters here

• Use more than one source. Expenses find paid tools, SSO finds federated ones, and DNS finds the free ones nobody paid for.
• Correlate to a tool and a person. A list of domains is not something anybody can act on.
• Assess what data it can reach, not whether it is on a list. A tool with a Drive integration is a different risk from a standalone chatbot.
• Route to sanctioning, not to a block. Banning a useful tool moves it somewhere you cannot see.
• Report time from discovery to a decision. A backlog of undecided tools is the same as no programme.

Who this is for

You run security or IT operations. AI tools appear faster than anybody can review them, and the register is a spreadsheet somebody updates when they hear about something.

How it works in practice

What has to happen between somebody adopting a tool and it being known.

1. 1

   Several sources are read on a schedule

   Card transactions, SSO app assignments, DNS or proxy logs, and browser extension inventories where you have them.

2. 2

   Signals are correlated to a named tool

   Domains, merchant names and app names resolved into one entry per tool rather than three.

3. 3

   An owner is identified

   The person or team using it, because a tool with no owner never gets reviewed.

4. 4

   Data exposure is assessed

   What it can reach: files, mail, code, customer records, and whether it trains on input.

5. 5

   Discovery routes to a review, not a block

   With a sanctioned alternative offered where one exists.

6. 6

   The register updates itself

   So the answer to which AI tools do we use is a query instead of an email thread.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up and read several sources

   No single source finds everything, and the gaps differ.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Brex, Okta, Google
   Workspace, Jamf, Slack, Vanta and Snowflake, or whatever we run in
   those seats. Before you plan anything, tell me which of them are
   already authenticated in the workspace, because I do not want a
   connector stubbed that I have not authenticated.
   
   Then build discovery from every source we have:
   
     Card and expense transactions, matched against known AI vendors, which
     finds paid subscriptions
     SSO application assignments, which finds anything federated
     DNS or proxy logs against a domain list, which finds the free tools
     nobody paid for
     Browser extension inventory from device management, where we have it
     OAuth grants against Google Workspace and Microsoft 365, which is the
     most under-used source and finds tools that already have access to
     company data
   
   Each of these finds tools the others miss. Expenses miss free tools, SSO
   misses anything not federated, and DNS misses everything on a personal
   device.

   The OAuth grant source is the one worth doing first. It finds tools that already hold access to company documents, which is the risk everybody is actually worried about.

2. 2

   Correlate to a tool and a person

   A list of domains is data. A tool with an owner is actionable.

   Headless skills build-workflow

   Copy

   Use build-workflow. Correlate the signals into one entry per tool rather
   than one per signal.
   
   Resolve merchant names, domains and app names to a canonical tool through
   a mapping table I can extend, because vendor naming is inconsistent and
   the same tool appears three different ways.
   
   Attach the people: who paid, who is assigned in SSO, who granted OAuth,
   how many distinct users, and first and last seen.
   
   Identify an owner. A tool with usage and no owner never gets reviewed,
   because reviewing it is nobody's job. Where several people use it, pick
   the earliest adopter or their manager and say so instead of leaving it
   blank.

3. 3

   Assess what it can actually reach

   The risk is the data access, not the presence of the tool.

   Headless skills tray-patterns

   Copy

   For each discovered tool, assess exposure rather than novelty:
   
     What scopes were granted, if it arrived through OAuth. A tool with
     read access to Drive is a different problem from a standalone chatbot.
     Whether company data is likely being pasted into it, from usage volume
     and the team using it
     Whether the vendor trains on customer input by default
     Where the data is processed, for residency
     Whether we already have a sanctioned tool doing the same job
   
   Rank by exposure and by user count. A tool with three users and full mail
   access outranks one with two hundred users and no data access, and a
   ranking by user count alone gets that exactly backwards.

4. 4

   Route to a decision, never to a block

   A ban moves the tool somewhere you cannot see it.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then route every discovery to a review instead of an
   automatic block.
   
   Open a review with the tool, its owner, the exposure assessment and the
   user count. Offer three outcomes: sanction it, sanction with conditions
   such as revoked scopes or a data processing agreement, or decline with a
   named alternative.
   
   Tell the users what happened and why, and point them at the alternative.
   
   Blocking first is the mistake. A tool people find genuinely useful moves
   to personal accounts on personal devices, where none of these signals
   reach it, and the programme has made the problem invisible, not 
   smaller.
   
   Reserve immediate action for the narrow case: a tool with broad data
   access and a known incident.

5. 5

   Keep the register current and measure the backlog

   A backlog of undecided tools is the same as no programme.

   Copy

   Write every decision back to the register so which AI tools do we use is
   a query, not an email thread.
   
   Re-scan on a schedule, because tools change scopes and terms without
   telling anybody, and a tool sanctioned last year on different terms is
   not sanctioned now.
   
   Report: newly discovered this month, pending review and their age,
   sanctioned against declined, tools with high exposure and no decision,
   and users on declined tools who have not moved to the alternative.
   
   Time from discovery to decision is the number that matters. A growing
   backlog means the programme exists on paper, and people notice that
   faster than you would expect.

6. 6

   Prove it works, then hand the register to security

   Because the vendor list and the risk criteria change constantly.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production.
   
   Then open the same workflow in Tray Build so security operations can
   extend the vendor mapping, adjust the exposure criteria and change the
   review routing in the visual canvas. New AI tools appear weekly and the
   mapping is never finished.

What it connects to

Discovery reads from wherever a tool leaves a trace, and writes to wherever decisions live.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Further reading

Background on the same subject, for the case rather than the build.

• Defusing the MCP ticking time bomb
• Shadow MCP is the new shadow IT

Related guides