Find and stop shadow AI usage

Discover unregistered models and ungoverned clients, then close the gap with a strict model registry, per-identity policy and a record of every attempt.

Shadow AI rarely looks like rebellion. It looks like a team that needed an answer, had a company card, and signed up for a model API. The traffic exists; the governance does not. The first step is making it visible, and the second is deciding what to do about it.

The short answer#

  • You cannot govern what you cannot see: log every model request through one gateway.
  • A strict registry turns "unknown model" from a silent success into a refusal you can act on.
  • Attribute usage to an identity, so an unregistered client has a name attached.
  • Expect the first week to be noisy: most shadow usage is benign and simply needs an approved path.

How to do it in AI-FW#

  1. Put the gateway in the path. Point clients at one base URL. OpenAI-compatible and Anthropic-compatible clients work with a base-URL change, which is usually a one-line edit per team.
  2. Turn on strict model registration. With Reject unregistered models enabled, a request for a model nobody approved is refused rather than forwarded. That converts invisible usage into an explicit, attributable event.
  3. Watch the flags, not just the blocks. Shadow AI appears in the dashboard as unregistered-model attempts, and in Audit Logs with the caller identity.
  4. Give the team a legitimate path. Register the model that was being used unofficially, attach a per-model key so credentials stay server-side, and route it under policy. The goal is adoption, not a permanent block.
  5. Add risk scoring. Repeated unregistered attempts raise the risk score for that identity, which can trigger an automatic cooldown while you resolve it.

Verify it works#

  • Confirm unregistered-model attempts appear in the transaction log with an identity attached.
  • Check that registered models still serve normally: a strict registry should not break approved traffic.
  • Review Model Inventory monthly for models that are registered but unused, and keys that should be rotated.

Frequently asked questions#

Will strict model registration break approved traffic?

No. Registered models continue to serve normally. Only requests for unregistered models are refused, and each one is attributed to an identity so you can act on it.

How do we onboard a model a team is already using?

Register it with its provider and key, then let it route under policy. The goal is adoption through an approved path rather than a permanent block.

Onboarding both ways

The self-hosted buyer's checklist covers what to look for in the discovery controls, and Configure models & keys walks through registering them.