Two threat reports in one week. Stolen API keys are the loot.

Two threat reports landed in the same week. On 8 September 2026 Google's Threat Intelligence Group published From Prompting to Autonomy. Two days later Anthropic published its September 2026 misuse report. Different telemetry, different actors, same conclusion: stolen API keys are no longer a step on the way to the goal. They are the goal, and they are the tooling for whatever comes next.

That shift is worth taking literally, because it changes which inventory you should be looking at this week.

#What the two reports say

Google's report is about tempo. Its headline case is an actor who did not spend weeks building infrastructure and tuning an exploit. He wrote a prompt and a set of agent instructions, and the resulting system planned, built and executed a mass credential harvesting campaign in under six hours. Google notes the agents handled the scanning pipeline, troubleshooting and IP rotation without manual intervention, and routed traffic through victim cloud infrastructure so requests arrived from legitimate addresses.

The second Google case is about holdings rather than speed. A framework Google tracks as Recon kept more than 23,800 harvested secrets in a production dashboard, managed in real time, API keys for cloud and AI services among them. Google frames this as a move from endpoint-focused infostealers to what it calls offensive agentic harvesting: credentials collected continuously, validated and kept ready for use.

Anthropic's report covers nine months of activity and reads differently, but the credential thread runs through almost every case. In the one tracked as GTG-50020, a Russian-speaking actor used prompt injection against an AI vendor's automated evaluation sandbox and obtained production API keys from multiple providers. Anthropic states plainly that the keys came from customers' environments, not from Anthropic systems. With them, the actor moved against roughly thirty AI companies in about four days.

In a separate case attributed to affiliates of ShinyHunters, Anthropic describes one session-store dump that produced over 2,100 Azure AD token sets across more than 40 corporate tenants in about 34 hours, and a pipeline on ten cloud workers that pulled 1.8 million Android application packages to scan them for hardcoded secrets. The same group is described stealing AI API keys from enterprise software vendors and reusing them against other organisations for roughly three weeks.

#Anatomy of the path

eval-sandbox      # AI vendor's automated evaluation environment
  → prompt-injection # instructions carried in the evaluated content
  → api-keys         # production keys, several providers at once
  → agent-framework  # keys become compute for the next round
  → downstream-orgs  # roughly thirty AI companies in four days

Read that path twice and notice where the privilege sits. Nothing in it required a user password, an MFA prompt or a phishing email. The sandbox was doing its job. It ran untrusted content, and the content told it to hand over what it held.

Google's supply-chain section shows the same shape with different plumbing. It describes an actor it tracks as UNC6780 compromising developer accounts to publish trojanised forks, including packages named tiktoken_mcp and azure-functions-mcp-extension, and a stealer it calls DUSTMAKER that extracted OIDC tokens from GitHub Actions runners. Those tokens were then used to publish compromised packages carrying valid build attestations. The signature was real. The identity behind it had been borrowed.

A build token is a non-human identity with publish rights. Nobody reviews it, nobody rotates it, and its signature is trusted by everyone downstream.

#This is a reach problem, not a secrets problem

Most organisations already have a secrets policy: keys in a vault, nothing committed to Git, a rotation interval on paper. That answers where the key is stored. Neither report turns on that question. Both turn on a different one: what can this key reach, and who would notice if someone else used it.

An API key issued to a build system, an evaluation harness or an internal agent is a non-human identity. It has no owner in the directory, it does not appear in the quarterly access review, and the scope it was given was usually the scope that made the integration work on the first try. That is how a key meant to run tests ends up able to read production, and how a key meant for one provider account ends up usable against thirty companies.

The same structural gap produced the Salesloft Drift OAuth breach and the Nx s1ngularity attack. The credential type changes every few months. The failure does not: a machine identity held standing access well beyond its function, and nobody was measuring that reach.

#What the agents changed, and what they did not

It is worth being precise. Neither report describes a new technique. Prompt injection, token theft from CI runners, secret scanning of public artefacts and credential replay are all well documented. What the agents supplied is throughput and persistence: validation of thousands of harvested keys, continuous scheduled collection, and campaign state that survives between sessions. Anthropic describes one operation keeping persistent memory of target lists, harvested credentials and standing instructions across working sessions.

The consequence for defenders is narrow but real. Detection built on the assumption that a stolen credential is used clumsily, from an unusual address, in a short burst, is weaker than it was. Anthropic describes an actor validating and rotating stolen API keys through a local proxy layer specifically so the traffic matched the legitimate owner's. Google describes attack traffic routed through victim cloud infrastructure for the same reason. Volume anomalies still work. Origin anomalies work less well than they used to.

The other side of this is ordinary. Both reports describe keys found where basic hygiene would have covered them: hardcoded secrets in mobile packages, exposed keys in public containers, tokens readable by a CI job that did not need them. The agents made the searching cheap. They did not make the keys findable.

#What to check this week

1. List the keys your AI and build tooling holds. Evaluation harnesses, CI runners, agent frameworks, MCP servers, coding assistants. Start with anything that processes content you did not write, because that is the sandbox case.
2. Scope every provider key to one purpose. If a key used for test runs can also read production or create new keys, that is the finding. Provider consoles increasingly allow per-key scoping and per-key spend limits. Use both.
3. Check what your GitHub Actions OIDC tokens can do. Confirm which workflows can publish, that publish rights are limited to protected branches or tagged releases, and that pull requests from forks cannot reach a token with write scope.
4. Scan your own artefacts the way the harvesters do. Mobile packages, container images and published archives. TruffleHog and equivalents are the same tools described in both reports. Run them against what you ship.
5. Add a use-anomaly alert per key, not per user. Requests per hour, unusual model or endpoint, first use from a new region. Origin alone is no longer reliable, so alert on the shape of use.
6. Write down the reach of your five most privileged machine identities. Name the systems and the data each one can touch today. If nobody can answer that in an afternoon, that gap is the risk.
7. Practise the rotation. Pick one production key and rotate it this week. Most teams discover their real exposure at the moment they try, when it turns out four services share it.

Both reports describe attackers who treat machine credentials as inventory: collected continuously, validated, sorted and held ready. The defensive equivalent is knowing what each of those credentials can reach before someone else measures it. Elmoz maps the attack paths from agents and non-human identities to the data that matters.