“And how does the AI know who is allowed to see what?”
The question comes up in almost every initial conversation, and it sounds like a detail to deal with later. It is not. It determines whether an answer can contain a sentence from a document the person asking would never be allowed to open.
This article is about documents: the information stored on a drive, in SharePoint or in another repository. Databases, ERP and CRM systems have their own permission models, which cannot be covered as an aside. They will have an article of their own.
The easy approach
Search everything that is available, then hide whatever the person asking is not allowed to see.
It is easy to build, it is fast, and many tools work this way. It also works as long as the final output is a list and nothing more.
But this easy approach has three pitfalls.
Three pitfalls
1. Autocomplete. As people type into a search field, they receive suggestions. If those suggestions come from the entire collection, they can include terms that appear only in documents the person typing will never be allowed to see: the name of an initiative they are not supposed to know about, or a customer handled by another team. The results list is filtered. The word has already appeared on the screen.
2. Summaries. If an AI answer is assembled from ten documents and two are hidden afterwards, their content is still in the answer. A list can be shortened. A sentence influenced by that information can only be discarded. Removing the citation is not enough, because the sentence remains.
3. Numbers. A question such as “How many cases of this kind were there last year?” produces a total, not a list. If the entire collection is counted and information is hidden afterwards, that total is not correct for anyone.
And it can be used to work backwards. The clearest example is not the number of cases, but salaries. Someone who asks for a department’s average salary, knows its headcount and already knows two of the salaries can calculate the third. No document was opened and no access permission was breached. The number alone was enough.
The third gap is the most troubling, in two ways: an incorrect number looks like a correct one, and a correct number can reveal more than it should.
What NXTGN AI CORE does instead
The decision is made before the search. When each document is ingested, it receives information about who may see it, taken from the repository where it originated. NXTGN AI CORE passes that information to every small section into which the text is divided for searching. The person asking brings their own identifiers: their identity and the groups they belong to. The search covers only content matching those permissions.
The difference sounds technical, but it is not. Information someone is not allowed to see is not hidden afterwards. It never appears in the first place: not in the results list, not in the material used to create the AI answer, and not in the total.
Why one step includes a second check
There is a route that retrieves a document’s full text, for example to quote from it. At that point, NXTGN AI CORE checks the permission again, even though the preceding search has already applied the filter.
Checking twice is inelegant. The reason is the different consequences of errors. If the search is too restrictive, someone receives too few results and complains that very day. If this particular retrieval route is too permissive, unauthorised content appears in an answer and nobody complains. For the second case, a single checkpoint is not enough.
When a repository provides no permissions
Not every repository can report who is allowed to see its contents. A folder on a drive can, as can a SharePoint library. Others cannot.
The permission field then remains empty, raising the question of what an empty field should mean.
By default, NXTGN AI CORE interprets it as “nobody”. A document whose permissions cannot be determined does not appear in any search.
There is one exception: the AI administrator can see it. Not for convenience, but so that the problem can be noticed at all. If nobody can see a document, nobody will notice it, and a misconfigured repository would remain undetected.
The limitation that remains
Permissions change. Someone moves to another department, a group is dissolved, or a folder receives a new sharing permission.
NXTGN AI CORE does not apply these changes in the same second. A separate, lightweight synchronisation updates only the permissions, without processing the documents again. By default, it runs every five minutes. There is therefore a window between a change in the repository and its effect on the search.
That window can be shortened, but not eliminated. Its duration is therefore shown in the administration interface, not tucked away in a footnote. Anyone who does not know about it will assume something is wrong.
My conclusion
Both approaches look the same in a demo. You type a question, an answer appears, and the screen gives no indication of whether the access decision was made before or after the search.
The easy approach costs nothing either, as long as nobody reads the search suggestions, shares a summary or copies a number into a template.
The difference becomes apparent in one situation: when someone learns something they should not have learned. Until then, it is a question of AI architecture that can be discussed calmly. Afterwards, it is an incident, and the discussion is no longer calm.