# Signs your AI API key is being abused, and what to check

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

> Signs an AI API key is being abused: usage on a key that should be idle, models your code never calls, flat round-the-clock traffic with no quiet hours, a jump in output or reasoning tokens relative to input, batch or cache patterns you do not use, new keys you did not create, and spend that departs from your usual day. Check per-key usage first (OpenAI's Usage API grouped by api_key_id, Anthropic's Usage page or Usage API filtered by key, Google's AI Studio usage and Cloud Billing reports by SKU), then revoke at the provider.

Key takeaways:
- Look per key, not per account: abuse hides in an account total and stands out on the one key that should be quiet.
- The strongest single signal is usage on a key that should be idle; the next is a model your code never calls.
- CISA's distillation advisory lists round-the-clock usage, many IPs on one account and new accounts at full usage at once; applying them to your own keys is an inference, not the advisory's guidance.
- Provider usage reports rarely show the caller's IP, so preventive controls (IP allowlists, scoped keys, provider spend limits) matter more than after-the-fact forensics.
- A gateway sees only traffic sent through it: a stolen provider key used directly is visible only in the provider's own usage data.

**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](https://infro.io/blog/leaked-openai-api-key) and [a leaked Anthropic key](https://infro.io/blog/leaked-anthropic-api-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](https://infro.io/blog/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 usage[1]. 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 usage[2]. [Reasoning tokens and cost](https://infro.io/blog/reasoning-tokens-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 indicator[1].

### 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 on[3].

### 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](https://infro.io/blog/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 restrictions[4]. Make sure those emails reach someone: Google recommends adding Essential Contacts for security, technical and suspension notices[4]. [What to do when a provider suspends your account](https://infro.io/blog/ai-provider-account-suspended-abuse) 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 UTC[2] | Usage API: `api_key_ids` filter and `group_by=api_key_id`, also model, project, batch, service tier[5] | 1 minute, 1 hour or 1 day buckets[5] |
| Anthropic | Console Usage and Cost pages[6] | 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 minutes[6] |
| Google (Gemini API) | AI Studio usage and cost dashboards, filterable by project, model and time frame[7] | Cloud Billing reports grouped by project or SKU, with date grouping for daily detail[8] | Daily in billing reports |

Two details trip people up. OpenAI's dashboard has its own project selector, and clearing it shows the whole organization[2]; 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 id[6], so null rows are not by themselves suspicious.

### What to check first at OpenAI

1. Open the Usage Dashboard, clear the project filter, and pick a range that starts before the suspected window[2].
2. Pull usage grouped by `api_key_id` and `model` with one-hour buckets from the Usage API (an Admin key is needed)[5]. Look for keys and models you do not recognize.
3. Check the audit log for API keys, service accounts and invitations created in the window[3].
4. 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 webform[9].

### What to check first at Anthropic

1. Open the Console's Usage page and Cost page for the window[6].
2. With an Admin API key, query the Usage API filtered or grouped by API key and workspace, in hourly buckets[6]. A workspace per workload makes this readable.
3. Compare the service tier and cache columns with what your code uses: batch, priority, cache reads and cache creation each appear separately[6].

### What to check first at Google

1. In AI Studio, open the usage and cost dashboards for each project and filter by model[7].
2. In Cloud Billing reports, group by SKU and by date to see which Gemini SKUs grew and on which day[8]. Viewing every linked project needs a billing account role such as Billing Account Viewer[8].
3. Check the project owner's email and the Essential Contacts for abuse or compromised-key notices[4].

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

> **Example: Reading one key's day**
> A team has three OpenAI keys: production chat, nightly evaluations, and a staging key. Grouped by key and model in hourly buckets, production follows the working day, evaluations run for two hours after midnight, and staging is near zero. One morning the staging key shows a steady rate for the past 20 hours, almost all on the most capable model, with output tokens per request several times production's. The account total rose only by a fraction; the staging key's line is the incident. The team revokes it at OpenAI, then checks the audit log for keys created in the same window.

## 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](https://infro.io/blog/ai-api-key-theft-bill-refund) and [LLM incident response](https://infro.io/blog/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 `401` and `ip_not_authorized` even with a valid key[10]. OpenAI is clear that this reduces risk but does not prevent all misuse[10].
- **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 responsibility[7]. [Provider spend limits compared](https://infro.io/blog/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](https://infro.io/blog/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](https://infro.io/docs/observability/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](https://infro.io/docs/org/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](https://infro.io/docs/cost/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.

## Questions

### How do I know if my OpenAI API key has been compromised?

Group your organization's usage by API key (the Usage API accepts group_by=api_key_id) and look for activity on a key that should be quiet, models your code does not call, and usage at hours your traffic never runs. Check the audit log for keys you did not create. If anything is unexplained, revoke the key, then use OpenAI's unauthorized activity form.

### Can I see which IP address used my API key?

Generally not from the provider's usage reports, which group by key, project, model and time. A gateway or your own application logs record the caller's address for traffic that passes through them. That is why restricting a key to known IP ranges in advance is more useful than trying to trace a thief afterwards.

### Does high usage at night mean my key was stolen?

Not on its own: batch jobs, scheduled evaluations and users in other time zones all run at night. It matters when a key whose workload follows business hours suddenly runs flat around the clock, which is one of the patterns CISA's distillation advisory lists for abusive accounts.

### What should I do first if I see signs of abuse?

Revoke or disable the key at the provider, not only in a gateway or secrets manager, because a stolen provider key works directly against the provider. Then lower the provider-side spend limit, review the audit log for new keys or members, and report the activity to the provider with the dates and amounts.

## Sources

1. China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies (AA26-251A) — CISA, NSA and FBI. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-251a (accessed 2026-10-21)
2. Reviewing API usage and costs — OpenAI Help Center. https://help.openai.com/en/articles/10478918-api-usage-dashboard (accessed 2026-10-21)
3. Admin and Audit Logs API for the API Platform — OpenAI Help Center. https://help.openai.com/en/articles/9687866-admin-and-audit-logs-api-for-the-api-platform (accessed 2026-10-21)
4. Respond to abuse notifications and warnings in Google Cloud — Google Cloud. https://docs.cloud.google.com/docs/security/respond-to-abuse-misuse (accessed 2026-10-21)
5. Completions usage (API reference) — OpenAI. https://developers.openai.com/api/reference/python/resources/admin/subresources/organization/subresources/usage/methods/completions (accessed 2026-10-21)
6. Usage and Cost API — Anthropic. https://platform.claude.com/docs/en/api/usage-cost-api (accessed 2026-10-21)
7. Giving you more transparency and control over your Gemini API costs — Google. https://blog.google/innovation-and-ai/technology/developers-tools/more-control-over-gemini-api-costs/ (accessed 2026-10-21)
8. Analyze billing data and cost trends with Reports — Google Cloud. https://docs.cloud.google.com/billing/docs/how-to/reports (accessed 2026-10-21)
9. I'm seeing unrecognized activity on my OpenAI account — OpenAI Help Center. https://help.openai.com/en/articles/8485685-im-seeing-unrecognized-activity-on-my-openai-account (accessed 2026-10-21)
10. IP allowlisting for OpenAI API — OpenAI Help Center. https://help.openai.com/en/articles/20001201-ip-allowlisting-for-openai-api (accessed 2026-10-21)