Microsoft AI Researchers Expose 38TB via an Overly Permissive SAS Token (Sept 2023)

Retrospective: this article looks back at events from September 2023, written in 2026 with the benefit of hindsight.

On September 18, 2023, Wiz Research disclosed that Microsoft's AI research team had accidentally exposed 38 terabytes of private data through a single misconfigured Shared Access Signature (SAS) token in a public GitHub repository. The exposed storage account included disk backups of two employees' workstations — with secrets, private keys, passwords and more than 30,000 internal Microsoft Teams messages.

1. Token publishedJuly 2020: Microsoft AI researchers add a storage URL with a SAS token to a public GitHub repository for downloading models.
2. Scope far too broadThe token grants access to the entire storage account — with full control, not just read.
3. Expiry extendedOctober 2021: the token's expiry is updated to October 2051.
4. DiscoveryJune 22, 2023: Wiz Research finds the exposure and reports it; Microsoft invalidates the token two days later.
5. DisclosureSeptember 18, 2023: public disclosure; Microsoft says no customer data was exposed.

It's one of the clearest examples of a modern cloud data exposure: no attacker, no vulnerability — just an access link scoped far too broadly, left valid for far too long.

What happened

Microsoft AI researchers were publishing open-source training data and models on GitHub. To let people download them, they included a URL to an Azure Storage account with a SAS token appended. According to Wiz's timeline:

• July 20, 2020: the SAS token was first committed to GitHub, with an expiry of October 5, 2021.
• October 6, 2021: the expiry was updated to October 6, 2051.
• June 22, 2023: Wiz Research found the issue and reported it to Microsoft.
• June 24, 2023: Microsoft invalidated the token.
• September 18, 2023: public disclosure.

The token didn't grant read access to a few model files. It granted access to the entire storage account, and with full control permissions — meaning someone could also have overwritten or deleted data, including the AI models people were downloading.

Microsoft stated that no customer data was exposed and no other internal services were put at risk.

Why SAS tokens are hard to govern

Azure Storage supports three kinds of SAS:

• Account SAS and service SAS are signed with the storage account key. Azure doesn't keep a central record of tokens you've generated, so you can't easily list them, and revoking one usually means rotating the account key — which breaks every other client using it.
• User delegation SAS is signed with Microsoft Entra ID credentials, has a maximum lifetime of seven days and can be revoked centrally.

A token generated in seconds in Storage Explorer or the Azure portal can therefore become a permanent, untracked credential. In this case, it was also public.

Why it mattered

AI projects create new data paths. Research and data science teams move very large datasets quickly, share them with collaborators and publish them — often outside normal data governance.

Write access is a supply-chain risk. Because the token allowed writes, an attacker could have tampered with models that others downloaded and ran.

Backups are sensitive. Workstation backups contained secrets that could have led much further than the storage account itself.

What to do now

1. Find storage accounts that allow Shared Key authorization. In Azure Resource Graph, list storage accounts with allowSharedKeyAccess not set to false. Account and service SAS tokens depend on it.
2. Move applications to Entra ID. Use managed identities and RBAC roles such as Storage Blob Data Reader, then set Allow storage account key access to Disabled. That invalidates every account and service SAS on that account in one step. Check first: some tools and services still need Shared Key, and storage logs show which requests use it.
3. Use user delegation SAS when you must share. Keep lifetimes short (hours, not years) and scope tokens to a specific container or blob with read-only permissions.
4. Set a SAS expiration policy on storage accounts that still allow Shared Key, so long-lived tokens are flagged or blocked.
5. Scan repositories and notebooks for tokens. GitHub secret scanning detects Azure SAS tokens; also check documentation, wikis and Jupyter notebooks.
6. Separate data by purpose. Public datasets belong in a dedicated storage account with nothing else in it.
7. Monitor. Enable Defender for Storage and storage diagnostic logs; alert on SAS-authenticated writes and large downloads from unfamiliar IP addresses.

How to detect risky SAS use

Storage diagnostic logs record how each request was authenticated, which makes SAS misuse visible:

• In StorageBlobLogs, filter on AuthenticationType == "SAS" and summarize by caller IP address, operation and bytes. Writes and deletes through SAS from unfamiliar IP addresses deserve immediate attention.
• In Azure Activity logs, watch for listKeys and regenerateKey operations on storage accounts by identities that don't normally perform them. Anyone who can list keys can mint account SAS tokens.
• Enable Defender for Storage, which alerts on access from suspicious IP addresses, anonymous scanning and unusual data extraction.
• Turn on GitHub secret scanning for public and private repositories so tokens are flagged when committed.

Common mistakes

• Generating tokens from the portal or Storage Explorer "just to share quickly." These convenience features create long-lived credentials that nobody tracks.
• Setting far-future expiry dates to avoid broken links.
• Granting account-level access when a single container or blob would do.
• Mixing public and private data in one storage account. A token meant for public models shouldn't sit next to workstation backups.
• Rotating keys without understanding dependencies, which breaks applications and tempts teams to avoid rotation entirely. Moving to Entra ID authentication first makes key rotation — and eventually disabling keys — safe.

Related incidents

The Microsoft SAS token exposure fits a long pattern of storage misconfiguration across every major cloud. In 2017, dozens of organizations exposed data through public Amazon S3 buckets. In 2020, Microsoft disclosed that a customer support database had been exposed after a network rule change. In 2022, researchers reported a misconfigured Azure Blob Storage container they called BlueBleed. Each case involved access that was broader than intended and visible to anyone who looked. The fix is consistent too: identity-based access instead of shared keys, private-by-default storage, short-lived sharing, and monitoring that catches exposure before outsiders do.

Questions for leadership

• Where do our AI and data science teams store and share data?
• Could a link shared years ago still grant access to our storage today?
• Do our AI initiatives follow the same data governance as everything else?

Key takeaways

• One overly broad SAS token exposed 38TB of Microsoft data for nearly three years.
• Account and service SAS tokens are hard to track and revoke; user delegation SAS is safer.
• Disabling Shared Key authorization removes the riskiest token types entirely.
• AI and research data needs governance from day one.