Skip to content

Find the AI-built apps you already have

Start with discovery, not policy. Executives overestimate how much shadow AI and shadow IT they can see, so don't rely on people reporting their own use. Look in identity and SSO logs, OAuth grants, expense and card data, DNS or proxy logs, endpoint reports and platform admin inventories, and run a no-blame amnesty alongside. Put each app you find into a first registry, with a provisional owner and tier, within 30 days.

Who this is for

IT managers and security leads starting a program for worker-built apps, or taking over one that never counted what exists. You get the discovery sources, the notice check to do first, amnesty terms, a triage rule and a 30-day list. About 9 minutes.

Each finding is also a desire path: a job people needed done that the approved route didn't serve. Discovery tells you what to pave next, as well as what to register (pave the desire paths).

Why does self-report undercount?

Because people under-report and leaders over-trust. In a vendor survey run in March 2026, 90% of executives were confident they could see how staff used AI, while 52% of knowledge workers said they had used AI tools that weren't authorized.1 A second vendor survey, from June 2026, put unpermitted use at 66% of office professionals at large companies in four countries.2 Both are vendor research, but they point the same way: a survey finds the apps people remember and are comfortable admitting to. It misses the scheduled automation nobody thinks of as an app, the agent on someone's personal token, and anything on a personal account.

The apps are real: a 2026 vendor scan found about 5,000 corporate-purpose apps on AI app builders' public hosting and reported that 40% exposed sensitive data, so expect some apps to be found from outside, on the builders' own domains.3

Don't: rely on a self-report survey alone

A census is useful: it finds the owner and the purpose, which no log shows. Run it alongside at least two technical sources, and compare the counts. The gap between what people report and what the logs show is your first program metric (A-005).

Where do you look?

Use the sources you already have before you buy anything. Most need only an admin export and an afternoon. Download the table as a checklist: discovery-checklist.csv. Prompt to Prototype, Find the AI-built apps you already have, https://prompt-to-prototype.com/roadmap/find-existing-apps/, as of October 2026. Licensed CC BY-SA 4.0.

Source What it reveals Effort Privacy caveat
Expense and card data New subscriptions to AI app builders, automation tools and model APIs, and who pays Low: one finance export, filtered by vendor category Shows individuals' purchases; share only the vendor and team with IT
Identity provider (SSO) app list and sign-in logs Which AI tools people sign in to with company accounts, and how often Low, if someone owns identity Sign-in logs are personal data about staff; aggregate before sharing
OAuth consent grants and API tokens Tools and agents that people connected to company mail, files, CRM or code, with the scopes they hold Medium: a report from the identity provider and each major SaaS admin console The grant names the person who consented; treat it as a lead, not an accusation
Service accounts and non-human identities Automations and agents running under a service identity, and who created them Medium Often no owner at all; that's the finding
DNS, proxy or secure web gateway logs Traffic to AI services and app-builder domains, including ones not behind SSO Medium: a domain list and a query The most intrusive source; this is where monitoring-notice rules bite hardest (see below)
Endpoint and browser management (device management inventory, browser admin console extension reports) Installed AI tools, desktop coding agents and AI browser extensions, by count per tool Medium: an inventory or extension report Device contents are the most notice-sensitive source. Collect tool names and counts, not file contents, browsing history or prompts
MCP and coding-agent configuration files on managed devices Which MCP servers and connectors people have wired to AI tools, and what systems they reach Medium: a scripted check through device management Read only the configuration's server list; never collect tokens found in it, and if one is there, rotate it (that's the exposed-credential follow-up)
Platform admin inventories Apps, owners, sharing settings and connectors on the low-code and AI app-builder platforms you license Low to medium; business plans only Personal and low-tier plans often have no admin view
Code hosting and cloud accounts at organization level Repositories, deployed projects and hosted sites Medium Repositories may hold personal data in test files
External exposure scan of your domains and storage, and of builder-hosted apps Apps reachable from the internet without sign-in, including apps on an AI app builder's own subdomains that use your company name, email domain or data (find them through the builder's admin or workspace view, and search where the vendor allows) Medium; a scanner or a provider Scan only what you own or are authorized to test. For builder-hosted apps, use the vendor's admin view or ask the vendor
Help-desk tickets Apps nobody in IT recognizes, found when they break Low None beyond normal ticket handling

