How do you tell if your AI API key is being abused? Look at usage per key, not per account, and look for things your own code would never do: activity on a key that should be idle, models you never call, traffic that runs flat through the night, output tokens far out of proportion to input, and keys or members you did not create. Each provider shows these in a different place, and most of them lag by minutes to a day, so the order you check them in matters.
This guide lists the signals, where OpenAI, Anthropic and Google show each one, a triage table for the first hour, and what to do once you are fairly sure. For what to do after you confirm a leak, see the provider-specific runbooks for a leaked OpenAI key and a leaked Anthropic key.
Why abuse hides in the total
A stolen key is usually used for one of three things: resold access through a proxy, bulk generation of outputs for someone else's training data, or running the attacker's own workload on your bill. All three add spend to an account that already has spend. On an account-level chart the new traffic looks like a busy week. On the chart for the one key that was leaked, it looks like nothing your application has ever done.
That is the first rule: break usage down by key, project or workspace before you judge it. It is also why one key per workload and environment pays off long before an incident: a key used by five services gives you nothing to compare against. How to secure LLM API keys covers the scoping.
The signals, strongest first
Usage on a key that should be idle
A key for a staging environment on a Sunday, a key you rotated out last month, a key issued to a contractor whose project ended. Any non-zero usage there is a question you can answer quickly, and a wrong answer is a strong sign.
Models your code never calls
Applications call a short, stable list of models. Usage of a frontier model you never deployed, a reasoning model on a key that only serves embeddings, or an image or video model on a chat-only key is hard to explain innocently. Attackers harvesting outputs tend to pick the most capable model available, because that is the output worth having.
Round-the-clock flat usage
Most product traffic follows people: it rises in the working day of your users and falls at night. A key that suddenly runs at a steady rate for 24 hours, with no quiet period, deserves attention. The CISA, NSA and FBI advisory on distillation campaigns lists round-the-clock usage among the indicators of abusive accounts, along with shared accounts used from many IPs and user agents, and new subscriptions that go straight to maximum usage1. The advisory is written for AI companies detecting abuse on their platforms and has no section for ordinary key holders; reading the same patterns on your own keys is our inference, not its guidance.
Output tokens out of proportion to input
Most applications have a characteristic ratio of input to output tokens: a retrieval feature sends long prompts and gets short answers, a drafting tool the reverse. Someone collecting training data wants long, complete answers, often with visible reasoning. A sharp rise in output tokens per request, or in reasoning tokens on a model that produces them, is a signal even when total spend looks ordinary. OpenAI notes that usage details can include cached-input and reasoning-token counts, which explain why a response's visible length does not show its full token usage2. Reasoning tokens and cost explains the mechanics.
Batch or cache patterns you do not use
If your workload never uses a provider's batch tier and the report shows batch usage on one key, someone else submitted it. The same applies to a sudden change in cached-input share. The CISA advisory names usage tuned to quotas and costs, including new accounts with high immediate hit rates, as a distillation indicator1.
New keys, members or service accounts
An attacker with console access, rather than one key, will often create a key of their own so that revoking yours does not lock them out. Audit logs show this. OpenAI's Audit Logs API records the lifecycle of API keys, invitations, users and service accounts, login failures and organization settings changes, once an owner turns audit logging on3.
Spend that departs from your usual day
A fixed threshold catches a bill that doubles; it misses a key that quietly adds 15% every day. Compare each day with the same weekday's usual level, per key or project. Five LLM spend anomalies covers the patterns legitimate code produces, so you can rule them out.
Signals that come from the provider
Some signs arrive by email: an abuse notice, a warning, an alert that a compromised API key was detected, or a suspension. Google Cloud's guidance for an abuse notification starts with verifying that the project was not compromised by checking its usage and logs, and treats a compromised-key alert as a reason to generate a new key and add API key restrictions4. Make sure those emails reach someone: Google recommends adding Essential Contacts for security, technical and suspension notices4. What to do when a provider suspends your account covers the next step.
Where each provider shows usage per key
| Provider | Console view | Per-key detail | Granularity |
|---|---|---|---|
| OpenAI | Usage Dashboard: filter by project and by user, shown in UTC2 | Usage API: api_key_ids filter and group_by=api_key_id, also model, project, batch, service tier5 | 1 minute, 1 hour or 1 day buckets5 |
| Anthropic | Console Usage and Cost pages6 | Usage API: filter and group by API key, workspace, model and service tier (Admin API key required)6 | 1 minute, 1 hour or 1 day; data usually within 5 minutes6 |
| Google (Gemini API) | AI Studio usage and cost dashboards, filterable by project, model and time frame7 | Cloud Billing reports grouped by project or SKU, with date grouping for daily detail8 | Daily in billing reports |
Two details trip people up. OpenAI's dashboard has its own project selector, and clearing it shows the whole organization2; a filtered view left over from last week can hide the abuse. In Anthropic's reports, usage from the Console's own playground carries a null API key id, and the default workspace shows as a null workspace id6, so null rows are not by themselves suspicious.
What to check first at OpenAI
- Open the Usage Dashboard, clear the project filter, and pick a range that starts before the suspected window2.
- Pull usage grouped by
api_key_idandmodelwith one-hour buckets from the Usage API (an Admin key is needed)5. Look for keys and models you do not recognize. - Check the audit log for API keys, service accounts and invitations created in the window3.
- If anything is unexplained, follow OpenAI's own guidance: change the password, which logs out current sessions within 30 minutes, and report through the unauthorized activity webform9.
What to check first at Anthropic
- Open the Console's Usage page and Cost page for the window6.
- With an Admin API key, query the Usage API filtered or grouped by API key and workspace, in hourly buckets6. A workspace per workload makes this readable.
- Compare the service tier and cache columns with what your code uses: batch, priority, cache reads and cache creation each appear separately6.
What to check first at Google
- In AI Studio, open the usage and cost dashboards for each project and filter by model7.
- In Cloud Billing reports, group by SKU and by date to see which Gemini SKUs grew and on which day8. Viewing every linked project needs a billing account role such as Billing Account Viewer8.
- Check the project owner's email and the Essential Contacts for abuse or compromised-key notices4.
A triage table for the first hour
| Signal | Likely innocent cause | Likely abusive cause | First action |
|---|---|---|---|
| Usage on an idle or retired key | A forgotten cron job or test | Key leaked from a repo, laptop or third-party tool | Revoke the key at the provider |
| A model you never call | A developer trying a new model | Someone harvesting outputs from the best model | Revoke; restrict models on the replacement |
| Flat 24-hour usage | A new batch or evaluation job | Proxy or scripted collection | Ask the key's owner; revoke if unexplained |
| Output tokens per request jump | A prompt change or new model snapshot | Long-form output collection | Compare with recent deploys |
| Batch or priority tier you do not use | A new internal job | Bulk generation by a third party | Revoke; check which key submitted it |
| New key, member or service account | A colleague's setup | An attacker keeping access | Remove it; review console sign-ins |
| Provider abuse notice or suspension | Rarely innocent | Compromise or a policy breach | Treat as an incident |
Once you are fairly sure
Act at the provider first. A leaked provider key works directly against the provider's API, so rotating it in a secrets manager, a gateway or a CI system does nothing until the old key is revoked at the source. Then:
- Revoke or disable the key at the provider and issue a scoped replacement.
- Lower the provider-side spend limit on the project or workspace for the next few days.
- Review the audit log for new keys, members and setting changes.
- Record the window, the models, the token counts and the cost from the provider's own report.
- Report the activity to the provider with those figures, and ask about the charges.
- Find the source: a repository, a client-side bundle, a CI log, a laptop, or a third-party tool that held the key.
Responding to AI API key theft and asking for a refund and LLM incident response cover the longer tail.
Prevention that makes detection easier
Detection after the fact is limited by what providers report. Provider usage reports group by key, project, model and time; they do not generally tell you the caller's IP address. Controls set in advance close that gap:
- IP allowlisting at the provider. OpenAI lets you restrict an organization or project to up to 50 IP addresses or CIDR ranges; requests from elsewhere fail with
401andip_not_authorizedeven with a valid key10. OpenAI is clear that this reduces risk but does not prevent all misuse10. - Provider spend caps. Google added monthly spend caps per project for the Gemini API, with a delay of about ten minutes during which overages are the customer's responsibility7. Provider spend limits compared covers the others.
- One key per workload and environment, so every key has an expected shape.
- A credential inventory with an owner and a purpose for each key. Building an AI credential inventory explains how.
How INFRO helps you spot abuse
INFRO is a gateway in front of provider accounts you own. For traffic that goes through it, it records every request with its key, project, environment, model, token counts and estimated provider cost, and its spend alerts flag a day that departs from a scope's usual day, with forecasts, delivered by email, Slack, Teams, PagerDuty or webhook (alerts). Gateway keys can be limited to chosen providers and IP ranges, and a request from outside them is refused with 403 ip_not_allowed before any provider call; budgets per organization, project, member and key refuse a request with 402 before the provider is called (spend controls).
Here is the limit, stated plainly. INFRO's controls govern traffic that goes through INFRO. A provider key stolen from anywhere, including from a platform that stores provider keys as INFRO does, can be used directly against the provider and bypasses every INFRO budget, allowlist and alert. For that case the evidence is in the provider's usage data. On the Business plan, INFRO's reconciliation with usage access on reads your provider's daily token counts per provider key and reports traffic that reached the account without going through INFRO; without usage access it reports "not checked", never "no bypass". Your backstops remain provider-side: scoped keys, provider spend limits, revocation at the provider, and the provider's own usage reports.
Summary
Abuse of an AI key shows up per key: a key that should be idle, a model you never call, a day without a night, output out of proportion to input, and new keys you did not create. Check per-key usage at the provider first, revoke at the provider, and set the controls in advance (scoped keys, IP allowlists, spend caps) that make the next incident smaller and easier to see.