Shadow AI: How to Find and Govern Unsanctioned LLM Use

Shadow AI is work-related AI use outside your organization's approval or oversight. To find it, compare approved tools and accounts with network, identity, endpoint, repository and financial evidence. Then assess the data and permissions involved, contain urgent risks, and move useful work onto an approved path.

A developer's personal API key in a company repository, a coding agent with shell access and customer tickets in a personal chatbot account each need a different response. This guide gives you nine evidence sources, a triage method, a governance plan and a downloadable audit checklist.

What counts as shadow AI?

Shadow AI is a subset of shadow IT, the use of technology outside approved oversight. AI adds questions about what reaches a model, how generated output is used and what an agent can do. Approval needs to cover the workflow, not only the vendor name.

Common examples include:

Palo Alto Networks includes unreviewed AI features in approved SaaS in its shadow AI examples. An approved application is not blanket approval for every future feature or integration.

Why shadow AI happens and where the risk sits

Employees can adopt a useful tool before procurement finishes reviewing it, or the approved option cannot do the task. CrowdStrike identifies approval delays, accessibility and unclear policies among the drivers. Use the audit to learn what the sanctioned path is missing.

In CybSafe and NCA's 2024 survey, 38% of employed respondents reported sharing sensitive information with AI without their employer's knowledge.

Do not equate every AI prompt with model training. As of September 2026, OpenAI's individual-service policy allows training use subject to controls, while its API does not train on customer data by default. Anthropic's consumer rules describe opt-in and other training conditions, while its commercial products do not train on inputs or outputs by default.

How to detect shadow AI: nine places to look

Start with evidence you already have.

1. Define the audit boundary and invite disclosure

Name one coordinator. Security handles incident decisions, IT covers devices and browsers, identity covers grants, finance covers purchases, and engineering maps credentials and agents to workloads.

Publish your approved inventory with tool, account type, owner, permitted data and allowed integrations. A vendor-name list is too coarse to reconcile against findings.

Offer a time-bounded amnesty for good-faith disclosure of ordinary unapproved use, subject to incident and legal obligations. Ask what people use, how they authenticate, what data they provide and what the tool can do. Do not promise immunity for active harm.

Choose a review window, such as the last 30 days, and record what is outside scope: unmanaged devices, missing logs, remote workspaces or personal accounts.

2. Correlate network destinations with identity and process

Use a maintained cloud-app catalog and provider API destinations, then compare results with the approved inventory. Microsoft Cloud Discovery can analyze firewall and proxy logs, but cannot discover apps outside its catalog by default. Available user, URL and upload fields depend on the log source.

A DNS lookup is not a prompt. A connection to a vendor site could be documentation browsing. For HTTPS, Cloudflare documents that full URLs, headers and bodies remain hidden without TLS decryption. Inspection exceptions and client integrations affect coverage.

Follow a candidate destination to its device, account and initiating process. An agent might appear as node or python, so inspect parent processes and configuration ownership rather than relying on a product name.

DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl =~ "api.anthropic.com"
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp),
    NetworkEvents=count()
    by DeviceName, InitiatingProcessAccountUpn, InitiatingProcessFileName, RemoteUrl
| order by NetworkEvents desc

Next, review corporate sign-ins, OAuth grants and app-to-app integrations. Defender for Cloud Apps can show user-installed OAuth apps accessing Microsoft 365, Google Workspace and Salesforce data. Review enterprise applications and service principals separately in your identity platform.

Capture publisher, scopes, granting identity, consent time and business owner. A grant establishes permission, not proof of a transfer. Corporate SSO also does not reveal every personal-email login.

3. Reconcile purchases and cloud activity

Ask finance for AI subscriptions, API-credit purchases and reimbursements. Search descriptors, then inspect receipts and ask the buyer: ambiguous merchant names and bundled features make brand-keyword searches incomplete. Free tools and personal-card purchases will not appear in corporate statements.

For cloud usage, reconcile service bills with resources and principals. AWS Cost Explorer supports service, account, region and usage-type filters. Use equivalent evidence in your other clouds.

Check audit collection before drawing conclusions. Current Bedrock CloudTrail documentation lists model invocation and Converse operations as management events, while agent calls such as InvokeAgent require data-event selectors. Data events are not logged by default. The absence of a charge or audit event does not establish that no AI was used.

4. Scan repository history and working files for provider keys

A provider credential could be a placeholder, a revoked key or an approved service credential. Establish issuer, owning account, sanctioned status and exposure.

Recognizable cues include Anthropic sk-ant- examples and OpenAI sk-proj-, sk-svcacct- and sk-admin- formats, represented in Gitleaks' Anthropic rules and OpenAI rules. GitHub warns that token patterns change, so use maintained rules and generic secret detection rather than a homemade prefix-only regex.

