Discovery finds AI observations; operations must reconcile the inventory

AI inventory has moved beyond a list of sanctioned chatbots

A board asks, “How many AI systems are we using?” The operations team exports an approved-tool list. Security exports proxy traffic. IT exports installed software. Identity exports OAuth grants. Engineering exports API keys and MCP configurations. Every answer is internally correct, and none describes the same population.

Current products reflect that fragmentation. Netskope's beta Client AI Discovery periodically scans managed Windows and macOS endpoints for named AI agents, local models, MCP servers, browser extensions, and IDE extensions. Its documentation is unusually useful because it also names the blind spots: signature-only detection, active-user profiles, unmanaged environments, and agents or models inside separate virtual machines and containers.

Drata announced limited-availability AI Agent Governance on August 4 with device sensors, an MCP proxy, and a tamper-evident evidence feed, initially deepest for Anthropic environments. The announcement describes discovery, monitoring, policy simulation, action logging, and governance. Those are vendor claims for a limited-availability product, not independent proof of universal coverage. They still show where enterprise requirements are heading: inventory now includes non-human identity, tool calls, permissions, and evidence, not only a product name.

NIST AI RMF Govern 1.6 states that mechanisms should exist to inventory AI systems according to organizational risk priorities. The word mechanisms matters. A quarterly spreadsheet without feed lineage, owner recertification, exception aging, and closure evidence is not a reliable mechanism. Recent r/AI_Governance and r/Information_Security discussions make the pain concrete: practitioners can see fragments of activity but cannot give leadership a defensible exposure number.

Use seven discovery surfaces and publish each blind spot

No row is optional in principle, but availability varies. A small company may begin with identity, managed-browser, endpoint, procurement, and attestation exports. A regulated engineering organization may add repositories, secrets, model gateways, cloud bills, and agent traces. The inventory must say which population each feed actually covers. “Endpoint scan complete” means little if contractors use unmanaged devices or production agents run in containers.

Respect employee privacy and labor rules. Discovery should be authorized, purpose-limited, minimized, retained for a defined period, and reviewed with Privacy, Legal, HR or works councils where appropriate. An inventory does not need prompt contents to establish that an application, identity, model endpoint, or credential exists.

Do not flatten an AI workflow into one product-name cell

“ChatGPT” may refer to a managed enterprise tenant, a personal account, a browser extension, a desktop agent, an API key, a model endpoint used through another SaaS product, or an agent connected to internal tools. These have different owners, contracts, data terms, credentials, and effects. Model the relationships explicitly.

asset_id: ai-asset-004218
product: Claude Desktop
publisher: Anthropic
observations:
  - endpoint: device-882/process-19344
  - identity: oauth-grant-771
workflow:
  name: vendor-contract-analysis
  business_owner: procurement-ops
  technical_owner: enterprise-apps
connections:
  mcp_servers: [filesystem-approved, contract-repository]
  data_classes: [confidential-contract]
  credentials: [oauth-grant-771]
authority:
  read: contract-repository
  write: none
status: approved-with-controls
approval_expires: 2026-11-30

Use deterministic identifiers where possible: publisher plus package ID, extension ID, OAuth client ID, service principal, model endpoint ARN, repository dependency, or signed agent identity. Names and domains are supporting evidence, not identity. Two observations with the same marketing name can be different assets; two different product names can be one embedded workflow.

for observation in discovery_snapshot:
    candidate = normalize(observation)
    matches = inventory.find_by_stable_ids(candidate.stable_ids)
    if len(matches) == 1:
        link(observation, matches[0])
    elif len(matches) == 0:
        create_candidate(candidate, status="needs-owner")
    else:
        open_exception("ambiguous-match", observation, matches)

reconcile_owners()
map_data_and_authority()
require_human_disposition()

Never let fuzzy matching silently merge assets. A false merge can attach the approved contract and owner of one tenant to a personal or unmanaged instance. Keep confidence, match reason, raw source IDs, and reviewer identity.

Reconcile in five gates

Start by validating feeds. A missing day of proxy logs is not zero use. A signature scan does not discover unknown packages. An identity report may show an app registration without proving current use. Preserve source-level truth before creating the management summary.

Next add business context. Ask why the workflow exists, which approved alternative was considered, who can stop it, what continuity plan applies, and what value it creates. Shadow use often grows where an approved path is slow or inadequate. Closing the risk may require migration and a fast approval lane, not only enforcement.

Then make one explicit disposition per canonical asset and workflow. “Known” is not a disposition. Approval needs conditions and expiry. Restriction needs enforceable controls. Removal needs closure evidence. Investigation needs an owner and deadline. Decommissioning needs confirmation that identities, credentials, extensions, data flows, and recurring jobs are gone.

