# Finding shadow AI: unapproved model API usage and how to govern it

URL: https://infro.io/blog/shadow-ai-api-usage
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-20
Last modified: 2026-10-20
Last reviewed: 2026-10-20 (next review due 2026-11-19)
Topic: Security and governance
Format: Guide

> Shadow AI API usage is model API traffic your organization did not approve or cannot see: keys on personal or team cards, unmanaged projects, prototypes in production. Find it by combining expense and card data, the providers' admin APIs (OpenAI's audit logs and project API key lists, Anthropic's API key list and usage report), egress logs for provider hostnames, and code and secret scanning. Then offer an approved path that is easier than the shadow one — a central gateway with keys per team, budgets and an allowlist — and a short written policy, rather than a ban.

Key takeaways:
- Shadow AI usage is model traffic you did not approve or cannot see; it is usually well-meant and badly governed.
- Find it from four sources: card and expense data, provider admin APIs, egress logs for provider hosts, and code and secret scanning.
- OpenAI's Admin API lists project API keys and audit log events; Anthropic's lists API keys by workspace and reports usage by key.
- Replace shadow usage with an approved path that is faster to use: keys per team in minutes, budgets, an allowlist, no procurement wait.
- Write a one-page usage policy covering data classes, approved providers, key handling and who approves exceptions.

**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 value[1][2].
- **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 key[3][4].

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](https://infro.io/blog/provider-admin-key-least-privilege) covers how.

```python
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:

1. **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).
2. **Providers and models.** The approved list, and how to request an addition.
3. **Keys.** Provider keys are held centrally; applications and people use scoped gateway keys; no provider keys in code, laptops or personal accounts.
4. **Spend.** Every key has a budget; who can raise it.
5. **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](https://infro.io/blog/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:

1. **Identify the owner and the workload.** Who created it, what calls it, how much it spends, and what data it carries.
2. **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.
3. **Run both for a short overlap.** Let the team move traffic behind a flag and confirm nothing breaks.
4. **Set a revocation date.** Agree it with the owner; revoke the shadow key at the provider on that date.
5. **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.

> **Example: One quarter's clean-up**
> A finance export shows seven provider charges outside the platform team's accounts. Four are prototypes that are retired. Two are production services on a team card; their owners get gateway keys with budgets, switch in a week, and the card keys are revoked. One is a contractor's integration; the contract is amended to require the approved path and a data processing clause. Monthly spend outside the platform drops to zero, and the next quarter's report checks that it stays there.

## 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.

## Questions

### What is shadow AI?

AI usage an organization has not approved or cannot see. For engineering teams it usually means model API keys on personal or team cards, unmanaged provider projects, or prototypes calling a model in production without review. It is rarely malicious; it exists because the approved path was slower.

### How do I find OpenAI API keys in my organization?

For accounts you own, OpenAI's Admin API lists API keys per project with their owner and a redacted value, and its audit log records key creation, updates and deletion. For accounts you do not own, look at card and expense data, egress logs for api.openai.com, and secret scanning of your repositories.

### Should we ban unapproved AI tools?

A ban without an alternative pushes usage further out of sight. Offer an approved path that is faster than the shadow one — keys in minutes, clear budgets, an allowlist of models — and a short policy on data, then retire the shadow keys as teams move.

## Sources

1. List audit logs — OpenAI. https://developers.openai.com/api/reference/resources/admin/subresources/organization/subresources/audit_logs/methods/list (accessed 2026-10-20)
2. Admin APIs — OpenAI. https://developers.openai.com/api/docs/guides/admin-apis (accessed 2026-10-20)
3. Admin API — Anthropic. https://platform.claude.com/docs/en/manage-claude/admin-api (accessed 2026-10-20)
4. Usage and Cost API — Anthropic. https://platform.claude.com/docs/en/manage-claude/usage-cost-api (accessed 2026-10-20)