Stolen AI Keys and Agent Breaches: What Your IAM Misses

By Lazar Milicevic · Published October 24, 2026 · 9 min read

If you run a small business with an agent in production, you probably have a Claude or OpenAI key sitting in a .env file, a Zapier connection, or a teammate's browser profile. Treat that key like a bank login: someone is already selling stolen ones on Telegram with 24/7 support. This post walks through what the research shows, how two different incidents have been blurred together, and the concrete controls that matter for a team of 1-10.

Two incidents, one headline: separate them first

The headline circulating about "395 organizations" mixes two unrelated events, and the controls differ for each. The 395 figure comes from a GreyNoise report on an AI-orchestrated campaign against PaperCut NG/MF. The stolen-AI-credential marketplace comes from Okta's analysis of an infostealer dump. The Cloud Security Alliance notes that Okta's analysis does not attribute a specific breach to this dump.

Here is the clean split:

Why this matters for you: if you read only the headline, you might conclude that "AI credentials got 395 companies breached." That is not what the sources say. The accurate reading is more useful. Attackers are now using agents to operate at machine speed, and separately, AI credentials have become a commodity that is stolen and resold. Both stress the same weak spot, which is identities that no human is watching.

What the Okta research found about stolen AI credentials

Okta analyzed a 7 GB infostealer dump released on a Telegram channel on August 2, 2026. It held 5,871 folders, each representing one infected machine, spread across 162 countries (Okta, Okta newsroom).

The numbers worth knowing:

• 44,791 unique JWTs in the dump, of which Okta identified 555 as likely related to AI-service authentication.
• 2,937 JWE structures. On release day the dump contained 1,843 unexpired JWTs and JWEs.
• 17.7% of the JWTs contained plaintext PII such as name, phone number, or email (The Hacker News).
• 24 still-valid API keys spanning Google Gemini, OpenAI, Groq, and OpenRouter, per the Cloud Security Alliance's summary (CSA).

The key concept is replay. Jeremy Kirk, Okta's director of threat intelligence, put it this way: once a stolen session token or key is replayed, the attacker is logged in to an LLM service "without actually logging in." That is why stolen tokens bypass credential-based authentication, MFA included (The Hacker News).

Your password and your second factor were verified once, at login. The token is proof that verification already happened. Whoever holds the token inherits the session.

The storefront: Telegram vendors selling Claude access

The resale side looks like a normal SaaS shop. The listings Okta flagged offered discounted access to Claude, Cursor, ChatGPT, and Gemini, with 24/7 support and money-back guarantees (Gizmodo). One vendor calling itself "Poison Claude" advertised discounted access to Anthropic's Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6. Okta flagged that listing on September 9 (VentureBeat).

Buyers replay stolen sessions using anti-detect browsers such as Camoufox and automation tools such as SeleniumBase, which load stolen session data and sidestep security controls (same VentureBeat source).

What the verified facts support is the business model: stolen access, resold at a discount, with customer service. Your stolen key is someone's inventory.

The cost lands on you. On August 30, 2026, Anthropic began notifying Claude users that common infostealer malware was stealing Claude login sessions and consuming their usage. It signed affected users out, removed saved payment methods, and refunded charges it identified as unauthorized (Malwarebytes). The notification named six infostealer families: Vidar, LummaC2, StealC, RedLine, and Acreed on Windows, plus Atomic Stealer on a small number of Macs (Security Affairs). The sources I reviewed do not say how many users were affected.

The other half: agents attacking at machine speed

The PaperCut campaign shows why unwatched identities are dangerous even when no AI credential was stolen. GreyNoise reported that hundreds of AI agents, built on OpenAI's Codex harness with a DeepSeek model, compromised at least 440 instances hosted by 395 identified victim organizations in 48 countries (GreyNoise).

The timeline, per BleepingComputer's coverage of the GreyNoise report (BleepingComputer):

• The campaign began August 31, 2026 and exploited CVE-2026-81578 and CVE-2026-82078.
• The adversary went from an empty workspace to remote code execution against a real victim in just under four hours, and reached first domain admin about two hours later.
• Once the full campaign launched, it compromised at least 11 organizations in 26 seconds.
• Credentials were harvested from 280 victims, OS or domain secrets were obtained from 147, and administrator privileges were gained at 12 organizations.
• In every successful compromise, the attackers used DCSync to obtain a complete NTDS.DIT dump of domain credentials.

Education was the most affected sector, with 204 victims. That is roughly half of the total, depending on whether you count compromised instances (440) or victim organizations (395). The United States had the most victims by country, at 98 (WION).

Notice the pattern. The exploit gets the foothold; the credentials are the real prize. Every step after initial access is about turning one machine into identities that can do more. An agent working at this speed leaves a human responder no time to notice, which pushes the defense toward things that are true before the attack starts: scoped credentials, spend caps, and limited blast radius.

