It’s 11:40 on a Tuesday night and you’re staging a new agent against a tenant. You’ve got a service principal, a client secret in your .env, and a scope list you copied from a blog post eight months ago because it made the 403 errors stop. The agent indexes a SharePoint site, summarizes a few hundred documents, and posts a digest into a Teams channel. It works. You ship it. You never look at the scope list again.
That moment — the one where “it works” closes the question — is the moment I think about every time a headline like “How I Could’ve Accessed 17 Trillion Microsoft Records” crosses my feed.
What’s actually verified, and what isn’t
Let me be straight about the sourcing, because I build bots for a living and I’d rather you trust my numbers than my adjectives. The claim comes from a write-up by Usman Masood Ashraf framing a scenario of unauthorized access at enormous scale. The surrounding reporting I could find does not confirm that 17 trillion records were reachable, by him or anyone else. What the available material does establish is narrower and, honestly, more useful to us as builders: cybersecurity concerns around enterprise platforms are the dominant theme in current discourse, and Microsoft is shipping a steady run of security and data-governance changes across Microsoft 365, Teams, and Entra ID.
So I’m not going to tell you a breach happened. I’m going to tell you why the shape of the claim — one identity, absurd blast radius — is the exact failure mode agent developers are building toward by default.
Agents inherit permissions, not judgment
A traditional integration does one thing. You wire it to an endpoint, it moves rows, and its reach is roughly what you intended. An agent is different. It decides what to read next. Give it broad read access and a loose instruction, and the scope of its access isn’t what you granted — it’s what the model decides to go looking for inside what you granted.
That distinction matters for three reasons:
- Discovery is the product. We build retrieval agents specifically to find things humans wouldn’t find. That’s the feature. It’s also the vulnerability.
- Prompts are an input channel. Content inside the documents your agent reads can contain text that reads like instructions. If the agent has write or send capability, untrusted content now has a path to action.
- Credentials outlive intent. The scope list you pasted at 11:40pm has no expiry on your memory of why you added each item.
Microsoft is moving the controls closer to the agent
One of the more telling items in the October 2026 change notes: Microsoft Purview is adding inline DLP controls for prompts in Microsoft Foundry apps and agents. Read that as a statement of where the risk moved. Data loss prevention used to sit at the file and the mail boundary. It’s now being applied at the prompt — the place where an agent asks for things and the place where things leave.
Alongside that, Purview’s data lifecycle management is doing retention based on “last accessed” for OneDrive and SharePoint files. For bot builders, that’s a quiet landmine worth naming: an indexing agent that touches every file in a library is also accessing every file in that library. If retention decisions key off access timestamps, your crawler is now a participant in governance, not an observer of it. I’d want to know that before I pointed a nightly job at a ten-year-old document store.
Entra ID continues to pick up security measures, and Teams is getting a separate attendance report policy for events in October 2026. Different surfaces, same direction of travel: more granular policy, applied per capability, closer to where data actually gets read.
What I changed in my own builds
None of this is exotic. It’s just unglamorous enough that we skip it.
- One identity per agent. Not one per team, not one per environment. If two agents share a principal, you can’t revoke one without breaking the other, so you’ll revoke neither.
- Scope diffs in code review. Permission changes get reviewed like schema migrations, with a written reason per scope. If nobody can explain a scope, it comes out.
- Read and write live in separate identities. The thing that summarizes should not be the thing that sends.
- Log what the agent retrieved, not just what it answered. Output logs tell you the agent behaved. Retrieval logs tell you what it could see.
- Treat retrieved content as hostile input. Strip or fence instruction-shaped text before it reaches the model’s instruction context.
The headline number may never be substantiated. The design lesson doesn’t depend on it. Whatever the real figure turns out to be, somebody built an identity with a reach nobody had audited, and most of us have one of those sitting in a repo right now.
🕒 Published: