AI SecurityThreat IntelligenceIncident Response
Imagine the email arriving on a Monday. A model provider's trust and safety team writes to say that an API key belonging to your organisation has spent the last several weeks doing reconnaissance against political parties, validating stolen credentials and writing exploit code. The key is suspended. They would like to understand your use case.
Your first instinct is that it wasn't you. Your second, if you are honest, is to wonder how you would prove that.
That scenario is not a thought experiment. It is a reasonable reading of one section of Anthropic's September 2026 threat intelligence report, which covers misuse of Claude that the company disrupted between December 2025 and August 2026. Most of the coverage has gone to the headline finding, that AI has closed the gap between state-backed teams and lone operators. The part worth taking back to your own estate is smaller and more awkward: a growing share of those operators were running on somebody else's account.
The report spans seven harm areas, from influence operations to weapons development. The Hacker News summarised the cyber cases on September 11. Running through several of them is a single theme: AI access has become something criminals steal for its own sake. Anthropic says compromised API keys, session tokens and devices have increasingly become "the sole objective of multiple criminal groups."
The cases that illustrate it:
| Case | Actor | What happened to AI credentials |
|---|---|---|
| GTG-50014 | ShinyHunters affiliates, financially motivated | Mass-downloaded 1.8 million Android APKs, decompiled them and scanned for hardcoded secrets. After compromising victims, moved their own attack workloads onto the victims' AI keys |
| GTG-50029 | A single French-speaking hacktivist | Built a Rust scanner to find and validate exposed API keys in public containers. The campaign ran for a month on stolen keys and gained internal access to at least 14 of 42 tracked targets |
| GTG-50020 | Russian-speaking, financially motivated | Compromised an AI vendor's evaluation sandbox to take production API keys from several providers, then attacked roughly thirty AI companies in about four days |
| GTG-50021 | Russian/Ukrainian-speaking fraudsters | Sold discounted "Claude" access that proxied traffic elsewhere while harvesting customers' Anthropic credentials |
Around those cases, the report describes fake installers impersonating AI coding tools, Claude Code among them, that collected every credential and session token on the device. It also describes several actors using prompt injection against AI wrapper services built on LiteLLM to pull production API keys out of their cloud containers. And it notes that fraudulent resellers are increasingly stocked with compromised access. We covered the reseller economy from the other direction on Saturday, in the US advisory on distillation through API transfer stations.
Anthropic breaks down what a stolen AI key is worth to an attacker in three words.
Loot. Keys and accounts resell in established markets.
Compute. The attack workload runs on someone else's quota and someone else's invoice.
Cover. The activity is attributed to the key's legitimate owner.
The first two are familiar from every cloud credential theft of the last decade. Stolen AWS keys have mined cryptocurrency on victims' bills for years, and we made the case earlier this month that AI infrastructure concentrates exactly these credentials.
The third is the new part, and it changes who carries the risk. When a stolen key mines cryptocurrency, the victim loses money. When a stolen key runs an intrusion campaign against a political party, the victim's name is the one in the provider's abuse records. From the provider's side, at least at first, the operator of that campaign is the organisation that owns the key.
The hacktivist case shows this was a design goal, not luck. According to the report, GTG-50029 rotated its stolen keys through a local proxy layer specifically so its traffic would blend in with the traffic of each key's real owner. The attacker's aim was to be statistically indistinguishable from you.
The same idea turned up in a different part of the threat landscape the same week. Arctic Wolf's reporting on PREY-0058, a Microsoft 365 data-theft and extortion cluster covered by The Hacker News on September 7, describes stolen sessions being replayed through residential proxies, including NodeMaven, from IP addresses in the same geographic location and on the same network provider as the victim. No endpoint malware, no lateral movement. Just the victim's own session, arriving from somewhere that looks like the victim's home.
Two unrelated operations, one SaaS identity and one AI API, landed on the same technique: don't hide the activity, make it look like the owner's. Detections built on where did this come from? are the ones that technique is designed to beat.
The report is unusually direct about the source. Most exposed keys, it says, come from legitimate customers who leaked them by accident in their own products and code: GitHub repositories, mobile app install files, Docker containers, websites and chatbots.
Every item on that list is something an organisation ships. That includes:
.env file committed once, removed in the next commit, and still sitting in git history.None of these involve a breach in the usual sense. The GTG-50014 pipeline did not break into anyone to get 1.8 million APKs. It downloaded them from app stores, the way everyone else does. And once a key is found, the report shows how quickly it gets used: another GTG-50014 compromise went from a single stolen developer token to full administrative control of a victim's cloud environment in roughly three hours.
Consider who is positioned to notice a stolen AI key being used.
The provider sees the traffic but not your intent. It knows the key made a hundred thousand calls. It does not know whether your product launched a feature that week, so a spike from a stranger and a spike from a launch can look much the same from where it sits.
Finance sees the invoice, monthly, usually as one line per provider. A campaign that runs for a month on a key with generous limits can finish before the first bill arrives.
The engineering team that owns the key often sees nothing at all. The legitimate application keeps working until the quota runs out, and then it starts logging rate-limit errors that look like a capacity problem, not a security incident.
The security team frequently does not know the key exists. AI keys get created in a provider console by whoever is building the feature, and they are rarely in the same inventory as cloud credentials.
That is why the cover value lasts. Nobody on the victim's side has an independent record of what the key was supposed to be doing. Without one, there is nothing to compare the provider's numbers against.
To be clear about the boundary first: Obiguard SOC does not connect to model providers' usage or billing APIs, it will not find a key inside a published APK, and it cannot revoke a credential. What it gives you is the thing that section above says most organisations lack: your own independent record of what your services actually did, so that a provider's usage figures have something to be checked against.
Traces give you your side of the ledger. SOC ingests distributed traces over standard OpenTelemetry. For services instrumented that way, outbound calls, including calls to a model provider, appear in traces, and the Service Map shows per-edge call volume, error rate and latency without anyone drawing it by hand. If the provider says a key made 400,000 calls last week and the service that owns the key made 40,000, the difference is the question you need to answer, and you only get to ask it if you have the second number.
Your own logs carry the first symptom. When someone else spends a key's quota, the legitimate application is often the first thing to notice, as a burst of rate-limit or quota errors that nobody on the team caused. SOC raises alerts from log-volume and rule matches without detection rules to write first. Each alert keeps an evidence timeline linked back to the raw log events that triggered it. So "our payments assistant started failing at 02:00" can go to a security analyst instead of dying in a capacity ticket.
Code review happens where keys leak. The report traces most exposed keys back to code, builds and containers that customers shipped themselves. SOC runs an automatic LLM code review on every commit to connected GitHub repositories. That is not a dedicated secrets scanner, but a provider key pasted into a config file or a mobile client is exactly the kind of issue a review on every push is there to surface, before it becomes an APK in someone else's download pipeline.
Pair that record with scoping on the key itself, which is what Governance AI and its allow-lists do. Then a key lifted from a container can only call the models and tools it was issued for, and every call it makes lands in the audit ledger under a named agent rather than an anonymous string.
For years the standard advice on API keys has been about confidentiality: don't commit them, don't log them, rotate them. All still true. But the report describes attackers who are no longer interested in keys as a means to an end. They want the key itself, because it comes with a stranger's quota and a stranger's reputation.
That shifts the question a security team needs to be able to answer. Not only could our key leak? but if our key had been running someone else's campaign since July, what in our own records would show it?
For most organisations the honest answer today is the invoice, which arrives monthly and says nothing about intent.
Explore Obiguard SOC or talk to us about building your own record of what your AI integrations actually did, before a provider sends you theirs.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →