Access control in AI knowledge systems: who gets to see which answer

01

Why do AI knowledge systems need their own access control concept?

An AI knowledge system copies content from many source systems into a shared index and generates new text from it. Losing those source rights is easy unless they are carried across explicitly. An answer can also expose content without showing the document itself: as a summary, a quote, a list of sources, a cached answer or a log entry.

A retrieval-augmented generation system reads content out of file shares, wikis and document management systems, splits it up and stores it in a vector database. From that point on, the source system no longer decides who can see it: the knowledge system does. And a language model rephrases it: a question about affected locations can expose a confidential plan without anyone opening a document.

The OWASP Top 10 for LLM Applications (2025 edition) lists this class as LLM08, vector and embedding weaknesses, and recommends permission-aware vector stores with strict logical separation. Knowledge management with AI places access control within the wider picture.

02

How do you carry a document's access rights through the RAG pipeline?

Rights are read from the source system together with the content during ingestion, mapped to unified identifiers for people and groups, and written to every chunk the document produces. If rights change without the content changing, the index is still updated. Deleted documents disappear from every copy, caches included.

The mapping step is where it gets critical: inherited folder permissions, sharing links and local groups all have to become identifiers from the central directory. Anything that cannot be mapped unambiguously is not interpreted generously; it stays out.

{
  "chunk_id": "doc-4711#3",
  "read": ["group:purchasing", "person:u-2081"],
  "data_class": "confidential",
  "rights_as_of": "2026-09-10T06:00:00Z",
  "content_as_of": "2026-08-28T14:12:00Z"
}

Two timestamps, because rights change more often than content: an ingestion process that only reacts to text changes will miss a group change. A deleted document has to disappear from the index, the embeddings, caches and any summaries computed in advance.

AI-GENERATEDAI-GENERATED

03

Why filter at query time instead of screening results afterwards?

Filtering at query time restricts the candidate pool to allowed chunks before the search ranks them. Filtering results afterwards has two weaknesses: the result list shrinks unpredictably, because the best candidates are often not allowed, and forbidden content still passes through steps such as reranking, logging or caching, where it can become visible.

The documentation for the PostgreSQL extension pgvector describes the volume problem: with approximate indexes, a filter only applies after the index scan. If a condition matches 10% of rows, HNSW with its default of 40 candidates returns 4 hits on average (pgvector documentation, 2026); iterative index scans keep searching further if needed. Qdrant recommends dedicated indexes for filter fields, ideally set up before ingestion.

The exposure risk matters more: with after-the-fact filtering, reranking has already read the content, and logs may already have captured it. With hybrid search, the filter applies to both the keyword path and the vector path at once.

04

How is the identity of the person asking connected to the knowledge system?

Identity comes from the organisation's central directory, usually through single sign-on with standards such as OpenID Connect. The knowledge system resolves the person's groups and attributes server-side, never from what the browser sends, and queries the index with exactly those rights. A service account with full access that searches on everyone's behalf defeats every permission.

Single sign-on is a prerequisite here. OpenID Connect Core 1.0 (OpenID Foundation) describes an identity layer on top of OAuth 2.0 that gives the application a signed ID token. The BSI recommends a central network-based authentication service in ORP.4.A18. The knowledge system therefore manages no accounts of its own.

• Resolve groups server-side: never take them from browser parameters.
• Search with the person's own rights: a service account with full access is a classic pattern behind silent data leaks.
• Reconcile accounts automatically: SCIM (RFC 7644, IETF 2015) standardises creating, changing and removing users and groups across system boundaries.
• Keep tokens short-lived: a long-lived token carries yesterday's groups.

05

Which access models suit AI knowledge systems: roles, attributes or relationships?

Role-based access is simple but becomes coarse once documents are shared individually. Attribute-based access decides by traits such as department, location or data class. Relationship-based access derives permission from relationships, such as membership of a project. For knowledge systems, carrying over the source system's document rights is usually the core, with attributes added on top.

NIST SP 800-162 (2014, updated 2019) describes ABAC as a decision made by checking attributes of subject, object and operation against rules; Google's Zanzibar paper describes a central relationship-based authorisation system. In practice, the models mix. If a person belongs to hundreds of groups, the filter on every search query grows with them, and a dedicated authorisation component becomes worthwhile.

06

What data classes does an AI knowledge system need, and what consequences do they carry?

Data classes group documents by protection need, for example public, internal, confidential and strictly confidential. For an AI knowledge system, they decide not only who can read a document but also whether it enters the index at all, which model may process it, whether answers get cached, and how much detail requests are logged with.