Agents and automations count as worker-built apps. For each one, record the identity it runs under and every grant and token, because the app registry needs them to hand the app over or revoke it later (A-044). None of these sources can see an app on a builder's personal account, which is why the amnesty asks about personal accounts directly.

Hypothesis to test

Automated discovery tools and platform exports promise to populate the registry for you, with owners. We expect them to help, but nobody has published how accurate they are at naming owners or catching leavers (A-026, Low). Test this in your first month: pick 20 apps the tools found and check each owner with the team that uses it.

What must you check before you look?

Not legal advice

Not legal advice. This page summarizes laws as of October 2026 for a general audience. It was written with an AI legal-research persona and hasn't been reviewed by a lawyer for your situation. Ask your counsel.

Analyzing staff traffic, sign-ins or devices for AI use is employee monitoring, and some jurisdictions require written notice or a written policy before you do it. The rules are on the US and Canadian laws page: the state electronic-monitoring notice laws (New York, Connecticut and Delaware among them) and Ontario's written electronic-monitoring policy rule. A fleet-wide search of laptops for AI tool or MCP configurations counts. If the CCPA applies to you, it covers employee data, so check that your employee privacy notice covers this use.

For Canadian staff, which privacy law covers employee data depends on the province: PIPEDA applies to employees only at federally regulated employers, while Alberta, BC and Quebec have their own private-sector privacy acts that cover employees, and Ontario adds its written monitoring-policy rule. Which Canadian laws apply sets them out. Quebec's private-sector act also requires telling people, before collection, about technology that can identify, locate or profile them (s. 8.1), which can reach SSO, proxy and endpoint analysis.7

In practice: ask counsel and HR which notices you already give, whether proxy, DNS and endpoint analysis falls inside them, and whether you need to update them before the scan. The notice should name the purposes on this page: finding apps and owners, deciding what to pave and support, and removing exposed data or credentials. Start with the low-intrusion sources (expense data, the SSO app list, platform inventories) while that's answered. Keep raw discovery exports only until triage is done; keep the registry record, not the logs.

Maps to: NIST CSF 2.0 ID.AM-02 (inventory of software and services) and NIST AI RMF GOVERN 1.6 (AI inventory) for discovery; SOC 2 privacy criterion P1.1 and CC2.3 (notice and communication) for the monitoring notice. Mapping reuses controls you already have; it isn't certification.

Don't: monitor staff beyond what local law and your notices allow

Discovery data identifies people. Use it to find apps and owners, to decide which desire paths to pave and support, and to remove exposed data or credentials. Don't use it to rank or discipline individuals, and keep it to the people running the program. The enforcement ladder follows the same rule. Any other use is a new purpose for counsel and HR to approve first.

Depends on your circumstances (C3)

If data crosses borders, or you monitor staff in the EU or the UK, stricter rules can apply, including assessments before monitoring and, in some EU countries, consultation with employee representatives. Route the discovery plan to counsel before you scan those staff. See when EU or UK law reaches you.

How do you run an amnesty?

An amnesty is a fixed window, usually 30 to 60 days, in which anyone can declare an app, automation, agent or AI tool they use, and register or migrate it without discipline. It works only if the terms are written, published and kept.

Terms to publish:

  1. Scope: apps, automations, agents, AI tools and browser extensions used for company work, on company or personal accounts.
  2. What's promised: no discipline for disclosing past unsanctioned use. There's no amnesty for intentional data exfiltration, for harassment, or for carrying on after being told to stop, and the amnesty doesn't stop you fixing an exposure. Counsel reviews the wording before you announce it.
  3. What happens next: each declared app gets triaged (below). An app with a problem gets help to fix or migrate it, not a shutdown without warning.
  4. The end date, and what changes after it: the policy on unsanctioned AI use applies, with its enforcement steps.

Illustrative composite: amnesty message

Subject: Tell us what you've built with AI (no blame, until 30 November)

