Connecting an AI to your knowledge base creates a problem you may not have considered: who gets to see what. Most platforms leave this problem half-solved, and the gaps are not always obvious until something goes wrong.
Imagine an account manager and a finance director ask your enterprise AI the same question: “What’s the full financial picture for the Meridian account?” In most AI deployments, they get the same answer. That answer includes internal margin analysis, payment history, and credit risk flags – information the account manager was never supposed to see.
Nobody intended this. The permissions probably looked fine on paper. But the AI does not care what the permissions looked like on paper; it simply surfaces whatever it can retrieve. And if access controls are not enforced at the right layer, retrieval is not controlled.
Enterprise AI deployments face three distinct access control problems: enforcing what each user can retrieve, keeping entire domains structurally separate, and being able to prove what was accessed after the fact. Most platforms address one of these. Few address all three.
Where most platforms enforce access – and why it’s the wrong place
The standard approach to access control in software is to restrict what users can see in the interface. A junior employee sees a filtered view; a senior employee sees more. This works well for traditional applications where the interface is the gatekeeper.
AI systems break this model because they do not present information – they synthesise it. The model reads from a knowledge base and generates a response. If the knowledge base is not controlled upstream of that synthesis, the interface cannot reliably contain what comes out.
Controlling access at the UI level means the AI itself has already retrieved the content. It has already reasoned over material the user was not supposed to see. Even if the response is filtered, the reasoning path was not. In some cases, sensitive information leaks through anyway – in a paraphrase, an inference, a synthesis that happens to surface a number the user had no right to know.
The reliable fix is retrieval-layer enforcement: permissions are checked before retrieval runs, and the knowledge base is filtered accordingly. From the AI’s perspective, content the user cannot access simply does not exist.
Scope and capabilities: two concepts most systems conflate
A properly built access control architecture distinguishes between two separate dimensions that are often treated as one.
The first is scope: which knowledge bases a user or team can access. This is determined by group membership. An account manager belongs to the Sales group and can access commercial knowledge bases. A finance director belongs to Finance and can access those plus margin and risk data. The Meridian example above is a scope difference – the finance director sees more because their group membership grants access to an additional knowledge base, not because they have a different “role” in the system.
The second is capabilities: what actions a user can perform within the knowledge bases they can access. Can they search only, or also export? Can they administer content, or only read it? These are role-level permissions that operate independently of scope.
Keeping these two dimensions separate makes the access model both cleaner and easier to audit. Scope answers “what can you see?” Capabilities answer “what can you do with it?” Conflating the two produces configurations that are difficult to reason about and harder to verify.
Granularity matters within scope as well. Coarse controls – “can access Sales content” or “cannot access Finance content” – leave wide margins for error. Effective systems enforce scope at the level of domain, folder, and document. For structured data, the cleaner approach is to store sensitive fields separately and apply metadata filtering or query-time joins at retrieval – rather than trying to enforce field-level boundaries inside chunked documents, which adds significant ingestion complexity and is difficult to maintain reliably.
Two-pass enforcement: closing the gap retrieval-layer controls leave open
Retrieval-layer enforcement is necessary. But it is not sufficient on its own. A well-designed system adds a second, deterministic enforcement step after retrieval that operates independently of the AI model.
Here is why this matters: a retrieval filter is a rule applied before the model sees anything. But the model itself can be manipulated – through prompt injection, where adversarial content in retrieved documents attempts to instruct the model to reference material outside its permitted scope. If the only protection is a retrieval filter, a sufficiently crafted injection can circumvent it.
A second enforcement layer – one that runs in code, not in the model – checks after retrieval that nothing out-of-scope was surfaced before the response is generated. Because this check lives outside the model, it cannot be confused or overridden by content inside the model’s context. The two-pass approach – filter at retrieval, verify independently after – is what makes access control robust rather than merely present.
Structural isolation: architecture, not configuration
Role and scope controls handle individuals well. But many enterprises also need to keep entire departments or client accounts completely separate from each other. For this requirement, separate knowledge bases are the right solution – not permission flags on a shared one.
Configuration-level controls – flags that prevent queries from crossing domain boundaries – are vulnerable to misconfiguration. A change in the deployment process, an update to the platform, a misconfigured integration – any of these can silently disable a flag-based control. When the control is configuration, the control can be broken by configuration.
Structural domain isolation removes this vulnerability. Each domain – each client, each department, each practice group – has its own physically separate knowledge base. There is no shared context for queries to inadvertently cross. The AI working in one domain has no knowledge of another domain’s documents – not because it has been told not to look, but because those documents genuinely do not exist in its environment.
Consider a global law firm. An employment lawyer asking about “the Ashford Partners deal” does not receive an access-denied message if that deal lives in a structurally separate M&A knowledge base. The AI returns nothing at all. From its perspective, those documents do not exist. This is not a policy outcome, it’s an architectural one.
The trade-offs are worth naming: structural isolation makes cross-domain knowledge sharing harder by design, and it adds operational overhead for each domain. Access control also shifts – scope decisions become decisions about which knowledge bases a user’s group can access, rather than which documents within a shared base. This is where the second enforcement pass described above closes the loop: even with separate knowledge bases, a deterministic post-retrieval check ensures that group-based routing cannot be misconfigured into granting unintended access.
The third problem: knowing what happened
Access control prevents the wrong people from accessing information. But in regulated environments, that is not sufficient. You also need to be able to prove, after the fact, what your AI system accessed and why.
The question that matters in a compliance incident is not “could this have happened?” but “did this happen?” If your AI system cannot reconstruct which documents were retrieved for a given query, which documents contributed to a given response, and what the AI generated on the basis of them – you cannot answer that question. And if you cannot answer it, you have not truly controlled access – you have only hoped nothing went wrong.
An audit trail at the AI layer closes this gap. Every query, every retrieval event, every generated response is logged with full provenance. When a regulator asks whether the AI disclosed confidential information in a client-facing interaction three months ago, the answer can be precise rather than approximate.
This is not a feature most organisations think to ask for when evaluating AI platforms. It only becomes urgently relevant when something goes wrong.
What to check in any enterprise AI deployment
Three questions will tell you whether access control has been properly implemented:
- Is access scope enforced at the retrieval layer – and verified again by a deterministic, model-independent check after retrieval? Only this two-pass approach is robust against both misconfiguration and prompt injection.
- Is domain separation structural (separate knowledge bases) or configuration-based? Structural separation cannot be misconfigured.
- Can the system reconstruct, for any interaction, which knowledge bases were queried, what was retrieved, and what the AI generated from it?
If any of these get a vague or qualified answer, the access model is not complete. Connecting an AI to your knowledge base without solving all three does not create a useful tool, it just creates a liability.
About the author
Marian Rams
Head of IT Solutions at emagine
Marian Rams is emagine's Head of AI Solutions, leading the design and delivery of agentic AI platforms from architecture through to client delivery. His background in distributed systems and cloud-native architecture shapes his approach: reliable foundations first, intelligence layered on top. He also builds and leads the teams that bring these platforms to life.