[Billing] API key stolen and abused twice in 12 days (LLMjacking); spending limit exceeded by 29%; refund denied via template responses without case review

Status Open
Maintainer reply None cached
Activity 2 comments · opened Sep 22, 2026

Summary

My Console organization (ID 581b4a01-fb0d-4b60-b448-0864694b88f5) suffered two API-key fraud incidents in 12 days (Sep 9 and Sep 20-21, 2026), with the classic LLMjacking fingerprint that Anthropic's own Threat Intelligence Report documents. Support denied the refund with template responses that demonstrably did not review the case, and declared the decision "final" while declining to check the origin IPs of the fraudulent requests — data only Anthropic can see.

Timeline and evidence (all verifiable in Anthropic's own logs)

  • Key n8n-producao-2026-09 was created Sep 9 as the rotation after the FIRST fraud incident.
  • Sep 10-19: legitimate usage only — claude-haiku-4-5 and claude-sonnet-5 automation traffic, ~US$2-3/day.
  • Sep 20: a single tiny probe request on claude-fable-5-1 (a model I have never used on this key).
  • Sep 21, 10:00-11:00 UTC: burst of ~12.8M input tokens on claude-fable-5-1 plus ~1.3M input / 287k OUTPUT tokens on claude-opus-5. Individual requests of 180k-364k input tokens, streaming, no user_id.
  • The burst triggered three auto-recharge charges to my card in one morning (US$48.04 + US$19.43 + US$16.41 = US$83.88) and total consumption reached US$194.96 — against a configured monthly spending limit of US$150 (129%).
  • I detected it the same morning, disabled the key myself, and all abnormal traffic stopped instantly.

Customer-side forensics (all clean, all documented)

  • Git history of every repository (public and private) scanned: the key was never committed anywhere.
  • Reverse-proxy access logs reviewed: all logins/API access to my automation platform in the window came from my own residential IP.
  • Panels behind HTTPS, host firewall, 2FA, rotated passwords. Key stored only in server-side env vars.
  • Workstation fully scanned for malware: clean.

Support failure

  1. First reply claimed my auto-recharge "is still enabled" — it had already been disabled by me before that reply. The case was answered without actually checking the account.
  2. Second reply addressed a completely different scenario ("email account compromise", "plan upgrade refund") — my case is Console API key fraud; no account login was ever involved.
  3. Request to compare the origin IPs/ASN of the Sep 20-21 fable/opus requests against my legitimate traffic was ignored in every reply.
  4. Precedent exists: the Sep 9 incident with the identical Opus 5 + Fable fingerprint on this same org received a partial credit. The "credits are non-refundable" argument was not applied then.
  5. Case closed as "final decision" with a note that further replies "may not be monitored".

What I'm asking

  1. A human review of the case with verification of the origin IPs of the flagged requests.
  2. Refund of the fraudulent consumption (~US$85-90) and of the ~US$45 consumed beyond the configured spending limit.
  3. Product-level: spending limits that hard-stop at the cap; per-key model restrictions; per-key IP allowlists; anomaly alerts. A key whose entire history is small Haiku/Sonnet calls suddenly pushing millions of Fable/Opus tokens per hour is trivially detectable.

I am a paying customer in Brazil whose entire operation runs on Claude. I did everything right, twice, and documented all of it. Happy to provide the full forensic timeline to anyone at Anthropic who will actually look at it.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