Skip to content

Platform

Find the AI your organization doesn't know it has

Surface unmanaged AI, shadow AI, unknown agents, unapproved models, external AI APIs and unregistered tools — then bring them under governance.

Found, not declared

Corroborated

5

Can change state

4

Against 11 declared systems. The comparison is the point — a discovery count on its own says nothing about coverage.

Why an inventory is not enough

The systems that matter most are the ones nobody registered.

A copilot that arrived with a seat licence. A scheduled job that quietly gained a model call. A SaaS feature that turned up in a release note. None of them passed through a build review, so none of them are on any list — and every one can change something.

This estate declares 11 AI systems and discovery has surfaced 5 more that were corroborated by at least two independent signals. 4 of the findings can change something in a system of record, which is the number that should set the order of work.

The honest framing is that this is not a scanning product finding secrets. It is a join across systems you already run, made useful by asking one question of every result: can this thing act?

All 5 sources are systems you already run.

Identity provider
OAuth grants to third-party AI applications, and which employee authorised each one.
Anything reached with a personal account or an API key rather than a corporate sign-in.
Egress proxy
Outbound requests to known model provider endpoints, by source workload and volume.
Traffic that leaves through an unmanaged network, and the contents of any request.
SaaS admin consoles
AI features enabled per tenant, and seat licences assigned to them.
Features enabled by default in a product update that nobody was notified about.
Code host search
Model SDK imports and provider base URLs across every repository.
Whether the code is deployed, and whether it runs against production.
Card and procurement data
Recurring charges to AI vendors, including ones below any approval threshold.
Free tiers, trials, and anything expensed as something else.

One signal is a lead. Two is a finding.

An OAuth grant proves somebody connected an app. Egress proves something called a model. A repository import proves code exists. None of those alone proves an ungoverned system is taking actions — which is why the headline number here is corroborated findings rather than raw detections.

What was found

Sorted by whether it can change something, not by how many seats it has.

Most shadow-IT reporting counts licences, which produces a long list ordered by spend. The column that should drive the work is whether the thing can reach a system of record.

Discovery findings

7 findings · 2 unclaimed
Every finding in the sample estate: what it appears to be, its kind, the team it appears to belong to, which sources saw it, whether it can change state in a system of record, its triage status, and when it was first seen.
What was foundKindAppears to belong toSeen byCan change stateStatusFirst seen
Vendor copilot enabled in the CRM tenantembedded AIRevOpsSaaS admin consolesIdentity provideryestriaged2 Sep 2026
Meeting notes app with an AI summarisercopilotSalesIdentity providerCard and procurement datatriaged18 Aug 2026
Scheduled script calling a model API directlyAI APIunattributedEgress proxyCode host searchyesunclaimed11 Sep 2026
Helpdesk macro suggestionsembedded AISupport OpsSaaS admin consolesonboarded4 Jul 2026
Document OCR with a model behind itapplicationFinanceCard and procurement dataEgress proxyyesonboarded22 Jun 2026
Consumer chat assistant used with work documentsmodelunattributedEgress proxyremoved9 Aug 2026
Reporting automation with a model call addedautomationOpsCode host searchEgress proxyyesunclaimed13 Sep 2026

Findings

7

across 5 sources

Can change state

4

triage these first

Unattributed

2

nobody to accept them

Brought under governance

2

registered and owned

IllustrativeThe OpsAI sample estate, alongside 11 declared systems. The declared inventory.

What happens next

Two outcomes, and a catalogue entry is not one of them.

A finding is either brought under governance or shut off. Leaving it discovered is the failure mode that makes discovery tooling feel like paperwork — a longer list every quarter and nothing changed.

  1. 01

    Can it change anything?

    The first question, and the one that sets the order. A summariser that reads is a different problem from a copilot that edits records, and counting seats tells you neither.

  2. 02

    Whose is it?

    Attribution is usually the slow part. An unattributed finding cannot be onboarded, because there is nobody to accept it — which is why the unattributed count matters more than the total.

  3. 03

    Govern it or remove it

    Registered with an owner and a rule at the action, or switched off at the source. Anything reached through a browser rather than an API has no boundary to sit in front of, so removal is often the only honest option.

Some things cannot be governed, and blocking them is the honest answer.

A consumer assistant reached through a browser has no API boundary to sit in front of, so it cannot be governed the way a connected agent can. Pretending otherwise would be the dishonest option. It is handled at the data boundary instead — which is a real control, just a different one.

How the data boundary handles it

Where to start

Ask your identity provider which AI apps have an OAuth grant.

It is a five-minute query against a system you already run, and it is usually the first time anyone sees the real number. Nothing about it needs OpsAI — which is rather the point about how available this information already is.