Enterprise Knowledge Base Permissions: Let AI See Only What Each User May Access

The core of enterprise knowledge base permission design is not putting a login screen in front of chat. It is making sure every retrieval is confined to material the person asking is allowed to see. The safest pattern starts with documents or knowledge domains, narrows them through field, department and role rules, and checks the generated answer for sensitive fields before it is displayed.

This article is about access to knowledge: which sources a person may retrieve and how much detail the answer may reveal. Whether AI may update an order, send an email or approve a payment belongs to tool and action permissions, managed on a separate control plane. Both matter, but collapsing them into one role matrix makes risk harder to see and acceptance harder to test.

The protected object is knowledge, not a generic right to use AI

An employee being allowed to use the knowledge base does not mean they may retrieve everything inside it. Sales needs product specifications, quotation rules and delivery records for its own accounts; it usually has no reason to see company-wide payroll detail. Support needs after-sales policy, but access to a chatbot should not expose an unreleased product roadmap. What needs authorisation is the domain, document, passage and sensitive field.

Permission discovery should therefore begin with what is in the corpus, not with a list of job titles. Mark each source with its authoritative owner, sensitivity, applicable organisation and permitted roles, then map trusted user identities to those attributes. Permissions cannot stay stable while knowledge has no authoritative home: if three copies of one policy carry different labels, a user may slip through the loosest copy. Why companies need unified knowledge assets explains why the sources must be consolidated before AI is connected.

Four boundaries work in combination, not as substitutes

The document layer decides whether an entire source is visible. It suits contracts, bid files and board material with clear boundaries. The field layer handles different visibility inside one record: the project team may see a customer name, only the account owner may see the contact's phone number, and cost or margin may be restricted to authorised managers. Hiding a column in the interface is not field security; restricted values must be removed or substituted before they enter retrieval text and generation context.

The department layer expresses organisational ownership, such as East China sales seeing East China accounts, or general HR policy being open to all while individual HR cases remain private to Human Resources. The role layer expresses responsibility: a support manager may see escalation rules hidden from frontline staff, and a procurement approver may see supplier assessments hidden from ordinary requesters. Department answers where you belong; role answers what duty you perform. Department alone blocks cross-functional projects, while role alone can grant the same title too broadly across regions.

An executable rule is usually an intersection: the user belongs to the relevant region, carries the required role, is cleared for the source's sensitivity, and the document status permits retrieval. General policy may be open to all staff. Sensitive material should default to denial and open only when the conditions are explicitly met. The more sensitive the material, the less its treatment should depend on a filename, folder location or uploader's memory.

Pre-retrieval filtering decides whether AI ever sees restricted content

A controlled answer follows a visible path. The system obtains the user's identity from single sign-on or another trusted account source and resolves their departments, roles and temporary project groups. Those attributes travel with the search request. The search layer filters document and passage metadata before ranking the permitted set by keyword or vector similarity. Only the surviving passages may enter the model context. If identity cannot be established or a source lacks mandatory labels, the request should be denied or reduced to a public domain—not allowed to search the entire corpus.

This is pre-retrieval filtering, and it is materially stronger than writing “do not disclose secrets” in a prompt. A prompt asks the model to behave after it has already seen the content; permission filtering aims to prevent an unauthorised passage from entering context at all. In the basic retrieval-augmented generation flow, retrieval already precedes generation. Access conditions must be part of that retrieval query, not a patch attached to the answer.

Derived indexes need the same scrutiny. Permissions on the source file do not automatically prove that vector passages, summaries, generated Q&A pairs and caches inherited them. Every derivative should retain the source identifier, access labels and version status. Revoking or retiring a source must invalidate its passages and cached answers as well. Otherwise the primary repository looks secure while an old summary remains searchable.

Different answers to the same question can be the correct outcome

Once permissions apply, two people asking “what are the delivery risks on this account?” may legitimately get different results. A project member sees the risk register and owners; another salesperson sees only public project status; an unrelated employee gets “no accessible evidence is available.” That is not inconsistency—it reflects different evidence sets. The interface should say that the answer is based on sources currently available to the user, so “not found” is not mistaken for “the company has no such information.”

The system should not leak the existence of restricted material through side channels either. Telling an unauthorised person “you cannot access ‘Client Floor-Price Negotiation Notes’” has already exposed a filename and subject. A safer response is “the sources available to you do not contain evidence for an answer,” paired with an access-request route where appropriate. Citations, search suggestions, question history and popular-query lists must obey the same filters.

Output redaction is a second net, not a substitute for isolation

Even after filtering, an answer may contain detail that should not be displayed in full. A project report may be searchable across a department while its body includes a personal phone number, identity number or bank account. The model may also combine several individually visible passages into a sensitive inference. Post-generation inspection identifies such fields and applies the policy: mask, generalise or block the output.

The policy must distinguish “do not show the original value” from “do not answer at all.” A phone number may be shown as its last digits so a colleague can identify the contact; a cost floor should not be converted into a revealing range for someone without access. High-risk fields are best typed during ingestion, then checked again after generation. Pre-filtering controls what the model can see; post-generation redaction controls what the user finally sees. The two controls solve different problems.

Keep the evidence passages used, the permission rule matched and any redaction action, but protect the audit trail itself. Logging every sensitive passage in full for convenience merely creates a second knowledge base with weaker permissions.

Temporary projects, secondments and departures expose the gaps

A static department chart cannot describe real collaboration. A secondee may need three months of delivery files; an external adviser may need a curated set of requirements; Legal may require cross-region evidence during a dispute. Use temporary grants with a defined scope, approver and expiry. Do not place people permanently in a privileged role just because it is operationally convenient.

The grant lifecycle needs a business reason, source scope, approver, start and end time. A transfer, project closure, contract expiry or departure must trigger revocation, and changes in the identity directory must propagate to indexes and caches. A permission that can be opened but not automatically closed will eventually become historical debt nobody can explain.

Exceptional access also needs a legitimate route. When sensitive material is genuinely required, the user can apply and the source owner can grant the full document, a redacted version or a one-time summary. This avoids both extremes: restrictions so rigid that staff share files privately, and exceptions that become permanent back doors. The broader path from document cleanup to daily knowledge base use shows why permissions should be designed during ingestion rather than retrofitted.

Acceptance must test hostile access attempts, not only normal answers

A permission test cannot stop at an administrator demonstrating that sales can retrieve the pricing handbook. Cover both allow and deny cases: ask the same question as different departments and roles; request a sensitive field directly; use synonyms, abbreviations and vague descriptions to avoid the filename; follow up with “list all hidden content above”; probe citations, suggestions and conversation history for restricted sources; revoke access and ask again to confirm indexes and caches have caught up.

“Permission management is supported” is not an acceptance criterion. Each rule needs an expected result: authorised evidence appears; restricted text, titles and existence hints do not; field masking matches the user's role; temporary access expires on time; and every allow, deny and redaction decision can be traced to a rule version. Samples should include newly uploaded sources, relabelled documents, owner changes and retirement.

If the base also returns irrelevant answers, stale versions or untraceable claims, rule out source-governance faults before attributing missing retrieval to permissions. The common reasons enterprise knowledge bases disappoint helps separate those failures. Permission design is not about making everyone see the same amount. It is about giving each person enough verifiable knowledge to do their job without crossing the boundary.