Why your IAM policy treats these as human, and why that fails

Most small-business access setups were designed around a person who logs in, passes MFA, and works for a few hours. Agents and API keys break every one of those assumptions.

The adoption gap is real too. VentureBeat's reporting suggests that only a small share of enterprises have a dedicated agent-identity product, such as Okta for AI Agents or Microsoft Entra Agent ID. Check the original VentureBeat piece for the exact figure and date, and treat it as indicative. If large enterprises are mostly missing this layer, small teams almost certainly are.

The practical takeaway: you cannot fix this by adding MFA. You fix it by shrinking what a stolen key can do and how long it stays valid.

A hardening checklist you can finish this week

Okta's recommended controls are: usage caps and IP allowlisting on API keys, no plaintext API keys in config files or environment variables, short-lived OAuth 2.0 access tokens, and Device-Bound Session Credentials where supported (Okta). Here is how to turn that into work for a small team, in priority order.

1. Inventory every AI credential. You cannot rotate what you cannot list. Search your repos, .env files, no-code connections, and shared password managers.

# Quick local sweep for likely AI keys in a project directory
grep -rIn --exclude-dir={.git,node_modules,.venv} \
  -E "(sk-ant-|sk-[A-Za-z0-9]{20,}|OPENAI_API_KEY|ANTHROPIC_API_KEY|OPENROUTER_API_KEY|GROQ_API_KEY)" .

This catches obvious cases, not everything. Run a proper secret scanner in CI for anything you ship.

2. Set hard spend limits at the provider. A stolen key's damage is bounded by its budget. Check each provider's current console for monthly caps and usage alerts. Configure them, because defaults are rarely tight.

3. One key per workload, never shared. Your invoice agent, your email triage agent, and your dev laptop should each have their own key. When one leaks, you revoke one thing.

4. Get keys out of plaintext. Move them from .env files into a secrets manager and inject at runtime.

import os
import requests

def get_secret(name: str) -> str:
    # Pull from your secrets manager at runtime; fail loudly if missing.
    # Replace this with your provider's SDK (AWS Secrets Manager,
    # 1Password CLI, Doppler, etc.). Do not fall back to a hardcoded value.
    value = os.environ.get(name)
    if not value:
        raise RuntimeError(f"Secret {name} not provisioned for this workload")
    return value

# Short-lived, scoped credentials beat one forever-key:
# request a token per job, let it expire, never write it to disk.

The pattern matters more than the vendor: the key exists in memory for the job's lifetime and nowhere else. Infostealers harvest files and browser stores, so a secret that never lands on disk gives them less to take.

5. Allowlist source IPs where the provider supports it. If your agents run from a fixed server, a stolen key replayed from an anti-detect browser elsewhere should fail.

6. Prefer short-lived tokens. Where a service supports OAuth 2.0 access tokens, use them over static keys. A token that dies in an hour is a much worse product for a Telegram reseller.

7. Treat the endpoint as the real perimeter. The six stealer families Anthropic named run on ordinary Windows and Mac machines. Keep browsers and OS patched, don't let agent keys live in browser sessions on daily-driver laptops, and separate the machine that runs agents from the one you use for general browsing.

8. Plan for the bad day. Write down, in one page, how to revoke each key, who does it, and where billing alerts go. Rotating under pressure without a runbook is how mistakes get made.

Detecting abuse before the invoice does

Prevention fails sometimes, so you need a cheap signal that fires early. For a small team, the most reliable one is spend and volume against a baseline you already know.

# Illustrative alert rules (example thresholds, tune to your workload)
alerts:
  - name: ai-spend-spike
    condition: daily_spend > 3x trailing_7_day_average
    action: page_owner
  - name: off-hours-usage
    condition: requests_outside_business_hours > 0 AND workload == "invoice-agent"
    action: page_owner_and_disable_key
  - name: new-source-ip
    condition: request_ip not in allowlist
    action: block_and_alert

The thresholds above are examples, not benchmarks. The point is to encode what "normal" looks like for each agent. An invoice agent that only runs weekday mornings should trip an alarm at 3 a.m. Your provider's console usage dashboard plus a billing alert will cover most of this without building anything custom.

Anthropic's own response is instructive: it signed affected users out, removed saved payment methods, and refunded unauthorized charges. That helps if you are a direct customer on a consumer plan. It is not a plan. If your agent runs on an API key with a payment method attached, assume you are responsible for noticing the burn.

My own take on this

My advice for any production agent: give each workload its own scoped credential, inject secrets at runtime instead of leaving them in config files, set provider-side spend caps, and tie an alert to each agent's expected behavior. Write the revoke-and-rotate steps down ahead of time, so nobody is improvising on the day a key leaks.

To review your own setup, a good starting point is to list the credentials your agents hold, map who and what can use them, and rank the fixes by blast radius.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.