There is probably a Make scenario running in your company right now. A colleague built it in March, because incoming messages needed sorting. The Claude key went into a field, the scenario worked, and nobody has opened it since. It still runs every night.
The key somebody pasted in back in March
On 10 September Anthropic published its threat intelligence report for September 2026. It collects the misuse Anthropic's own threat team detected and shut down between December 2025 and August 2026, across seven categories. Most of the report is about espionage and influence operations, and you read those as a spectator.
One section is different. In that one, the reader owns the thing that was stolen.
A Russian-speaking actor went after the AI vendors themselves. Anthropic writes that the actor attacked roughly thirty AI companies in about four days, and that its goal, pursued across more than a dozen avenues, was access to a Claude model that had not been released yet. Anthropic's own wording is that the actor never gained access and that every attempted path failed.
What the actor did walk away with was something else. Anthropic writes that throughout, the keys involved were customers' keys stolen from customers' environments, and that the actor never compromised Anthropic's own systems.
So the people who lost something were the people holding a key. That's why this report is about the March scenario.
What does an attacker actually use a stolen AI key for?
Anthropic splits the value of a stolen key three ways. I'm giving the categories as they stand in the report:
Loot. Stolen keys and accounts have resale value in established markets.
Compute. Holding the credentials means the attacker's own workloads run at someone else's expense.
Cover. The activity is attributed to the credential's legitimate owner.
Notice where the three of them land. The resale happens in a market you never see. The bill lands with you. And the third happens in a log you don't own, with your name on it.
Anthropic stops at the three categories. Only one of them leaves a trace where most companies are looking. The bill is the channel you expect to catch things on, and it reports the least serious of the three uses.
You can look as closely at an invoice as you like without seeing the other two. What moves the problem is a key that points at a person.
Your name is on the traffic
Cover is the hardest of the three to take seriously if you picture it as a reputation problem. Anthropic describes the pattern like this: the actor moved its own workloads onto the stolen keys, so the activity was attributed to the legitimate owner.
In the report, the victims are AI companies. Your key is the same kind of object, and that's why it's worth something to whoever gets hold of it. The consequence just looks different at the scale you work at.
A twelve-person company has no security team, and there's no trust page that needs updating. What happens is more ordinary than that. The traffic breaks Anthropic's own terms, and it is registered against your organisation. The organisation gets rate-limited or suspended. Then the March scenario stops on a Tuesday morning, the invoices don't go out, and the explanation sits in a log you neither own nor can read.
It's an operations problem long before it's a reputation problem. And it hits the small company harder than the large one, because there's no second route to send the invoices by.
There's a time budget in it too. In the same report Anthropic describes a breach that went from one stolen developer token to full administrative control of the victim's cloud environment in roughly three hours.
What does cheap Claude access cost?
There's one actor in the report where a small Danish company is the obvious victim rather than a bystander.
Anthropic describes a fraudulent reseller that sold discounted Claude access. The traffic was proxied to different models than the ones advertised, and credentials were harvested through malware the customers installed themselves.
Anthropic's own recommendation is in the report word for word: AI access should be purchased only through authorized channels. An alleged discount that requires routing traffic and credentials through an unknown intermediary introduces, in Anthropic's assessment, tremendous risk to user data and systems.
There's a second bill hidden in that, and it's easier to miss. If the traffic was proxied to a different model, then any evaluation run through that access was an evaluation of something other than what the label said. A team that trialled Claude on a discounted endpoint and concluded it didn't live up to the talk may have been measuring something else entirely.
The decision sits with whoever approves purchases. Find out who your AI invoice actually comes from, and whether anyone in the building holds access finance never bought.
Anthropic's own word for it is "No one"
The report doesn't mention it. It's in the Claude Platform documentation, and it shipped a fortnight before the report did.
Anthropic has three kinds of API key, and the docs set them out in a table with a column headed "Acts as": who the key acts on behalf of.
A personal key acts as you, with your roles and permissions. It's archived when you're removed from the organisation.
A service account key acts as a service account, and stops working when that account is archived.
Then there's the old type, the workspace key. In the "Acts as" column it says, word for word: "No one: it belongs to the workspace it was created in." The same table says it stops working only when it expires, is disabled or deleted, or when its workspace is archived, regardless of whether its creator leaves the organisation.
Anthropic writes that the first two are identity-backed: each belongs to a user or a service account the organisation already manages, and every request acts as that identity. Anthropic puts the significance this way, that keys won't accidentally outlive the people or workloads that own them. The recommendation is there too: prefer them over workspace keys for new integrations.
Be precise about what this fixes. An identity-backed key doesn't make Cover visible. It makes it attributable and revocable. That's a smaller thing than being able to watch it happen, and it's still the one that works.
A workspace key can be deleted, incidentally. Two clicks in the Console. The hard part is knowing what stops working the second it goes, which is why it stays where it is.
The gap between a person stopping and their key stopping is the entire control. Measured against those three hours, that gap is what decides how much gets done.
Anthropic's recommendation to organisations is short: they should treat AI keys and agent integrations with the same level of seriousness as they do production credentials. The reason, as Anthropic gives it, is that attackers treat them with exactly that seriousness.
The boundary for what Claude may do on its own has to be written in advance. An attacker holding your key works inside precisely the boundary you wrote.
The table that finds the keys
Build a list, one row per place a key lives, with four columns. The first row is filled in as an example, and the second is just as ordinary:
| Where the key lives | Who set it up | Personal, service account or workspace | Does it expire |
|---|---|---|---|
| The Make scenario, sorting incoming messages | Marketing, back in March | Workspace | No |
| The script on the old server | Don't know | Can't tell | Don't know |
Column two is a question you ask a colleague, not something you look up. The Console key list shows each key's expiration; it doesn't record who created it. If nobody claims a key, that isn't a mystery to solve. It's a key to replace.
Column three is the one that decides something, and it's also the hard one. The key string in the Make field tells you nothing: all three types look alike. The type is chosen when the key is created, in the Linked account field, so the Console key list under Settings and API keys is where you see which keys the organisation has and what each is tied to. If you can't match a key sitting in a tool to a row you can put a name against, that is the answer: a key nobody can attribute belongs on the list of keys to replace. Anthropic recommends personal and service account keys for new integrations anyway, so the outcome is the same either way.
Column four is allowed to end on never. Expiration is chosen when the key is created and can't be changed afterwards.
There's a step zero worth checking first: does anyone at your company have owner or admin access to the Console at all. In the company this article is about, the answer is sometimes the freelancer from two years ago.
Once the table is filled in you're holding two lists: keys to move onto an identity-backed key, and keys to rotate now. Anthropic has written the migration down in five steps:
- Decide the key type. Your own tooling takes a personal key; a shared or unattended integration takes a service account key.
- Have a service account created if you need one.
- Create the new key for the right workspace.
- Deploy it wherever the integration reads the key, usually
ANTHROPIC_API_KEYor an entry in a secrets manager. - Delete the old one once you've seen the calls go through.
Budget about half an hour per integration, if you can test it the same day. It isn't hard. It just has to be done one at a time, which is why it doesn't get done.
How I run an AI audit of your keys
You can build the table yourselves, and you should. What goes wrong is the migration: an integration that sends invoices has to change key without stopping sending invoices, and you usually find out the next day.
As an AI consultant in Copenhagen I run the AI audit of the access and move the integrations, alongside the Claude implementation work I already do for Danish companies, from the Claude integration itself to the internal AI tools that end up holding the keys. The order is the same as above: where the keys live, who they act on behalf of, and what stops working when we swap them out.
The other half is the one that matters over a year, and it's about AI implementation going forward: who inside the company owns the access once I've gone home. That question is what an external AI lead on subscription is the answer to, if nobody internally has their hand up. Write to me if you want the two lists walked through.
The actor in Anthropic's report went at more than a dozen avenues trying to reach a model that hadn't been released yet. Every path failed. That door held.
The key in the March scenario was never behind a door at all.
FAQ
Frequently asked questions
No. Anthropic writes that throughout, the keys involved were customers' own keys stolen from customers' own environments, and that the actor never compromised Anthropic's systems. The actor tried more than a dozen avenues to reach an unreleased Claude model, and failed every time.
It's the oldest of the Claude Platform's three key types. In Anthropic's own documentation, the column for who the key acts on behalf of reads, word for word, "No one": it belongs to the workspace it was created in. It keeps working even after the person who created it has left the organisation. Anthropic recommends personal keys or service account keys for new integrations.
Start with the places rather than the Console. Go through the tools where somebody could have pasted a key into a field: automation platforms, scripts, code repositories, one employee's machine, and the tools a department bought on its own. Write one row per find with four columns: where it lives, who set it up, which type it is, and whether it expires. The Console key list shows the expiration.
Anthropic's recommendation is to revoke it immediately. In the Console a key can either be disabled, which is reversible, or deleted, which is permanent. Anthropic also recommends rotating keys on a consistent schedule, for example every ninety days, by creating new ones and deactivating the old ones.
It lands the other way round. A large organisation has an offboarding procedure and a key policy, and therefore a partial answer to who a key belongs to. A twelve-person company where a freelancer set the whole thing up in an afternoon eighteen months ago has no answer at all, and often doesn't know the key exists.
The review itself is an afternoon's work and can be done internally with the table in this article. What takes time is migrating the integrations running on a workspace key, because each one needs the new key deployed and tested. Prices for my fixed engagements are on the pricing page.
Sources
- Anthropic: Detecting and countering misuse of AI, September 2026
- Anthropic: Threat Intelligence, every report in the series
- Claude Platform documentation: Authentication and the three key types
- Claude Platform release notes, 27 August 2026: personal keys and service account keys
- Anthropic support: API Key Best Practices
