Anthropic Threat Report September 2026: DevOps Lessons

The number that stopped me in Anthropic's report was not the biggest one. It was 34 hours: the time the report gives for a session-store dump holding more than 2,100 Azure AD token sets across more than 40 corporate tenants, with AI agents doing nearly all of the work. Our own token hygiene is measured in quarters, not hours.

This post is a defender-focused reading of the report Anthropic published on 10 September 2026, covering activity it disrupted between December 2025 and August 2026. I read the cyber sections myself; every claim about the attackers is attributed to the report and I add no operational detail. The mitigations come from Microsoft, GitHub and TruffleHog documentation that I also read, and anything that is my own opinion is labelled as such.

What the report actually says about three cyber cases

The report's central claim is that AI has moved attacks from manual, labour-heavy work to delegated, machine-speed execution, so sophistication no longer tells you who is behind an operation. It says Claude Haiku, Sonnet and Opus were used in all of its cyber cases. Three cases matter most to anyone who runs infrastructure, and the table separates what the report states from the lesson I draw.

Two limits on all of this. These are Anthropic's own findings about its own platform, so they describe what Anthropic could see, not the whole threat landscape. And the report does not say which kind of Azure AD token was in those sets, so I will not guess at it.

Rebuilt until undetected: why a signature is a lagging indicator

In the GTG-20006 case the report says monitoring agents watched whether deployed malware was flagged and the agents kept iterating until it was not. Its own conclusion is blunt: AI has inverted the cost back onto defenders, and static detections become less effective because adversaries can close the loop faster than defenders can respond.

I read that as a statement about timing rather than about any single product. A hash-based or string-based rule is written after a sample is seen, and a retest loop that rebuilds the sample can finish before the rule ships. The report does not say how long any loop took, so I am not claiming a number.

What survives a rebuild is behaviour and identity: a service account suddenly reading mail it never read, a token used from a device that never enrolled, a build job calling a new cloud API. That is why the rest of this post is about credentials and not about malware signatures. It is my inference from the report's argument, and your detection engineers may weigh it differently.

Session stores as loot: device-bound tokens and fast revocation

Anthropic says the 2,100 token sets came from a session-store dump, which is the part worth acting on: a session store is a pile of replayable credentials. Microsoft's Token Protection is aimed squarely at replay. Its documentation says it reduces token replay attacks by ensuring only device-bound sign-in session tokens, such as Primary Refresh Tokens, are accepted, so a stolen token cannot be used from another device.

Continuous access evaluation attacks the other half, the lifetime. Microsoft's page says access tokens default to one hour, that critical events are enforced in near real time with up to 15 minutes of latency, and that CAE-aware sessions can carry tokens valid for up to 28 hours because revocation is event-driven. Both controls have real boundaries, summarised below from the two Microsoft pages.

# Incident lever: kill every refresh token for one account, then let CAE-aware
# apps (Exchange, SharePoint, Teams) be challenged on their next request.
# Cmdlet named in Microsoft's CAE page; needs the Microsoft Graph PowerShell SDK.
Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId "dev@example.com"

# Caution from the same page: a Conditional Access policy or group change can
# take up to a day to reach resource providers (some policy updates, about two
# hours). Revoking sessions is the way to make it bite now.

# Rollout order for Token Protection, per Microsoft's deployment advice:
#   1. pilot group first
#   2. Conditional Access policy in report-only mode
#   3. capture interactive AND non-interactive sign-in logs
#   4. read the logs for long enough to cover normal app use
#   5. only then enforce

One developer token to cloud admin in about three hours

The report states that one intrusion escalated from a single stolen developer token to full administrative control of a victim's cloud environment in roughly three hours. It does not describe the steps and I will not reconstruct them. The finding is the distance, not the route: three hours is a short window for a quiet anomaly to be noticed and escalated by a human.

The defender question is therefore what a developer identity can reach on a bad day. My own audit starts with three questions: can this identity assign roles, can it read secrets stores, and is there any path from CI credentials to a break-glass role. If the answer to any is yes, that is the line to cut before buying any new tool.

AI API keys are now loot, and you need a register

The report recommends that organisations treat AI keys and agent integrations with the same seriousness as production credentials, and says one stolen key was used for roughly three weeks. In every instance it describes, the keys came from customers' environments rather than from Anthropic's systems. Three weeks of unnoticed use is an inventory failure before it is a detection failure.

