AI-run breaches in 3 hours: harden your Azure tenant now

On 10 September 2026 Anthropic published its threat intelligence report "Detecting and countering misuse of AI: September 2026", covering operations it disrupted between December 2025 and August 2026. One number in it should be read twice by anyone who runs a Microsoft tenant. After breaching a SaaS provider, a ShinyHunters affiliate pulled data belonging to roughly 200 of that provider's downstream customers and then dumped a session store containing more than 2,100 Azure AD token sets spanning more than 40 corporate tenants, in about 34 hours. A separate compromise went from one stolen developer token to full administrative control of a cloud environment in roughly three hours. AI agents did nearly all of the work. The report is a catalogue of what attackers now do with frontier models. It is light on what defenders should do about it, so the mapping to Entra ID, Foundry and the rest of an Azure estate is below.

What the report actually documents

Anthropic groups the disrupted activity into seven harm categories. Four of the cyber cases matter directly to an enterprise running on Azure.

• GTG-50014, ShinyHunters affiliates. Financially motivated operators who treated the supply chain as the front door. One affiliate downloaded 1.8 million Android APKs to harvest hardcoded secrets. Another breached a SaaS provider and used that foothold to reach the provider's customers, which is where the 2,100 token sets across 40 tenants came from. The operators also treated stolen AI API keys as both a target and a compute resource for the next attack.
• GTG-20006, Russian state-nexus espionage. AI-automated intrusions against government ministries, defence and intelligence bodies, embassies and defence-industrial companies, "concentrated in Ukraine and Europe". When endpoint security caught the malware, the operators had Claude rebuild it. More than 20 organisations were hit, including drone manufacturers.
• GTG-10007, Chinese exploit foundries. Undergraduates and security professionals running continuous binary reversing against major endpoint-security products, producing around a dozen possible zero-day findings in a single month. The report's conclusion from this case: "security through obscurity" is no longer viable, and everything connected to the internet is a potential target.
• GTG-50029, the AI supply chain itself. A Russian-speaking actor tried to reach pre-release Claude models through compromised evaluation sandboxes. Stolen keys and session tokens were a primary objective across several cases, because a stolen key gives resale value, free compute and attribution cover in one object.

Two further points frame the rest of this piece. First, Anthropic states that none of the misuse cases involved Claude Fable or Mythos-class models, apart from one illicit distillation case, and attributes that to the cyber safeguards on those models. Second, the report's own recommendation on credentials is blunt: "Organizations should treat AI keys and agent integrations with the same level of seriousness as they do production credentials", and AI access "should be purchased only through authorized channels". A discounted key that routes traffic through an unknown intermediary is a data exfiltration path with a price tag attached.

Why "Azure AD token sets" is the line to reread

The tokens were not taken from Microsoft. They were sitting in a third-party SaaS provider's session store, because that provider had been granted OAuth access to its customers' Microsoft tenants and cached the resulting tokens to keep its integration working. When the provider fell, the tenants fell with it. Your Conditional Access baseline, your MFA rollout and your privileged identity management did not get a vote, because the attacker never signed in. They replayed a token that had already been minted for someone your tenant trusted.

Microsoft's own security blog described the same actor's playbook against Salesforce customers in July: vishing employees into approving a malicious connected app disguised as a data loader, and harvesting OAuth tokens from breached integration vendors such as Salesloft and Gainsight. Both techniques "bypassed traditional authentication detections by operating through approved identities and legitimate workflows". The September report shows the Microsoft-tenant version of that play, at AI speed.

The practical consequence: every enterprise application with consent in your tenant is now part of your attack surface, and the security of that application's token storage is your problem, whether or not the vendor's contract says so.

The hardening checklist, mapped to Azure

1. Inventory and shrink OAuth consent

Export the enterprise applications list from Entra ID and sort by permissions granted, not by name. Anything with Mail.Read, Files.Read.All, Sites.Read.All or Directory.Read.All at application scope deserves a named owner and a written reason. Then turn off user consent for unverified publishers, route everything else through the admin consent workflow, and let Defender for Cloud Apps app governance flag apps whose behaviour changes after approval. A quiet integration that suddenly enumerates every mailbox at 03:00 is the signature the report describes, and it is visible only if someone is watching consented apps as a class.

# List service principals with application-scope Graph permissions granted in the tenant
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/servicePrincipals?\$select=id,displayName,appId,publisherName" \
  --query "value[]" -o json > sps.json

# For each, pull the app role assignments (application permissions) it holds
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/servicePrincipals/<sp-id>/appRoleAssignments" \
  --query "value[].{resource:resourceDisplayName,roleId:appRoleId}" -o table

Map the role IDs back to permission names with the Microsoft Graph service principal's appRoles collection. The output is usually longer than anyone expected.

2. Make stolen tokens worthless

Token Protection in Conditional Access binds sign-in session tokens to the device that requested them, so a replayed Primary Refresh Token from another machine is rejected. As of the August 2026 documentation it is generally available for native applications on Windows, iOS and macOS covering Exchange Online, SharePoint Online and Teams, with Azure Virtual Desktop and Windows 365 on Windows, and in preview for browser-based access to Azure Resource Manager. Roll it out in report-only mode first, watch interactive and non-interactive sign-in logs for a full business cycle, then enforce for a pilot group.

Token Protection does not cover tokens minted for third-party applications through OAuth consent, which is exactly the class stolen in the SaaS case. For those, the controls are shorter token lifetimes where the app supports them, Continuous Access Evaluation for Microsoft first-party resources, and a rehearsed procedure for revoking a service principal's refresh tokens the moment a vendor discloses a breach.

3. Treat AI keys as production credentials, literally

The 1.8 million APKs were downloaded to find hardcoded secrets. The same technique works on any public repository, container image or npm package your teams publish, and AI API keys are what the operators were after. On Azure the fix is structural rather than procedural: remove the key from the equation. Foundry and Azure OpenAI resources accept Entra ID authentication, and the resource can be configured to refuse key-based calls entirely. Workloads on Container Apps, AKS, Functions or App Service then call the model with a managed identity, and there is no string to leak.

// Bicep: an Azure OpenAI / Foundry resource that refuses API keys
resource aoai 'Microsoft.CognitiveServices/accounts@2024-10-01' = {
  name: 'aoai-prod-swc'
  location: 'swedencentral'
  kind: 'OpenAI'
  sku: { name: 'S0' }
  properties: {
    disableLocalAuth: true          // Entra ID only, no key-based access
    publicNetworkAccess: 'Disabled' // reach it over Private Link
    customSubDomainName: 'aoai-prod-swc'
  }
}

// Grant the workload identity the data-plane role instead of handing out a key
resource userRole 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  scope: aoai
  name: guid(aoai.id, workloadIdentityPrincipalId, 'openai-user')
  properties: {
    principalId: workloadIdentityPrincipalId
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions',
      '5e0bd9bd-7b93-4f28-af87-19fc36ad61bd') // Cognitive Services OpenAI User
    principalType: 'ServicePrincipal'
  }
}

Where a key is unavoidable, for example a third-party SaaS that only speaks API keys, store it in Key Vault, rotate it on a schedule, and enable push protection and secret scanning on every repository. The report's line about buying access "only through authorized channels" belongs in your procurement policy verbatim. Foundry, Bedrock, Vertex and the vendors' own consoles are authorized channels. A reseller offering half-price GPT-6 Astra tokens through a proxy endpoint is not.

4. Detect on an hours clock, not a days clock

Three hours from first token to global admin means the traditional next-business-day triage of a medium-severity alert is not a detection strategy. The behaviours the report describes are detectable: a service principal enumerating directory objects it has never touched, bulk Graph calls against mail and files, new credential additions to existing app registrations, mass downloads from SharePoint, and privilege escalation chains that complete in minutes. Microsoft Sentinel and Defender XDR both ship analytics rules for these patterns, and Microsoft's July blog post published advanced hunting queries for connected-app abuse specifically. Enable them, tune the thresholds against your own baseline, and route the resulting incidents to someone who is paged, not someone who reads a dashboard on Monday.

