RBAC Is the Hard Part of AI, and Nobody Wants to Hear It

Part two of The Corporate Second Brain, a six-part series. The full map is at the end.

The demo always works. It works because in a demo, the AI can see everything. You ask it anything and it answers, because there are no walls in a sandbox.

Then you roll it out to the whole company, and you remember that your company has walls for good reasons. HR data. Board materials. The comp spreadsheet. The deal that has not closed. The moment the assistant can read all of it, you have not built a productivity tool. You have built the fastest way to leak your own company to itself.

This is the part nobody wants to hear. The hard problem in enterprise AI is not the model. It is who is allowed to see what.

Retrieval is a permission decision, not a search

Here is the reframe I give every technical leader. When your AI pulls a document to answer a question, that is not a search. It is an authorization decision. The system is deciding this person is allowed to see this. Most teams build it as a search and bolt permissions on afterward, and that is exactly how the comp spreadsheet ends up quoted in a chat with a summer intern.

The rule is simple to say and hard to do. A document the user is not allowed to open must never enter the AI's context in the first place. Not filtered out of the answer after the fact. Never retrieved at all. If the machine read it to write the answer, it does not matter that it "chose not to mention it." It already leaked in the phrasing.

The good teams enforce this in two places. At ingestion, when a document comes in, it is tagged with who can see it, and anything sensitive is walled off before it is ever indexed. At retrieval, every lookup is scoped to the person asking. Two gates. OpenAI reportedly runs a permission system across tens of billions of documents to do exactly this. The scale is enormous. The principle is the same one your file server has used for thirty years.

The permission that outlived the person

Let me make the failure concrete, because it does not look like a hack. It looks like an ordinary Tuesday.

An analyst moves from finance to marketing. Nobody revokes the finance access, because nobody ever does. A quarter later a document from the finance drive gets copied into the AI's index, and the permissions ride along frozen as they were the day of the copy. Now marketing can ask the assistant about margins they were never supposed to see, and the assistant answers, helpfully, with a citation. No alarm goes off. Nobody chose this. It is just three small bits of drift lining up, and the machine treating stale permissions as current truth.

That is the whole risk in one scene. Access control is not hard because the concept is hard. It is hard because permissions go stale, and an AI applies stale rules faster and more confidently than any human ever would.

Why governance is where projects rot

The trap is copying permissions into a second place. The day you duplicate "who can see this" into a separate search index, you have signed up to keep two systems in sync forever. They will drift. They always drift.

A document gets copied into the AI index with the permissions frozen as they were the day it was copied. Six months later the source says "confidential" and the index still says "everyone." Now your AI is enforcing a rule that was true in March. This is the quiet failure mode that turns a working system into a liability nobody notices until it quotes the wrong thing to the wrong person.

The underrated advantage of plain files

This is where I break from the standard playbook, and it is the thread running through this whole series.

If your knowledge lives in a folder of files instead of a specialty database, the permission system is the one your operating system already ships. The folder either lets this person in or it does not. There is no second copy of the rules to keep in sync, because the files are the rules. Put the deal room in a directory the deal team can open and nobody else can. The AI acting on your behalf inherits your access. It cannot read what you cannot read, because it is walking the same filesystem you are.

I want to be honest about the edge. Scoping an agent so it truly cannot wander into a folder it should not touch is real engineering, and the tooling for doing it cleanly is still young. Anyone who tells you this is solved is selling something. But starting from "the files carry their own permissions" is a much better place to stand than "we copied everything into a search engine and now we manage access twice."

What to do this week

1. Ask for one number. How many places does "who can see this document" currently live? If the answer is more than one, that is your drift risk, named.
2. Run the intern test. If you gave the AI assistant to your newest hire today, what is the first thing they could ask it that they should not be able to see? If you do not know, you are not ready to turn it on.
3. Decide where retrieval gets scoped. Before generation, not after. Write that requirement down before you evaluate a single vendor.
4. Keep permissions in one place. Wherever the document actually lives. Do not let a shiny tool talk you into a second copy of the rules.

The board question I would ask this week is short. When we turn this on, whose access does it use? If the answer is "everyone's," you do not have an AI project yet. You have an incident waiting for a date.

Next up, the layer that decides whether the assistant is trustworthy or just fluent: ingestion, and why garbage in means confident nonsense out. Access control keeps the AI from reading what it should not. Ingestion decides whether what it does read is even true.

---

The Corporate Second Brain, a six-part series

1. Your Company Already Has a Second Brain
2. RBAC Is the Hard Part of AI (this post)
3. Why Ingestion Is the Whole Ballgame
4. I Replaced the Vector Database with a Folder
5. From What We Know to What You Should Do
6. Build a Corporate Second Brain in a Weekend