Install Gitleaks using its release instructions, then run these scans separately from an authorized local repository. The commands below follow the Gitleaks v8.30.1 reference, checked September 30, 2026.

# Check available history, refs, scan configuration and exclusions first.
gitleaks version
 
# Scan history across locally available refs.
gitleaks git --log-opts="--all" --redact --exit-code=2 \
  --report-format json --report-path ../shadow-ai-history.json .
 
# Separately scan current files, including uncommitted configuration.
gitleaks dir --redact --exit-code=2 \
  --report-format json --report-path ../shadow-ai-files.json .

A shallow clone or missing refs limits historical coverage. Review scanner exclusions and test credential coverage with synthetic fixtures.

Gitleaks v8.30.1 returns 1 for findings or errors by default. The --exit-code=2 flag above gives completed scans with findings a separate status. Preserve and review stderr for scan errors and report-writing failures. A failed scan can still leave a partial report: report existence or valid JSON does not prove scan completeness.

5. Inventory endpoints, extensions and MCP configurations

Collect authorized app, package and process evidence through endpoint management. Record device coverage, then reconcile browser and IDE extensions against approved tools.

Microsoft's Shadow AI admin-center experience is in public preview as of September 2026. It requires Frontier opt-in, Defender for Endpoint, Microsoft 365 E5 and Intune enrollment for managed Windows devices. Check its per-agent coverage before using it in your audit; preview blocking is limited to OpenClaw on Intune-managed Windows devices.

Chrome's apps and extensions report covers enrolled browsers and ChromeOS devices with reporting enabled. Review requested website access and permissions, not only extension names.

MCP (Model Context Protocol) connects AI clients to tools, databases and APIs. For a local development machine, the VS Code CLI and Claude Code MCP reference document these inventory commands:

# Requires the VS Code CLI on PATH.
code --version
code --list-extensions --show-versions
 
# Repeat for profiles that exist. "Work" is an illustrative name.
code --list-extensions --show-versions --profile "Work"
 
# Inspect untrusted project configuration before running this command.
claude mcp list

Repeat across relevant profiles, remote workspaces and CI runners. Claude MCP listing can contact configured servers for health checks, so inspect untrusted configuration in a controlled context rather than launching it automatically.

Review project .mcp.json, user/local definitions in ~/.claude.json, plugins, connectors and managed configuration. Do not export full env, authentication headers or tokens into the inventory.

For each server, identify its operator, executable or URL, authentication, reachable data stores and read/write rights. MCP security guidance treats local servers as an executable-system risk. A local stdio server can evade a provider-domain hunt while still accessing sensitive files or external tools.

6. Grade evidence before calling it a violation

Use four evidence labels:

For a suspected transfer, correlate timestamps and identities with authorized DLP alerts, file-access logs or SaaS sharing events. Treat a nearby download or copy event as a lead, not proof of what reached the AI service.

Keep these grades visible in the findings handed to managers. They distinguish a capability that needs review from activity that warrants incident response.

Assess findings and choose a remediation

Prioritize data sensitivity, reachable systems, action authority, credential ownership, vendor terms and observed activity.

Keep one inventory record per distinct tool/account/workflow. The following hypothetical finding shows how to record evidence, restrictions and follow-up tasks.

Require accepted data handling, model access and tool permissions before the migrated workflow processes company code.

tool_vendor,feature_model,client_version,account_type,human_service_owner,team,purpose,discovery_source,evidence_grade,last_seen,credential_issuer,redacted_credential_identifier,data_classes,training_retention_review,gateway_region,inference_region,accessible_repositories_data_stores,mcp_servers_tools,read_write_external_action_rights,approval_status,outcome,interim_restriction,remediation_owner,due_date,review_date,evidence_reference

Use four outcomes:

• Contain now: exposed live credentials, apparent unauthorized sensitive-data transfer, or an ownerless agent with high-impact production permissions. Follow incident response, preserve evidence and coordinate revocation.
• Assess and migrate: useful work with company data but a personal account or missing review. Supply corporate access and narrow permissions after review.
• Approve with conditions: accepted vendor terms, an accountable owner, allowed data and scoped authority.
• Prohibit or isolate: unacceptable data handling or permissions. Offer an approved replacement or a synthetic-data sandbox.

Contain urgent risks while the broader enablement rollout proceeds.

Govern shadow AI without removing useful workflows

Discovery is the first control in a wider program. Our AI governance framework template covers owners, approvals, data rules and audit evidence; the steps below focus on what changes once you know where shadow AI is.

Make the approved route easier to use

Give employees a place to request access, published approval criteria and an expected response time. Support the workflow people need: browser chat, coding assistance, internal applications or tool-connected agents. An API gateway does not replace an approved browser workspace for an employee who needs one.

