Investigating credential misuse through an AI gateway
A gateway can authenticate a valid key while still carrying unauthorized activity. Investigating that activity requires identifying the access boundary involved: the downstream client, the gateway account, or the upstream provider credential.
Choose the correct investigation scope
| You observe | Start here | Do not assume |
|---|---|---|
| One virtual key changes behavior | Its owner, permitted workloads, and request history | The entire upstream provider account is compromised |
| Many virtual keys change together | Shared deployments, routing, policy, and collector changes | Every customer independently became malicious |
| Provider usage exceeds gateway records | Direct clients, other gateways, missing logs, and timing differences | All unmatched traffic is theft |
| Management settings change unexpectedly | Administrative access and change history | Rotating one inference key resolves administrative access |
Compare the gateway's view with the provider's view
Establish which downstream principal the gateway authenticated and which upstream identity it used. Join request references where available. Separate missing records from records that contradict the expected route. Check clock alignment, retention, and retry semantics before treating a mismatch as suspicious.
If a provider key is also used by a direct application, gateway logs will not describe that application's requests. Inventory other authorized users of the credential rather than forcing every provider event into the gateway dataset.
Open a case with a falsifiable hypothesis
Write a statement such as “the new request population on this virtual key is not explained by the registered workload.” List the records that would confirm or disprove it: deployment history, job traces, owner confirmation, scope changes, and correlation to provider requests.
A generic statement such as “the account looks like a proxy” is harder to resolve. Many legitimate gateway customers are proxies. Investigate the permission boundary and unexplained usage instead.
A mismatch example
Synthetic example: provider records show 12,000 requests, while one gateway export contains 9,000. Before escalating, investigators find another approved gateway using the same provider credential with 2,000 requests. The remaining 1,000 are still unresolved. Neither the original 3,000 gap nor the final 1,000 should be labeled confirmed abuse without additional evidence.
Contain the affected authority
For confirmed compromise, follow the incident procedure at the control point that grants the access. A downstream restriction may not stop direct use of an upstream credential. Broadly disabling a provider key can affect unrelated tenants, so identify dependencies and verify the containment result.
For unexplained behavior without confirmed compromise, preserve the case and reconcile it with the owner. Record any temporary restrictions, their scope, and the conditions for reversal.
Read LiteLLM exposure response for the containment sequence and gateway provenance for the identity and request joins. Use the resale guide only when the hypothesis concerns downstream access distribution.