Permission-Aware Enterprise Knowledge
An internal AI search and answer system that treats access control as an architectural requirement.
- Reference architecture
- Concept
- Application evidence
- Not implemented
- Data
- Synthetic dataset proposed
- Test boundary
- Plan only · tests not run
This is an unbuilt reference concept. The architecture and verification structures below are proposals, with no running application, test results or client deployment claimed.
Access is decided
before an answer exists.
The proposed design carries source permissions through ingestion, retrieval and citations. A model does not decide who can see a document. Two employees can ask the same question and correctly receive different evidence.
Proposed architecture · no connected services
- Identity + groupsExisting SSO supplies the principal.
- Current source permissionsResolve the permitted retrieval scope.
- Authorized retrieval onlyFilter before restricted text reaches inference.
- Cited answer / no answerExact source version, freshness and access remain inspectable.
Denied content stays outside the answer, shared cache and logs.
The test is the
evidence withheld.
Proposed verification plan. No application or tests have been run. Build a synthetic corpus with three fictional identities, 30 documents, conflicting titles, a superseded policy, a deleted page and a restricted memo.
Scroll the verification table to inspect the evidence column.
| Challenge | Required behavior | Evidence to retain |
|---|---|---|
| Exact title, no entitlement | The restricted source contributes neither retrieval text nor a summary. | Authorized scope and retrieval IDs, without restricted content in logs. |
| Permission revoked or source deleted | Access changes propagate within a documented synchronization SLA. | Change event, index state, retrieval decision and measured propagation. |
| Same query, different identity | Cached results retain user and tenant boundaries. | Separate authorization contexts and permitted source sets. |
| Stale, hostile or insufficient evidence | Cite the correct authorized version; ignore source instructions; allow no answer. | Version/anchor checks, adversarial cases and insufficient-evidence results. |
Before building a retrieval stack.
Inspect the governed search and answer capabilities already available in the organization. Mixed systems, specialized workflows, tenant boundaries and provenance requirements may justify custom engineering; a familiar chat interface alone does not.
A common enterprise AI request is deceptively simple: let employees ask questions about company knowledge. In a large organization, knowledge is not a single pile of text. It is an overlapping network of source systems, versions, permissions, ownership and retention policies.
This reference design tests whether an AI assistant can answer a user from only the information that person is actually entitled to see, cite its sources, and clearly say when it does not have an answer.
The user journey
An employee asks a question in a simple search-first interface. The assistant identifies its authorized retrieval scope, searches indexed and live sources where appropriate, returns a concise answer with verifiable citations, and shows last-updated information. Clicking a citation opens a source document only if the user's existing access permits it.
The same question asked by two employees can legitimately produce different answers. That must not be treated as a retrieval bug. It is a consequence of access rules.
System design
Identity: SSO identity and group membership are carried through to retrieval; the model itself never decides permission.
Sources: Synthetic policy, maintenance and product documents with version and ownership metadata.
Ingestion: Connectors normalize and chunk documents, carry source IDs, metadata and ACL references, record indexing failures and maintain deletion/revocation propagation.
Retrieval: Query rewriting and hybrid search as appropriate, filtered by current authorized source permissions before any restricted text reaches inference.
Generation: A replaceable model adapter constructs responses from authorized evidence, surfaces uncertainty and allows a no-answer result.
Observability: Trace retrieval IDs, grounding and citation consistency using redactable logs without exposing restricted content in analytics.
Test identities and content
Create three fictional users: a field technician, a regional supervisor and a finance administrator. Create 30 synthetic documents with carefully different permissions. Include two identical document titles in different departments, a policy superseded by a new version, one deleted page and a confidential memo that never appears to the field technician.
Negative tests
- A user who cannot access a source must not receive a summary of that source, even when the question includes its exact title.
- Revoking a permission must prevent retrieval according to a documented synchronization SLA.
- A source citation must point to the exact authorized version and page or document anchor.
- A document with malicious instructions must not change the assistant's data-access scope.
- Queries that lack authorized evidence should receive a safe insufficient-evidence response.
- Logs and monitoring should not create a secondary exposure path for restricted content.
- Search caching must preserve user and tenant boundaries.
The make-or-buy test
A Microsoft 365 environment may already have a governed way to answer many of these questions. Before building a custom retrieval stack, inspect existing entitlements, connector support, licensing, UX needs, provenance requirements and policy behavior. Custom engineering may be warranted for mixed systems, specialized workflows, tenant boundaries or product experiences not served by an existing platform.