The Identity Layer Nobody Prioritizes
Reading note
Essays for people who want the pattern behind the pattern.
This page is designed to read like a quiet, deliberate argument rather than a feed item.
There’s a pattern I keep watching play out: a team spends three weeks evaluating models. GPT-4 vs. Claude vs. Gemini. They run benchmarks. They compare output quality. They build a matrix.
Then they deploy the winning model with a service account that has read access to everything.
The model selection was never the consequential decision. The identity and access layer was. And it barely got discussed.
Here’s what I keep seeing:
Service accounts with blanket permissions. The AI agent can read anything the service account can read. If that account has access to HR data, financial records, or customer PII — so does the agent. Nobody intended this. They just used the same service account they use for everything else.
No scoping by use case. An agent built for IT helpdesk questions doesn’t need access to the finance SharePoint. But it has access because the search index it queries wasn’t scoped. The agent is as permissive as its retrieval layer, and nobody audited the retrieval layer.
Token-level permissions don’t exist yet. The model sees everything in the context window equally. You can’t say “use this document for answering but don’t surface the salary data in paragraph three.” Once it’s in the context, it’s available. The only control is what gets into the context in the first place.
The test environment lie. In the pilot, the agent queried a curated dataset. In production, it queries the real thing. Nobody re-evaluated permissions at the transition point because “it worked in test.”
The fix isn’t complicated, but it requires someone to ask the question before deployment: what is the worst thing this agent could surface, to whom, and is that acceptable?
Most teams don’t ask because the identity layer isn’t exciting. It’s not the model. It’s not the UX. It’s plumbing. But plumbing is where the data leaks happen.