Home / Resources / Security

Security · 5 min read · Updated 2026-11-03

Stolen AI API keys are paying for hackers' autonomous scans

A criminal forum seller is renting out an autonomous penetration-testing agent that runs on stolen OpenAI, Anthropic and Google keys, so the victim's own account pays for the attack. Bitsight's forum data shows this is a trend, not a one-off listing.

On a restricted criminal forum, a seller is marketing MONST3R-AI, described as an autonomous penetration-testing platform. The buyer supplies stolen OpenAI, Anthropic or Google API keys, sets a spending cap, and hands over a target list. The seller hosts no model at all; the compute and the bill belong to whoever the key was stolen from (Help Net Security, 16 October 2026, reporting Bitsight threat intelligence research). The seller claims 1,072 findings across 199 scanned hosts. Bitsight has not verified that figure, but the business model behind it does not depend on the number being true.

Why this is not an isolated listing

Bitsight's team tracked thousands of posts across 16 underground forums from February through August 2026, and the pattern around that one listing shows up across the whole dataset, not just in it.

Mentions of AI agents, indirect prompt injection and the Model Context Protocol rose 67 percent over that seven-month window (Bitsight, via Help Net Security, 16 October 2026). Jailbreaking discussion grew by roughly three quarters over the same period, and interest in open-weights models such as GLM and DeepSeek climbed sharply as forum members began ranking models openly by how readily they comply with harmful requests, with some stripping safety behaviour out themselves through a technique the research calls abliteration. One reseller, CloseRouter, was advertising GLM access at $0.053 per million input tokens against $1.12 on the official API, which is the kind of margin that explains why criminal supply chains form around leaked or discounted model access in the first place.

The same period produced a concrete campaign, not just forum chatter. Water Kurita's FakeGit operation seeded roughly 7,600 fraudulent GitHub repositories to spread SmartLoader malware, and more than 800 of them posed specifically as AI skills or MCP servers, including a lookalike "Docker MCP Gateway" (Bitsight, via Help Net Security, 16 October 2026). A developer who trusts the wrong MCP server is not making a judgement error comparable to clicking a phishing link; they are handing a tool permission to act inside their own environment.

Separately, Reco's State of Agent Security 2026 (26 August 2026), built from anonymised enterprise telemetry and analysis of 500 public Model Context Protocol servers, found 80 percent of AI tools inside organisations running with no oversight at all, and, in smaller organisations, 414 unsanctioned AI tools per 1,000 employees. Two unrelated research teams, looking at different ends of the same supply chain, reach the same conclusion: the agent and MCP ecosystem is growing faster than anyone's visibility into it.

What it means for a regulated enterprise

An API key is not a password an employee memorised. It is usually embedded in code, a CI pipeline, a notebook, or a browser extension, and it often carries no spending limit and no narrow scope by default. When one leaks, through a committed secret, a compromised laptop, or a malicious MCP server masquerading as a developer tool, the exposure is not "someone read a file." It is "someone now has a standing, billable credential that can run an autonomous agent against any target they choose, at your expense, under your account history."

That has direct consequences for regulated organisations. Under the EU AI Act's record-keeping obligations and under NIS2's expectation that cybersecurity risk management is a management responsibility, "we didn't notice our key was being used" is not a defensible answer once an incident is under review. An AI provider key sitting in a repository or a service account is exactly the kind of credential an access review under ISO 27001 or a SOC 2 control mapping is supposed to enumerate. Bitsight's own advice is blunt: treat an exposed AI provider key with the same seriousness as an exposed AWS credential, because the blast radius is comparable and the detection tooling most organisations already run for one does not cover the other.

What actually addresses it

The mechanism that closes this gap is narrow, revocable, identity-bound credentials, not broader awareness training. A key that is scoped to one agent, one purpose and one spending ceiling, and that can be revoked the moment its behaviour looks wrong, turns a stolen credential into a dead end rather than a standing liability. The same logic applies to MCP servers and agent plugins: Bitsight's recommendation to verify the source of every one before connecting it is a supply-chain control, equivalent to verifying a package before it enters a build.

What to check on Monday

Pull the list of every AI provider API key your organisation holds, OpenAI, Anthropic, Google or otherwise, and ask three questions of each one: does it have a spending cap, is it scoped to a single service or agent rather than shared across several, and could you revoke it in under a minute without breaking something else. Then check your source code and CI logs for any of those keys committed in plaintext, the same scan you would already run for cloud credentials. Finally, list every MCP server and agent plugin currently connected to a developer machine or a coding agent, and confirm each one's source against its publisher, not just its name, given that FakeGit's lookalike MCP gateway shows exactly how that trust gets exploited.

How AANCER answers

AANCER issues identity to agents rather than letting them inherit a shared provider key. Each Certified Agent gets a scoped passport from your own per-install certificate authority, naming the tools, data and spend it may reach, so a leaked credential cannot be repurposed to run an unrelated scan against unrelated targets.

Revocation takes effect in under 30 seconds, without redeploying the agent or taking down the systems it talks to, which matters precisely when a key's behaviour starts to look like someone else's autonomous tool rather than your own workload.

Every credential use is written to an append-only, tamper evident audit ledger, so when a security team asks which key did what, against which system, and when, the answer is a log to read rather than a policy to trust.

Sources

  • https://www.helpnetsecurity.com/2026/10/16/stolen-ai-api-keys-autonomous-scans/
  • Reco, State of Agent Security 2026, 26 August 2026

Related guides

Compliance

The EU AI Act Article 12 readiness guide

What record-keeping and human-oversight obligations actually require operationally from August 2026 — and the evidence an auditor will ask you to produce.

9 min read

Read the guide →

Risk

The credentials nobody reviews

Your AI agents hold OAuth tokens, API keys and service accounts that went through no approval process. The agent was reviewed. The studio was reviewed. The identity behind them was not.

5 min read

Read the guide →

Security

When the agents organised themselves: what the Hugging Face swarm means for accountability

Roughly 700 AI agents divided labour, traded favours and compromised production infrastructure across four regions. The uncomfortable part is not that it happened — it is that the account of what happened had to be reconstructed afterwards, by outside parties.

6 min read

Read the analysis →