Microsoft's AI Team, One SAS Token, and 38TB of Exposure

In September 2023, the security firm Wiz disclosed that Microsoft's AI research team had accidentally exposed 38 terabytes of private data. The cause was a single overly permissive access token, published in a public GitHub repository alongside legitimate open-source AI training data. It is one of the clearest illustrations of how the sprawl of AI research collides with cloud misconfiguration.

Microsoft's researchers were doing something entirely reasonable: sharing open-source models and training data through a public GitHub repo. To let people download a bucket of that data from Azure Storage, they generated a Shared Access Signature (SAS) token — a signed URL that grants access without requiring a login. The intent was to share one folder of AI data. The result was far broader.

How a share became an exposure

Two mistakes compounded. First, the SAS token was scoped not to a single folder but to the entire storage account. Second, it was configured with full-control permissions rather than read-only. Anyone who found the token could not just read everything in the account — they could delete or overwrite files, including the very models other people would download. In an AI supply chain, write access to a popular model repository is a poisoning vector, not merely a confidentiality problem.

Wiz reported the exposed data included disk backups of two employees' workstations, containing secrets, private keys, passwords, and over 30,000 internal Microsoft Teams messages. According to Wiz, the token had been committed in 2021 and remained valid — it was set to expire years in the future — meaning the window of exposure stretched across roughly three years before disclosure.

The AI angle is the volume

AI research is unusually data-hungry. Teams routinely move terabytes of models, datasets, and checkpoints, and they share them widely and informally to collaborate. That culture of open sharing — healthy for research — is precisely what turns one careless token into a 38TB incident. The larger and more casual the data flows, the more a single misconfiguration exposes.

What defenders should take from it

• Treat SAS tokens as credentials. Scope them to the narrowest path, grant read-only unless write is genuinely required, and set short expirations. A token that never expires is a permanent key.
• Scan repositories for secrets — including tokens in URLs. Secret-scanning that only looks for API keys and passwords can miss a signed storage URL. Microsoft has since expanded detection to cover SAS tokens.
• Inventory external sharing. Know which storage accounts can be reached without authentication, and review account-level access grants regularly. You cannot revoke a share you do not know exists.
• Separate data-sharing accounts from everything else. Backups, secrets, and internal chat history should never live in the same storage account as public research data.

Microsoft revoked the token, invalidated it, and confirmed no customer data was involved. Wiz noted the researchers acted quickly once alerted. But the incident is a warning to every organisation racing to stand up AI research programmes: the data volumes are enormous, the sharing is casual, and the access controls are frequently an afterthought. You cannot secure the AI data you have not mapped — and in a 38TB repository, the most dangerous object was a single line granting the whole account away.