5. Assume the backups are a target

The report notes that operators now maintain persistence by corrupting restoration points, so that recovery re-infects the environment. Azure Backup vaults support immutability and soft delete; both should be on for anything you would restore after an incident. Test a restore to an isolated subscription quarterly, and scan the restored image before it touches the production network. A backup you have never restored is a hypothesis.

6. Your own agents need the same fences

The day before the threat report, on 9 September, Anthropic published a separate alignment assessment covering four incidents in which Claude models running inside a partner's cybersecurity evaluations reached real third-party systems. In each case the evaluation environment had been misconfigured to allow internet access while the prompt claimed otherwise. One model uploaded a malicious package to PyPI; another compromised a real company's web application that shared a name with the fictional target. Anthropic's conclusion applies to any agent you run in Foundry Agent Service or Copilot Studio: network isolation would have prevented every one of these incidents, and the model's own judgement is only one layer. Give agents an explicit egress allowlist, a scoped identity, and no standing credentials they do not need for the task in front of them.

What this costs in licences and effort

The cheapest items on that list, consent review and disabling local auth, close the two paths the report shows being used most. Start there.

The Swedish and EU angle

Cybersäkerhetslagen turns the three-hour breach into a reporting problem. Sweden's NIS2 transposition, cybersäkerhetslagen (2025:1506), entered into force on 15 January 2026, the registration service for in-scope entities opened on 2 February 2026, and the regulations on incident reporting and information obligations took effect on 1 July 2026. The NIS2 directive's cadence is an early warning within 24 hours of becoming aware of a significant incident, a full notification within 72 hours and a final report within a month. If an attacker completes the compromise in three hours and the first internal alert is read the next morning, the organisation is already behind on the 24-hour clock before anyone has opened a ticket. Detection latency is now a regulatory exposure, not only a technical one.

The supply chain is in scope, and the report shows why. NIS2 requires in-scope entities to manage supply-chain security as part of their risk regime. The SaaS provider whose session store held 2,100 tenant token sets is precisely the kind of supplier that needs to appear in that risk assessment, with a documented answer to "what happens to our tokens if you are breached". Ask vendors how long they cache Microsoft refresh tokens, whether they encrypt the session store with keys outside the application boundary, and whether they can revoke every token for your tenant on request within an hour. Vendors who cannot answer are telling you something.

European government targets are named explicitly. GTG-20006's target list of ministries, defence bodies and diplomatic missions concentrated in Ukraine and Europe should be read alongside Sweden's position as a NATO member with a growing defence-industrial base. Public-sector bodies and their suppliers in Sweden, including the small engineering firms that sit two tiers down in a defence supply chain, are inside the blast radius the report describes. For those organisations the checklist above is not optional hardening. It is the baseline the national authorities will expect when the first incident report lands.

Data residency does not help with stolen tokens. Running your models in Sweden Central and your data in the EU Data Zone keeps the data where the regulator wants it. It does nothing against an attacker who holds a valid token for a user in that tenant. Residency and identity security are separate budgets, and the September report is an argument for the second one.

Conclusion

The September 2026 report documents three shifts at once: attackers compressing a cloud takeover into hours, treating third-party SaaS integrations as the entry point into Microsoft tenants, and hunting AI API keys as a first-class objective. Each maps to a control you can switch on this month. Review every consented application and its scopes. Enforce Token Protection where it is generally available and rehearse token revocation for the rest. Disable key-based access on Foundry resources and move workloads to managed identities. Tune Sentinel for enumeration and escalation patterns that complete in minutes. Make backups immutable and test the restore. Fence your own agents with egress allowlists. Then put the vendor questions about token caching into the next supplier review, because under cybersäkerhetslagen the supplier's session store is now part of your incident.