Direct answer
Cut groups along three dimensions — people, work and classification — then set three rules: deny by default (nothing that has not been explicitly granted can be retrieved), scope by role (sales sees pricing, support sees process), and cap by classification (restricted material is open only to named people and never surfaces externally). Technically, permissions must take effect before retrieval rather than filtering results afterwards — filter first, then retrieve. Otherwise the AI has already read documents it should never see into its context and can repeat them back.
Without permissions, a knowledge base amplifies overreach
Before AI, overreach required someone to actually open the wrong file. With AI, a single question can assemble material that was never meant to leave the building into a tidy answer. Permission design therefore has to come first, not after an incident.
Cut groups along three dimensions
- People — grouped by role (sales, support, delivery, finance, external visitors).
- Work — grouped by business line or project (the same product catalogue can look different to business A and business B).
- Classification — public, internal, restricted, aligned with your document tiering.
Crossing the three gives you combinations of who, on what kind of work, and at what classification. Do not chase infinite granularity — a set of groups covering 80 per cent of everyday cases is enough, and the remainder can be handled through exception approvals.
Three rules
- Deny by default. Material without an explicit grant is retrievable by nobody. This turns the consequence of “we forgot to configure permissions” from a leak into an unavailability — the safe direction.
- Scope by role. Sales gets products and pricing wording, support gets process and scripts, delivery gets implementation documents. Scope follows the needs of the job, not seniority.
- Cap by classification. Restricted material is open only to named people, and by default is not allowed into the answering chain of any externally facing AI.
The technical point: permissions must apply before retrieval
The correct chain is: filter the document set by the asker's identity → retrieve within that set → generate the answer.
The wrong pattern is “retrieve across the whole base, then delete the passages the asker has no right to see.” The problem is that the document has already been read into the context and the model may already have built its answer from it — the final step only truncates the output. The information has in fact already left.
Handling external visitors
AI customer service aimed at outside visitors needs its own permission set: access limited to the public tier plus approved external messaging, physically or logically isolated from the internal base. One shared base serving both internal staff and external customer service is the most common source of overreach.
Four steps to put it in place
- List roles and business lines, and define the grouping table (a single meeting is enough).
- Label existing material with a classification — restricted first, everything else internal by default.
- Configure pre-retrieval filtering and verify it case by case with a test account.
- Audit the permission configuration once a quarter to check it has not been scrambled.
Key facts
| Grouping dimensions | People (role) / work (business line or project) / classification (three tiers) |
| Three rules | Deny by default, scope by role, cap by classification |
| Technical requirement | Permissions must apply before retrieval (filter, then retrieve), not filter after retrieval |
| External isolation | External AI may only reach the public tier and approved external messaging, isolated from the internal base |
Sources
- Permission and isolation conventions from enterprise knowledge base delivery work
- Minimum-necessary and isolation principles for connecting a knowledge base to AI customer service
- Three-tier document classification (public / internal / restricted)
Follow-up questions
Does a small team need permissions at all?
Yes, but simplified: start with a single internal-versus-external split, separating the externally facing AI from internal material. That one step blocks the most common form of overreach.
Can permissions be assigned by seniority?
Less well than by business role. A senior title does not mean someone needs to see everything; scope should follow the content of the work.
How often should permissions be reviewed?
Quarterly is a sensible rhythm. Focus on whether newly added material has landed in the everyone-can-see-it default, and whether access is revoked when people change roles.
Can an external visitor's question hit internal material?
It should not. The external chain must reach only the approved external messaging set, with pre-retrieval filtering — and it should be verified case by case with a test account before launch.