Identity is the filter: building identity-aware RAG.
A support assistant that can answer from 100,000-plus tickets is easy to demo and hard to ship — because the moment it works, it knows too much. For a five-brand company the hard problem in retrieval was never finding the answer. It was making sure the person asking was allowed to see it. Here is how I built Knowledge Fabric so identity does the filtering, and why that decision had to come first.
The problem was never search
Knowledge Fabric answers support questions from more than 100,000 help-desk tickets, plus point-of-sale configs and SharePoint. Standard retrieval — embed the corpus, match the question, return the closest chunks — gets you a working demo in an afternoon. Then you remember the corpus spans five brands. A front-desk lead at one brand asking how to refund a membership should never get back another brand's playbook, another brand's pricing, or a note meant for a regional manager. The hard part is not relevance. The right answer for one person is a leak for another.
Identity is the filter, not a redaction step
The tempting shortcut is to retrieve first and scrub after — pull the best chunks, then strip the ones this user should not see. That fails two ways: the sensitive content already rode through the model's context, and the answer quietly degrades because you deleted material it was reasoning over. So I pushed identity to the front. Knowledge Fabric is grounded on Entra ID — 1,523 verified identities across a 15-slot attribute schema — and those attributes become a filter applied at retrieval, before a single chunk reaches the model. You do not retrieve and redact. You retrieve only what this identity is allowed to see.
Attributes scale where role lists don't
Five brands, several roles, regions on top of that — model it as static role lists and you are hand-maintaining a combinatorial mess forever. The 15-slot attribute schema is what made it tractable: every chunk is tagged with the attributes required to see it, every identity carries its attributes from Entra, and access is simply the match between the two. Add a brand or a role and you are adding attribute values, not rewriting access rules. Attribute-based access is more work to stand up than a role dropdown, and far less work to live with.
Grounded answers, with receipts
Every answer cites where it came from — the ticket, the POS config, the SharePoint doc. That is partly trust: a support lead can click through and verify instead of taking the model's word. It is also a guardrail — an assistant that has to cite a source has a harder time inventing one. Grounding plus identity-filtered retrieval means the model only ever sees a small, authorized, relevant slice of the corpus, which is also why it answers quickly and stays on topic.
How I knew it actually held
Boundary logic is exactly the kind of thing that looks right in a demo and leaks in week three, so phase one did not ship on vibes — it closed at 52/52 QA checks, and the access-boundary cases were the ones I cared about most. Can one brand reach another brand's content? Does a role change immediately narrow what is retrievable? Does an identity with missing attributes fail closed — return nothing — instead of failing open? The eval harness was the release gate. If a boundary check failed, it did not ship.
What I would tell you
Decide who is allowed to see what before you tune retrieval quality — boundaries are load-bearing and retrofitting them is miserable. Filter at retrieval, not after. Reach for attributes over roles the moment access has more than one dimension. And write the boundary tests first, because those are the ones that fail quietly. I left the franchise group before Knowledge Fabric rolled out portfolio-wide, which is why the identity-aware patterns are going open source as part of TenantFleet — the boundary problem is not unique to one company, and nobody should have to rediscover “filter on identity, not after” the hard way.
Building retrieval that has to respect who is asking? Let's talk — or see the case studies.