What is AI abuse? A guide for inference operators
AI abuse is the use of AI systems or access in ways that are harmful, unauthorized, or prohibited by an applicable policy. In inference services, examples include stolen API-key use, prohibited credential sharing, repeated claims of restricted credits, and unauthorized model extraction. Heavy usage, automation, and legitimate distillation are not automatically abuse.
What counts as AI abuse in an API or gateway?
This guide focuses on misuse of inference access. Harmful generated content, prompt injection, and training-data poisoning need additional controls and evidence. Treating all of those problems as one category makes it difficult to decide who should investigate or what a finding means.
| Suspected problem | Evidence to collect | Common alternative explanation |
|---|---|---|
| Stolen or shared credentials | Credential lifecycle, workload ownership, request timeline, observed networks | An approved shared service or regional deployment |
| Unauthorized resale | Delegation records, account terms, downstream reconciliation | An authorized gateway or reseller |
| Repeated free-tier claims | Entitlement history and coordinated account activity | Several legitimate users on one corporate network |
| Suspected model extraction | Account coordination, usage history, permitted-use records | An authorized benchmark or evaluation job |
| Unexpected inference cost | Tokens, model mix, retries, job and deployment history | A software defect rather than adversarial use |
How can I tell whether my AI service is being abused?
Collect UTC timestamps, pseudonymous credential identifiers, request identifiers, model selection, token counts, outcomes, and recorded cost. Add trustworthy workload and network identifiers where available. Keep issuance, revocation, scope, and ownership records separately so the investigator can establish what was authorized at each point.
Do not copy raw credentials, authorization headers, prompts, or responses into a general investigation export. Record missing fields explicitly. A provider that sees only a gateway's upstream credential may be unable to distinguish downstream users without cooperation from the gateway.
Is an expensive AI bill evidence of abuse?
No. Growth, retries, or a changed model can increase cost without unauthorized use. Start with the bill-spike checklist. Compare each credential against its own workload history. A new observed network, a changed model mix, and simultaneous unfamiliar traffic can justify investigation. Each observation also needs an operational explanation check: deployment, failover, batch processing, or an approved new customer.
Synthetic example: a key's hourly request count doubles when an evaluation job starts. All additional requests reconcile to that job. The change is explained authorized activity. If the extra requests cannot be reconciled, the case remains unresolved; the missing explanation is not proof of theft.
What should I do if I suspect AI abuse?
- For confirmed exposure or ongoing unauthorized access, use the incident procedure to contain the affected credential promptly.
- For an unexplained change, identify the owner and preserve the relevant metadata while checking operational context.
- Where temporary limits are appropriate, scope them to the affected principal and record the rollback conditions.
- After a decision, retain the evidence and explanation so the same legitimate workload does not repeatedly trigger investigations.
Measure investigation quality
Track reviewed cases, confirmed unauthorized use, explained legitimate activity, unresolved cases, and time to a useful decision. Separate the cost of traffic under review from confirmed unauthorized cost. Report how many events lack identity or usage fields; a quiet detector with poor coverage is not evidence that abuse is absent.
Continue with a specific investigation
- Investigate LLM API key abuse
- Investigate token theft and unauthorized resale
- Understand model extraction and distillation defenses
- Plan gateway security logging
For the broader application-security scope, see OWASP's LLM application security project. The workflow above is an investigation framework, not a claim of validated detection performance.