Publish allowed tool/account/data combinations, not just brands. A public-text drafting tool and a customer-record processing tool need different conditions. Exceptions should have an owner, limited scope, compensating controls and an expiry date.

Train each role using examples of permitted inputs, prohibited data and the exception process. Name who reviews generated code, customer-facing content and consequential decisions before they are used.

Keep model access separate from action permissions

An approved model does not decide which repository an agent may read, what its shell may execute or which database records it can delete. Restrict those through client policy, operating-system boundaries and downstream roles. Approval prompts alone are not the same as restricted credentials.

Claude Code's security documentation describes mode-dependent permissions. Its managed MCP controls provide organization-managed server restrictions. Verify the policy used by each client rather than assuming every agent has the same controls.

Define data, identity and spending rules

Issue separate credentials for people and automation. Shared team keys identify a team but do not reliably distinguish individual users. Use user-owned access for people and service accounts for automation. Caller-supplied labels supplement identity; they do not authenticate it.

Set spending caps and alerts, an offboarding process and a named owner for each workload. Alerts notify; caps enforce spending limits.

Document allowed data classes, provider retention, gateway logging and who can read evidence. Configure Requesty's payload logging and telemetry to match those rules. Start with metadata where it answers the audit question. GDPR Article 5 includes data-minimization and storage-limitation principles: employee monitoring should not create an unnecessary prompt archive. Review the collection with privacy/legal.

Test enforcement and record blind spots

Run controlled tests with synthetic data. Repeat when tools, grants or client policies change, and schedule a recurring review. Track inventory ownership, overdue remediation and telemetry coverage, not just the number of blocked requests.

Put engineering AI on a governed path with Requesty

The way to reduce shadow AI is to make the approved path easier than the workaround. With Requesty, give each developer or workload one key for access to 600+ models through OpenAI-compatible and Anthropic-compatible endpoints, with credentials, model policy and spending controls managed centrally.

ZoomInfo routes AI access for 1,300+ engineers through Requesty, including coding tools and internal applications, with provider credentials held inside the gateway, approved models, RBAC and unified cost tracking.

"Every engineer wanting to access AI at ZoomInfo now has to go through Requesty!"

Arkady Landes, Senior Cloud DevOps Manager, ZoomInfo

Build the paved road around four mechanisms:

• Provider credential isolation: hold organization-owned provider credentials behind the gateway using BYOK, issue Requesty keys to engineers and protect those keys as secrets.
• Scoped identity: issue person-specific keys for developers and service-account/workload keys for automation, then attribute usage by person, workload and tool through usage analytics and client metadata.
• Model policy: configure Approved Models and Access Lists for your organization, teams and workloads.
• Spending controls: apply monthly caps at key, user, team and organization levels, with Group Budget mode enabled for a pooled team budget.

Enable input PII and secrets Guardrails in Report or Mask mode. Start with Report, review matches, then test Mask on representative traffic. Connect supported remote servers through our MCP Gateway to manage server registration, selected tools and authentication in the same console.

Pair Requesty with endpoint and egress controls because the gateway sees only traffic sent to it. Configure the allowlist before rollout: without Approved Models or a scoped Access List, the full catalog is available by default.

Use our coding-client and application integration guides to configure your tools. Before migrating, check native-tool compatibility with synthetic requests so the approved path preserves the features your team needs.

For a Claude Code CLI pilot, replace your-requesty-key with the issued key. The example uses anthropic/claude-sonnet-5-5; select a model approved for that key.

export ANTHROPIC_BASE_URL="https://router.requesty.ai"
export ANTHROPIC_AUTH_TOKEN="your-requesty-key"
# Optional: set the approved model for this session.
export ANTHROPIC_MODEL="anthropic/claude-sonnet-5-5"
claude

The Claude Code integration guide covers persistent settings and client setup. Run /status to confirm the effective base URL and credential source, then send a synthetic request and confirm its key and model in Requesty logs.

Make governed access the easy option

For an organization-wide rollout, talk to Requesty Enterprise about identity, model access, spending controls and tool integrations. To pilot the approved path with one team, create a Requesty account.

Your shadow AI audit checklist

Start with one team. Resolve the highest-risk access, migrate one useful workflow and test both the sanctioned path and the path that avoids it. Then expand the audit with a clear record of your coverage and remaining blind spots.

Sources

Documentation and commands checked September 30, 2026. Survey results retain their original research date.

• IBM: Shadow AI definition
• CybSafe and NCA: 2024 AI data-sharing survey
• Microsoft: Cloud Discovery setup and limits
• Gitleaks: v8.30.1 command reference and exit codes
• Claude Code: Gateway connection and verification
• OpenAI: API data handling
• Requesty: Approved Models
• Requesty: ZoomInfo customer story