Many of you have built apps, automations or agents with AI tools to get work done. We want to support them, not shut them down. Until 30 November, register anything you've built or rely on, including anything on a personal account, using this 10-minute form. Nobody will be disciplined for telling us about past use, except for intentional data exfiltration, harassment, or carrying on after being told to stop (wording to be reviewed by counsel). We'll help you move it to an approved tool if it needs one, and name a backup so it keeps working if you're away. After 30 November, unregistered apps fall under the AI use policy.

Don't: punish amnesty disclosures

One disciplinary case for something disclosed in good faith ends every future amnesty, because people learn that telling IT is the risky choice. A quiet crackdown on a tool the business tolerated for months does the same. If a disclosure reveals an exposure, contain it as an incident and fix it with the builder.

How do you triage what you find?

Put every finding into one of three buckets, then tier the ones you keep with the risk tier workshop for existing apps, which handles a batch in 90 minutes. A first scan can find 50 or more apps: triage the Fix bucket first, and schedule workshops at 12 to 15 apps each.

Bucket When What you do
Register It's in use, someone will own it, and it breaks no floor Create the record with a provisional owner and tier; confirm both within 30 days
Fix It's in use but breaks a floor (for example, a public link to internal data) or a never-do (for example, a key in the front end) Contain first, then register it under the floor-breach rule with a fix-by date
Retire Nobody uses it, nobody will own it, or it duplicates an approved app Agree a date with the users, export what they need, revoke its grants

A workshop tier from a two-line description is provisional; the owner confirms it by answering the six tier questions.

Whatever the bucket, record what job each found tool or app does, with its data class. Group the findings by job: the most common jobs go to the paved-road backlog, because they're the desire paths most worth paving (pave the desire paths).

What goes in registry v0?

A shared table with the core fields from the app registry template is enough to start: name, purpose, provisional owner, platform, data, users, provisional tier, how you found it and the triage bucket. Keep the discovery source column, because the registry's health checks later compare registered apps with discovered ones. Publish an interim acceptable use policy at the same time, so people know the rules for what they build next.

Don't: ban and hope (AP12)

An interim policy that forbids AI tools, with nothing approved, hides use instead of stopping it, and your next discovery run finds less while the risk stays. Approve one default tool for each common job you found. Sources are on failure patterns.

What's the first-30-days list?

The canonical day-by-day sequence lives in if nobody owns this today; don't run a second copy. The discovery-specific tasks are:

  • Ask counsel and HR the notice question above.
  • Pull the expense, SSO and platform-inventory exports.
  • Announce the amnesty with written terms and an end date.
  • Pull OAuth grants and service accounts; flag any with no owner.
  • Run the external exposure scan of your own domains, and check builder-hosted apps through each builder's admin view.
  • Pull the endpoint and browser-extension reports, once the notice question is answered.
  • Triage each finding into register, fix or retire, Fix first, and record its job for the paved-road backlog.
  • Hold the first risk tier workshop on the registered apps.
  • Report the gap between self-reported and discovered counts.
  • Choose the builders you found for the next phase: run a 90-day pilot of the paved road.

Depends on your circumstances (C5)

If nobody owns identity or access today, your sources are expense data, the census and platform inventories. Don't plan around SSO logs or grant reports until someone owns identity.

Depends on your circumstances (C7)

If several business units already build independently, run one amnesty with one form and one registry schema, and let each unit triage its own findings.

Depends on your circumstances (C1, C2)

If you process regulated data, involve your privacy or compliance lead in triage, because a discovered app holding it is an incident question first; if you're a public body, record fields with publication in mind (US federal agencies publish an AI use-case inventory under OMB M-25-214).

Record the decision

Record the amnesty terms once, using the decision record template.

Illustrative composite

Title: Run a 45-day amnesty for worker-built apps and AI tools · Status: accepted · Date: YYYY-MM-DD · Owner: enablement lead (a role) · Approved by: HR lead and counsel

Context. Discovery data shows AI tools and app builders in use that nobody registered. We don't know who owns most of them.

Decision. A 45-day amnesty: no discipline for disclosing past use, excluding intentional data exfiltration, harassment and carrying on after notice (wording reviewed by counsel). Every declared app is triaged into register, fix or retire. Discovery data is used only to find apps and owners, choose which desire paths to pave, and remove exposed data or credentials.

