Audit Shadow AI Without Driving It Underground

Run a shadow AI audit as a repeatable discovery-and-treatment process, not a hunt for rule-breakers. Define the scope, combine technical and employee-reported evidence, create one record for each distinct AI use case, score its actual exposure, assign an owner and offer an approved alternative before imposing a broad block.

The central artifact is a living worksheet, not a blacklist. It should show what capability is being used, by whom, for which business purpose, with what data and permissions, under whose accountability, and by what date the risk will be accepted, reduced or removed.

1. Set the audit boundary and reporting terms

Start with a decision-oriented scope: identify unapproved AI capabilities receiving company data, assess each use case and assign remediation. Include standalone services, personal accounts, APIs, browser extensions, locally installed models, agents and AI features embedded in otherwise approved software. Create separate records when one provider’s assistant, API and autonomous workflow have different users, permissions or data access.

Name an audit lead and participants from security, IT, privacy, legal, procurement and affected business units. Record the workforce groups, devices, subsidiaries and systems in scope; the collection period; permitted evidence sources; access controls; and deletion dates. Review employee-monitoring requirements with legal and HR instead of assuming that access to telemetry permits unrestricted inspection of content.

Give staff a low-friction route to disclose a tool and explain the unmet need behind it. The UK National Cyber Security Centre’s guidance advises organizations to understand why employees use unapproved services, communicate openly and provide secure alternatives, because shadow AI is unlikely to disappear entirely.

2. Discover capabilities across several control planes

Multiple enterprise evidence sources are reconciled to verify an unapproved AI use case without treating a single signal as proof.

No single log provides a complete inventory. Reconcile network, endpoint, identity, cloud and SaaS signals with commercial records and voluntary disclosures; the Adaptive Security audit framework similarly combines multiple discovery sources and includes embedded features, extensions, APIs, agents and personal accounts within scope.

Network: DNS, proxy, secure web gateway and firewall records can reveal destinations and activity patterns, but not necessarily a user’s purpose or the content transmitted.
Endpoint and browser: installed applications, extensions and managed-browser events can expose local tools and page-level activity, subject to policy and legal constraints.
Identity and cloud: sign-ins, OAuth grants, service accounts, API keys, SaaS administration and cloud audit events can connect a capability to an identity and its permissions.
Commercial records: contracts, invoices, expense claims and corporate-card transactions can reveal services bought outside normal procurement.
People and workflows: a short disclosure form, workflow-owner interviews and an amnesty period can uncover personal accounts, pasted-data workflows and legitimate needs that telemetry misses.

Do not turn a DNS lookup or expense line directly into a violation. Confirm that the service was used, establish the identity where possible, ask for the business purpose and determine whether company data entered the system. Record evidence confidence and preserve only the minimum content needed to support the finding; collecting full prompts by default can create an additional privacy and security problem.

3. Build one worksheet that supports a decision

A vendor-neutral worksheet records distinct AI capabilities, their data handling, ownership, risk and remediation.

Create one row for each materially different capability or workflow. Use these vendor-neutral fields:

Tool and feature: provider, product, embedded function, model, extension, API or agent, plus version when relevant.
Identity: employee, contractor, service account or personal account; authentication method; and affected user group.
Permissions: OAuth scopes, connectors, accessible repositories, administrative rights and actions the system may take.
Data class and flow: input categories, retrieved sources, output destinations and downstream systems.
Retention: known provider retention, deletion controls, model-training terms and unresolved contractual questions.
Owner: accountable business owner and the technical or control owner responsible for remediation.
Business purpose: task, required outcome, frequency and reason an approved option is insufficient.
Human review: who verifies outputs, at what stage and before which decisions or external actions.
Risk tier: rating, rationale, evidence confidence and approval status.
Remediation date: required action, responsible party, due date, exception expiry and closure evidence.

Add the discovery source and last-review date so another reviewer can reproduce the decision without reopening unnecessary employee content. Mark unknowns explicitly: an unanswered retention question is work for the owner, not proof that retention is safe or unsafe.

4. Score the use case, not the brand

Assess impact and likelihood separately before assigning a tier. Impact should cover confidentiality, privacy, intellectual property, regulatory duties, output integrity, external effects and the consequences of an incorrect or unauthorized action. Likelihood should reflect frequency, user count, permission breadth, account controls, provider terms, logging, human review and whether the capability can act autonomously.

The NIST AI Risk Management Framework Core calls for risk-prioritized AI inventories, documented accountability, periodic review and treatment based on impact and likelihood. It does not prescribe one universal scoring formula, so use the organization’s established risk scale and retain the reasoning behind the result.

A low-impact drafting task using public material is not equivalent to a workflow that submits regulated records, retrieves confidential repositories or can send messages and execute changes. Raise the tier for restricted data, broad connectors, reusable credentials, consequential decisions or autonomous actions. Lower it only when effective controls are evidenced, such as data minimization, enterprise identity, narrower permissions, acceptable retention and meaningful human review.

5. Treat the need before enforcing the boundary

A verified shadow AI workflow is moved to an approved alternative before unsafe access is closed.

Send every verified row through the same decision path. Approve a low-risk use when its data handling, access and oversight are acceptable. Approve with restrictions when configuration, narrower permissions, permitted data classes or mandatory review can bring exposure within tolerance. Sandbox an experiment that still needs testing, or replace it with a sanctioned capability that meets the recorded business need.

Block or disable a capability when exposure is unacceptable and cannot be reduced promptly—for example, because it transfers prohibited data, holds excessive privileges or can take unsafe autonomous action. Route suspected incidents through the organization’s established response process, including credential rotation or access revocation where warranted. Every block needs an owner, reason, date and replacement route; otherwise the employee still has the same task and deadline but no visible safe way to complete it.

Notify the workflow owner of the finding and its evidence confidence.
Choose approval, restriction, sandboxing, replacement, blocking or a time-limited exception.
Record the control changes, approved alternative, owner and remediation date.
Verify closure with fresh evidence rather than a ticket status alone.
Schedule review when the model, feature, permissions, data, purpose or provider terms change.

Keep the register active after the initial audit: add new telemetry and disclosures, expire exceptions and recertify material use cases on a risk-based schedule. Success is a current inventory in which useful AI has a governed route into the business and unacceptable exposure has a documented route out—not a temporarily empty detection queue.