Guide · 2026-09-08 · 8 min read

Hackers Are Stealing Claude Tokens: How to Protect Your AI API Keys and Sessions

Attackers are draining Claude subscriber accounts through stolen API keys and hijacked browser session cookies. Here's the two-front defense — spending limits, short-lived tokens, AI gateways, and endpoint hygiene — that keeps your AI budget yours.

TL;DR

  • Hackers are stealing Claude tokens from subscribers, as TechCrunch reported — turning your AI subscription or API credits into their free compute.
  • Token theft has two fronts: inference theft (stolen API keys and credits) and account token theft (stolen browser session cookies).
  • The fix is layered: strict spending limits, per-request verification, short-lived credentials, an AI gateway, and basic endpoint hygiene against infostealer malware.
  • A stolen key with no spending cap is a blank check. A stolen session cookie skips your password entirely. Defend both.

Claude

Anthropic

1. What Actually Happened

Attackers are targeting Claude subscribers and reselling or abusing their access. The economics are obvious: frontier model inference is expensive, so a compromised account is free compute for spam farms, phishing content generators, and grey-market API resellers.

The important detail for defenders is *how* they get in. This is not one attack — it is two distinct theft patterns that need two distinct defenses:

Protecting your AI tokens from hackers requires securing both your API keys/credits (inference theft) and your browser session cookies (account token theft). Locking down one while ignoring the other leaves the door open.

2. Set Strict Usage and Spending Limits

The single highest-leverage defense: make a stolen credential worth very little.

  • Implement strict alerts. Configure hard budget caps and alerts on your AI provider accounts so unusual usage spikes surface immediately — not on next month's invoice. A key that stops working at $50 of anomalous spend is a failed heist.
  • Verify every request. Require authentication and validation checks on every individual API request rather than trusting a single login session. Session-level trust is exactly what cookie thieves exploit.

If you only do one thing after reading this, set the spending cap. Every hour an uncapped stolen key runs is money you don't get back.

3. Upgrade Token Management

Long-lived credentials are the attacker's best friend. Shrink the window of exposure:

  • Ban long-lived credentials. Avoid long-lived personal API keys or access tokens entirely. A key that lives for a year is a year-long liability.
  • Use short-lived tokens. Migrate to short-term bearer credentials and rotate your keys regularly. If a leak happens, the credential expires before it can be monetized.
  • Deploy an AI gateway. Route your large language model traffic through an AI Gateway combined with machine authentication. This gives you a single choke point to monitor usage anomalies in real time — a sudden burst of requests from an unfamiliar ASN at 3 a.m. should page someone.

A gateway also centralizes key custody: developers stop pasting raw provider keys into local .env files, which is where a huge share of leaks originate.

4. Defend Against Browser Session Theft

This is the front most teams forget. Consumer AI accounts — Claude, ChatGPT — are compromised not through passwords but through stolen session state.

  • Watch out for infostealers. Hackers bypass passwords by stealing active browser session cookies that keep you logged into consumer AI platforms. Infostealer malware harvests these cookies in bulk and sells them by the thousand.
  • Log out when idle. Regularly log out of AI accounts and services when you are not actively using them. A dead session is an unstealable session.
  • Secure your endpoint. Keep your operating system and web browser fully updated, and avoid clicking suspicious links or downloading unverified software that might carry session-stealing malware.

Note what this means: enabling MFA is necessary but not sufficient. Session cookies are post-authentication artifacts — the attacker rides a session that already passed MFA.

5. The Cost Angle: Why Token Theft Is a Budget Problem

We track AI pricing for a living, and here's the uncomfortable math: at frontier output prices, a stolen key running flat-out can burn hundreds of dollars per day. Attackers don't optimize prompts, don't cache, and don't batch — they run the most expensive model at maximum concurrency because it's not their money.

The tell in your usage dashboard is rarely a slow leak. It's a vertical line. That's why the combination of hard caps + real-time anomaly detection beats after-the-fact reconciliation every time.

6. Quick-Reference Checklist

Related Reading

Last updated: · Source: Pricing dataset · Methodology

Frequently asked questions

How are token costs calculated?

Multiply input tokens by the input rate and output tokens by the output rate, add the two amounts and divide by 1,000,000. A standard request example uses 1,000 input and 500 output tokens. Monthly budgets multiply the result by request volume; taxes, hidden reasoning tokens, tools and tier surcharges can add costs.

Which recorded model has the lowest request cost?

LFM 2.2 6b by Liquid AI costs $0.00002 for the standard request, with $0.01 input and $0.02 output per million tokens. This price ranking does not establish quality equivalence; verify task success and context requirements.

Can cached and batch discounts be combined?

Only recorded rates are used. Cached input can have cache-write or storage charges, while batch rates apply only to eligible asynchronous jobs. We do not automatically stack the discounts or treat an absent rate as zero. Check the linked provider source before budgeting.

How current is the public dataset?

The live pricing table synchronizes stored model records daily; public file snapshots update when the site is rebuilt. Synchronization is not independent provider verification. It contains 1,026 priced models across 124 providers, last updated 2026-10-31. Directory entries are counted separately. A synchronization date is not proof of independent verification.