Alternatives considered. No amnesty, enforce the policy now (rejected: it drives use further out of view, AP12). An open-ended amnesty (rejected: no point at which the policy starts to apply).

Consequences. We publish the declared and discovered counts at the end, and the enforcement steps in the policy on unsanctioned AI use apply from the day after.

Review by: at the end of the window.

Questions to ask your counsel

  1. Do we have to notify staff before we analyze SSO, proxy, DNS or expense data for AI use, in each state and province where we have staff, and do our existing notices cover it?
  2. Does our amnesty create any disclosure obligation, for example if a declared app turns out to have exposed personal data?
  3. Can we promise no discipline for amnesty disclosures, and what limits should the promise state?
  4. Does analyzing network traffic or device contents raise any issue under the Electronic Communications Privacy Act: do the consent or business-use exceptions cover our setup, and does our notice establish consent?
  5. For Canadian staff, which provincial or federal privacy act covers our employee data, and does our notice meet Quebec's rule on technology that can identify, locate or profile people?

Assumptions and evidence

  • A-005 (Medium): we expect self-reported inventories to undercount, because executives overestimate their visibility; test this by comparing registry counts with discovery counts after the amnesty.
  • A-006 (Low): we expect non-developers to have built apps on AI app builders outside IT; test this by counting app-builder deployments by non-IT staff in your discovery data.
  • A-026 (Low: vendor guidance only): we expect automated discovery to name owners well enough to help; test this by checking 20 discovered owners against the teams that use the apps.
  • A-044 (Low): we expect agent identities and grants to be inventoriable cheaply; test this by counting grants and service accounts with no registry entry or owner.

Evidence: vendor surveys and a vendor scan for the scale of unsanctioned use, vendor guidance for automated hygiene checks5, and practitioner assessment that AI-accelerated shadow IT needs governance-first sandboxes rather than blocking6; no independent study of discovery accuracy. Facts on this page are as of October 2026.

  1. The Register, report on an Okta survey of 784 respondents (fieldwork March 2026): 90% of executives confident in their visibility, 52% of knowledge workers using unauthorized AI tools, 27 May 2026. https://www.theregister.com/ai-ml/2026/05/27/bosses-blinded-by-confidence-about-shadow-ai-use-by-workers/5247275 [vendor], accessed 2026-10-21. ↩

  2. PagerDuty, press release on a Wakefield Research survey of 1,250 office professionals at companies with $500M or more in revenue in Australia, Japan, the UK and the US: 66% used AI tools they believed weren't permitted, 11 Jun 2026. https://s206.q4cdn.com/635206389/files/doc_news/PagerDuty-Report-Finds-Two-Thirds-66-of-Office-Professionals-Have-Used-Unauthorized-AI-Tools-at-Work-2026.pdf [vendor], accessed 2026-10-21. ↩

  3. Red Access, report on apps built with AI app builders: about 5,000 corporate-purpose apps among 380,000 assets, 40% exposing sensitive data, 2026. https://info.redaccess.io/shadow-ai-builders-security-report [vendor], accessed 2026-10-21. ↩

  4. US Office of Management and Budget, Memorandum M-25-21, "Accelerating Federal Use of AI through Innovation, Governance, and Public Trust" (AI use-case inventory), 3 Apr 2025. https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf [primary], accessed 2026-10-21. ↩

  5. Microsoft Learn, Power Platform tenant hygiene guidance (owner-left detection, inactivity notices, quarantine; the starter kit it describes is no longer maintained). https://learn.microsoft.com/en-us/power-platform/guidance/coe/after-setup-tenant-hygiene [vendor], accessed 2026-10-21. ↩

  6. Thoughtworks Technology Radar, "AI-accelerated shadow IT" (Caution), Apr 2026. https://www.thoughtworks.com/radar/techniques/ai-accelerated-shadow-it [vendor; a consultancy's practitioner assessment], accessed 2026-10-21. ↩

  7. Act respecting the protection of personal information in the private sector, CQLR c. P-39.1, s. 8.1 (informing people of technology that can identify, locate or profile them). https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1 [statute], accessed 2026-10-22. ↩