Worked example: one agent appears as four observations

An endpoint feed reports Claude Desktop on device D-77 with a local filesystem MCP connection. The identity feed shows an Anthropic-related OAuth grant for the same employee. The proxy feed shows traffic to an approved enterprise domain. A repository scan finds an MCP configuration referencing the contract repository. Counting rows produces four “AI assets.” Ignoring three feeds produces a harmless desktop-app record.

Reconciliation links the endpoint process and OAuth client through the employee and timestamp, then connects the repository configuration after a technical owner confirms deployment. The business owner says the workflow drafts vendor-contract issue lists. Procurement provides an approved enterprise subscription. Security confirms read-only repository access, but the endpoint record reveals the filesystem MCP server can read a broader local directory than the approved purpose requires.

The correct disposition is approved with controls, not approved or prohibited. Restrict the MCP root to the contract workspace, test read-only access, document the enterprise tenant and data terms, set a 90-day recertification, and retain the technical evidence. A follow-up scan and tool-call test must prove the broader path is no longer reachable.

If the OAuth identity belongs to a personal account or the employee uses an unmanaged device, the match becomes an exception. Do not borrow the enterprise contract's approval. Preserve business continuity, migrate the workflow to the approved tenant, rotate or revoke affected credentials, and assess whether confidential contract data left approved boundaries.

Control the inventory as operational evidence

Microsoft's internal Copilot governance account reinforces the same operating idea: inventory extraction, sensitivity labels, DLP, ownership, and employee practices must work together. No dashboard substitutes for clear roles and a usable approved path.

Report the denominator, uncertainty, and closure—not a magic asset count

Leadership usually asks for one number because the inventory has not yet established a shared unit. Keep at least three counts separate: raw observations, canonical assets, and active business workflows. One approved enterprise assistant used through a browser, desktop client, OAuth grant, and repository integration can create four observations, one asset relationship, and several distinct workflows. Conversely, one browser domain may conceal personal and enterprise tenants with very different contracts and data paths.

Every dashboard should state its coverage denominator. For endpoints, report managed devices observed, eligible devices, stale clients, unsupported platforms, inactive profiles, and known unmanaged populations. For identity, report directories and tenants included, the period covered, and which credential types remain invisible. For network data, report inspected paths, bypasses, remote access, and whether local or encrypted use is outside scope. Unknown coverage is a result, not a footnote.

A defensible executive statement sounds like this: “Within 92% of managed endpoints, two corporate identity tenants, approved network paths, and the production model gateway, we reconciled 640 observations into 118 canonical assets and 74 active workflows. Twelve assets lack an accepted owner, eight exceptions exceed policy age, and unmanaged devices remain outside measured coverage.” The numbers here are illustrative, not site findings; the structure is what matters.

Do not rank employees or teams by raw observations. A high count can reflect a software deployment, testing activity, or better telemetry rather than higher risk. Review risk at the workflow level using data sensitivity, decision consequence, external effect, credential and tool authority, affected population, contractual status, and control evidence. People metrics require a separately approved purpose and qualified HR, privacy, legal, and employee-relations review.

Failure modes that make inventories look better than they are

A 30-day pilot should prove reconciliation before enforcement

1. Choose one business unit and document exact populations and monitoring authority.
2. Connect at least four available surfaces and validate their coverage independently.
3. Reconcile observations into canonical assets without automated enforcement.
4. Assign owners and map purpose, data, credentials, tools, and procurement.
5. Human-review every proposed match and disposition for the first two weeks.
6. Close a small set of low-risk actions and prove technical outcomes.
7. Measure orphan rate, unresolved rate, exception age, repeat discovery, false classifications, and time to closure.
8. Only then pilot targeted enforcement with a rollback and employee support path.

The pilot succeeds when the team can explain its denominator. Report observation count, canonical assets, active workflows, covered population, unknown coverage, approved/restricted/unresolved dispositions, and aged exceptions. A single “shadow AI count” without definitions will not survive the next scan.

FAQ

What belongs in a shadow AI inventory?

Include AI applications, embedded SaaS features, agents, models, extensions, MCP servers, integrations, identities, credentials, data flows, connected tools, business purposes, owners, approvals, exceptions, and closure evidence.

Can one vendor discover everything?

No. Every sensor has stated or implicit limits. Reconcile multiple feeds, publish blind spots, and use attestation and sampling for what technology cannot see.

Should all shadow AI be removed?

No. Decisions should consider business need, safe alternatives, data and authority, contract status, risk, continuity, and the ability to add effective controls.

How often should the inventory be refreshed?

High-signal feeds may update continuously or daily. Owners and exceptions should be reviewed on a risk-based schedule, with immediate review after new high-risk assets, identities, data flows, or permissions appear.