How do you find shadow AI usage? Look in four places: card and expense data for provider charges, the providers' own admin APIs for keys and projects in accounts you control, egress logs for traffic to provider hostnames, and code and secret scanning for keys in repositories. Then make the approved path easier than the shadow one — a central gateway that issues keys per team in minutes, with budgets and a model allowlist — and write a one-page policy. Bans without an alternative only move the traffic further out of sight.
What shadow AI usage looks like
For engineering organizations, shadow AI is rarely a rogue tool. It is usually one of these:
- A key on a personal or team card. Someone needed a model for a prototype and expensed the account.
- An unmanaged project in the company account. Created by someone who has since left, still holding a live key.
- A prototype that became production. It calls a provider directly, with no budget, no logging and no review of the data it sends.
- A coding agent on a personal subscription, running against company code.
- A vendor or contractor integration using its own model account with your data.
Each is a cost risk (spend nobody budgets), a security risk (keys nobody rotates) and a data risk (prompts carrying information nobody classified). None is solved by finding the people involved and telling them off; they were solving a real problem faster than the approved route allowed.
Four ways to find it
1. Money
Search card statements and expense reports for every model provider and cloud AI service. A recurring charge from a provider your platform team does not manage is the most reliable signal there is, and it surfaces accounts you have no admin access to. Ask finance for a monthly report filtered on provider names.
2. The providers' admin APIs
For accounts the company owns, the providers expose what you need:
- OpenAI. The Admin API's audit log lists user actions and configuration changes in an organization, filterable by actor, project, resource and event type, including API key creation, updates and deletion; project endpoints list each project's API keys with their owner and a redacted value12.
- Anthropic. The Admin API lists API keys across the organization, filterable by status and workspace, and the usage report breaks token usage down by model, workspace and service tier and can filter by API key34.
Run both monthly. Look for keys with no recent owner, keys in projects or workspaces nobody claims, and usage on keys outside your gateway. Admin keys are powerful, so hold them in the platform team only; least privilege for provider admin keys covers how.
import os
import requests
ADMIN = {"Authorization": f"Bearer {os.environ['OPENAI_ADMIN_KEY']}"}
BASE = "https://api.openai.com/v1/organization"
projects = requests.get(f"{BASE}/projects", headers=ADMIN, params={"limit": 100}).json()["data"]
for project in projects:
keys = requests.get(f"{BASE}/projects/{project['id']}/api_keys", headers=ADMIN).json()["data"]
for key in keys:
owner = (key.get("owner") or {}).get("user", {}).get("email", "service account")
print(project["name"], key["name"], owner, key.get("last_used_at"))The script is a starting point: paginate, write the output somewhere durable, and compare it month to month.
3. Egress
If production traffic leaves through a proxy, NAT gateway or firewall that logs destinations, search for provider API hostnames — api.openai.com, api.anthropic.com, generativelanguage.googleapis.com and the rest — by source service. Traffic to a provider from a service that should be going through your gateway is shadow usage by definition, and the source tells you who to talk to.
4. Code and secrets
Secret scanners in your repositories and CI catch provider keys committed to code, and a code search for provider SDK imports and base URLs lists every service that calls a model directly. Treat a committed key as compromised: revoke it at the provider, then find out why it was there.
Make the approved path faster
Shadow usage exists because the official route was slower. Fix that first:
| Shadow usage happens because… | The approved path should offer |
|---|---|
| Getting a key takes a ticket and a week | A key per team or service in minutes, self-service |
| Procurement for a new provider takes months | Pre-approved providers and models, with an allowlist |
| Nobody knows what they may spend | A budget per team, visible to the team |
| Prototypes need models now | A sandbox environment with a small budget and no production data |
| Coding agents need setup | A documented gateway configuration and a key per developer |
A central gateway or control plane makes this practical: provider accounts are held once, centrally; teams get scoped keys; budgets and allowlists are enforced before the provider is called; and every request is attributed. Once that exists, retiring shadow keys is a migration, not a confrontation.
A one-page AI usage policy
A policy engineers read is short. Cover five things:
- Data. Which data classes may be sent to which providers (for example: public and internal data to approved providers; customer personal data only through approved paths with guardrails; credentials and secrets never).
- Providers and models. The approved list, and how to request an addition.
- Keys. Provider keys are held centrally; applications and people use scoped gateway keys; no provider keys in code, laptops or personal accounts.
- Spend. Every key has a budget; who can raise it.
- Exceptions. Who approves them, and how long they last.
Review it twice a year. The provider and model list will change faster than the rest; model access governance covers keeping the allowlist current.
Moving shadow usage onto the approved path
Finding shadow keys is the start. Moving the traffic without breaking anything takes a plan per key:
- Identify the owner and the workload. Who created it, what calls it, how much it spends, and what data it carries.
- Offer the replacement first. Issue a key on the approved path with a budget that covers the current spend, and a short guide to switching the base URL.
- Run both for a short overlap. Let the team move traffic behind a flag and confirm nothing breaks.
- Set a revocation date. Agree it with the owner; revoke the shadow key at the provider on that date.
- Close the account if it was personal. Make sure a personal provider account used for company work is cleaned up, including any data it retained.
Governing it with INFRO
INFRO holds your provider accounts' credentials once, sealed, and issues gateway keys per team, service or developer that can be limited to chosen providers, environments and IP ranges. Model allowlists apply at organization, project and key level; budgets at organization, project, member and key level refuse a request before the provider is called; and every request is attributed by project, key and model. The audit log records who created keys, changed allowlists and raised budgets. It does not discover keys in accounts you have not connected — the four searches above do that — but it gives the traffic you find somewhere governed to move to.
Summary
Find shadow AI with money, admin APIs, egress logs and code scanning. Then make the governed path faster than the ungoverned one — self-service keys, budgets, an allowlist, a sandbox — write a one-page policy, and retire the shadow keys as teams move.