BSI Standard 200-2 (2017) distinguishes the protection-need categories normal (limited and manageable impact), high (impact can be considerable) and very high (impact can be existentially threatening). What matters is that every class has a technical consequence.

The most effective control is simply not ingesting something: what is not in the index cannot leak into an answer. Data minimisation here means removing personal details that are not needed before ingestion. For classes with a high protection need, Local language models explains running on an organisation's own hardware.

07

How do you log an AI knowledge system without storing personal content?

What gets logged is what traceability needs, without storing content: timestamp, a pseudonymised identifier, the rights applied, identifiers of the chunks retrieved and cited, the model version and check results. Question and answer text is not stored permanently by default. Where it is needed for troubleshooting, short retention, dedicated access rights and a documented approval apply.

Without logs, there is no way to work out why an answer was wrong (observability); with complete content, logs become the largest collection of confidential questions in the building. The way out is references rather than content. The OpenTelemetry semantic conventions for generative AI classify message content as opt-in and warn about sensitive data (specification state: September 2026). The BSI baseline module OPS.1.1.5 requires deletion under a defined process (A5) and protection against changes made by administrators (A10).

Which data protection requirements apply to logs is a question for review with an organisation's own data protection office; GDPR-compliant AI offers an overview. Checking AI answers describes spot checks for quality.

08

What changes for access control when an AI agent uses tools?

An agent acts on a person's behalf and must therefore never see or do more than that person could. Every tool retrieves data with the person's delegated rights, not with a service account that has full access. Actions that write need confirmation. Results a tool produces carry their rights with them when later steps reuse them.

An AI agent calls tools, often through the Model Context Protocol, and every connection carries its own credentials (Extending agentic harnesses). Intermediate results carry rights too: if an agent summarises a confidential document for an email, the summary inherits that document's rights. AI agents in knowledge work explains the loop and the approval points; AI security covers injected instructions (prompt injection).

09

Which BSI baseline modules serve as a reference for access control and logging?

The BSI's IT-Grundschutz compendium offers an established reference through its baseline modules ORP.4 Identity and Access Management and OPS.1.1.5 Logging, supplemented by CON.1 Cryptography Concept, CON.6 Deletion and Destruction, and OPS.2.2 Cloud Usage. The modules name no AI-specific cases, but their principles, such as least privilege and protected logs, carry over directly.

• ORP.4 Identity and Access Management

  2023 edition

  Rights only as needed (A2), defined granting and revocation (A7), standard rights profiles (A16), central authentication service (A18).

• OPS.1.1.5 Logging

  2023 edition

  Scope set by protection need (A1), deletion under a defined process (A5), protection against changes made by administrators (A10).

• CON.1 Cryptography Concept

  2023 edition

  The index, embeddings and backups are copies of the sources and belong in the same encryption concept.

• CON.6 Deletion and Destruction

  2023 edition

  Deleted documents leave behind chunks, vectors and cached answers.

• OPS.2.2 Cloud Usage

  2023 edition

  A reference as soon as the index, the model or monitoring runs at a cloud provider.

The BSI has announced Grundschutz++, a successor that replaces the compendium with a machine-readable rule set; the underlying principles stay useful regardless. The BSI publication Generative AI Models: Opportunities and Risks for Industry and Public Authorities (2025) describes the risks of generative models across their lifecycle. On connecting to existing systems: API, MCP or CLI.

10

How do you test whether an AI knowledge system honours access rights?

Testing uses accounts for different roles together with marker documents: documents carrying a unique, invented term that only one group may read. If the term shows up for another account in the answer, the sources, suggestions or the cache, the filtering leaks. Tests for revoked rights, deleted documents and logs come on top of that.

1. Test accounts per role

   Set up in the central directory, plus one account with no special rights.

2. Marker documents

   An invented term that appears nowhere else, shared with only one group.

3. Ask from every account

   Directly, rephrased, and by asking for a summary of entire areas; check suggestions and sources too.

4. Revoke rights and delete

   Measure when the term disappears, including from the cache and any summaries.

5. Check logs and lock the process in

   The term must not appear there in plain text; all these checks should run automatically with every change.

11

Which misconceptions about access control in AI systems persist?

Five assumptions persist: that an instruction to the language model protects confidential content, that embeddings reveal no content, that filtering afterwards is enough, that a separate index per department solves the problem, and that running locally makes access control unnecessary. Each one shifts control to a place that cannot deliver it.

On-premise vs. cloud LLM covers when running on-premise pays off for other reasons.