The template below is mine, not the report's. Its job is to make each AI credential answerable to a person: who owns it, what environment it serves, when it dies and what should page you if it spikes. Spend caps themselves live in your provider's console, so the file records that one exists rather than inventing a value.

# ai-key-register.yaml -- MY template, not something the report prescribes.
# One row per AI credential. The point is that every key has an owner and an
# end date, so "stolen and used for three weeks" cannot go unnoticed for three weeks.
- name: ci-eval-harness
  provider: anthropic
  environment: ci-eval          # never a production workload
  owner: platform-team
  scope: eval-only workspace    # a workspace with no production traffic
  spend_cap: set-in-provider-console
  created: 2026-10-01
  rotate_by: 2026-10-31         # short on purpose
  stored_in: secrets-manager    # never in the repo, the image or the sandbox image
  injected_as: per-run env var  # minted per job, gone when the job ends
  alert_on: spend spike, new source IP, use outside CI window

# Wrong: one long-lived production key shared by the app, the eval sandbox
# and a developer laptop. One leak spends every environment's budget.
# Right: one key per environment, per job where the provider allows it.

Sandboxes, resellers and proxies are part of the attack surface

The report's guidance is that integrations built around AI, such as sandboxes, proxies, resellers and agents, belong inside your threat model. Its cases give each one a concrete shape, and the table pairs the reported pattern with the control I would check first.

None of these controls is exotic. What the report changes is the arithmetic: if an agent can try the same attack path against thirty targets in four days, as GTG-50020 did according to the report, then the weakest of your own integrations will be found by repetition, not by cleverness.

Where this advice breaks down

I would be overselling if I claimed any of this would have stopped the intrusions the report describes. Anthropic does not say how the session store was reached or what tokens it held, so I cannot tell you that Token Protection would have blocked it. The honest claim is narrower: these are the documented controls that address the credential classes the report says were taken.

• Coverage gaps: Token Protection browser support is in preview, and guest users are outside CAE, so partner and contractor accounts need their own plan.
• Revocation delay: up to 15 minutes for critical events, and up to a day for some policy and group changes, so manual revocation stays in your runbook.
• Vendor perspective: the report is Anthropic's account of its own platform. It cannot see attacks that never touched Claude, so the absence of a pattern in it is not evidence of absence.
• Tooling trust: a verifying scanner only confirms keys it has a detector for, and an unknown status means verification failed, not that the key is safe.

The trade-off I have chosen is to accept some rollout friction from device binding in exchange for shortening the replay window, and to keep the report-only phase long enough that I can see who it would break. That is my choice for my own environment, not a universal recommendation.

What to do on Monday

Five steps, ordered by how much risk each removes per hour of work. None needs a new product.

1. Inventory every AI API key you can find and write it into a register with an owner, environment and rotation date. Start with CI, eval harnesses and shared team vaults.
2. Scan your repositories and build workspaces with a verifying scanner, rotate every verified hit first, and only then clean up history.
3. Put a Token Protection policy into report-only mode for a pilot group, capture interactive and non-interactive sign-in logs, and read them before enforcing.
4. Write down and test the revoke-everything runbook for one developer identity, including how you confirm CAE-aware apps challenged the session.
5. Audit what each developer and CI identity can do in your cloud: role assignment, secrets read and any path to an administrator role. Remove what is not needed daily.

# Step 1: find AI keys that are still LIVE, not merely key-shaped strings.
# TruffleHog checks each candidate against the issuing API; --results=verified
# keeps only credentials confirmed valid and active.
trufflehog git https://github.com/your-org/your-repo --results=verified

# Same idea for a build agent's workspace or a dumped container filesystem.
trufflehog filesystem /var/lib/ci/workspace --results=verified

# Read the result statuses before you trust a clean run:
#   verified   = confirmed valid and active by API testing
#   unverified = detected but not confirmed (invalid, expired, or verification off)
#   unknown    = verification failed (network or API error) -- re-run, do not ignore

# Step 2: a verified hit means rotate FIRST, clean history second.
# GitHub's own secret scanning guidance is the same: rotate the affected
# credential immediately.

Steps 1 and 2 are cheap enough to finish in an afternoon, and they address the one class of loot the report calls out by name. Steps 3 to 5 are slower because they touch users, so schedule them with a pilot and a date.

The rule I am carrying from this report: assume any credential an agent can read will eventually be tried, and make every credential short-lived, device-bound where possible, owned by a named person, and revocable within minutes. The malware an attacker can rebuild overnight is not the part of the system I can control. The keys and tokens are.