Permission-scoped AI retrieval

What permission-scoped retrieval changes on a live deal

Set your folder permissions once. The AI inherits them. There is no second permission model to configure for the assistant, no separate index to keep in sync, and no toggle that decides whether AI features respect the access control list, because they cannot do anything else.

The practical effect is that the same question produces different answers for different people, correctly. A bidder asking the data-room chat about customer concentration gets an answer grounded in the documents that bidder can open. A member of the deal team asking the same question gets an answer that also draws on internal material, because that person can open it. When the AI drafts a reply that will be shown to the other side, the grounding set narrows again, to what that side can read, not what the drafter can read.

This is worth saying plainly, because an assistant added to a document platform after the fact can end up reading a general index rather than a permission-resolved one. The retrieval path here takes the folder-read check as an argument from its caller, so a feature cannot opt out of it. CogniSuite's retrieval is filtered by the same per-folder access control the file tree and the download gate use, in one shared function, applied before ranking. Ask any vendor which index its assistant reads, and whether the access check runs before or after ranking.

Why a retrieval leak is harder to contain than a file permission bug

A conventional permission bug exposes a file. Someone opens something they should not have, and the access log records it. You know what was seen, by whom, and when. The remediation is unpleasant but bounded.

A retrieval leak is worse in three specific ways.

It produces no view record. The recipient never opened the document, so there is no document view to find in the audit trail. The content arrived as prose inside an answer.

It concentrates rather than exposes. A summarizer takes the sensitive part of a restricted document and states it directly. The reader does not have to know what to look for.

It cannot be undone. On a competitive process, internal price expectations or one bidder's position reaching another bidder is a problem for the integrity of the process, not a hygiene issue. There is no way to un-disclose it.

Deal teams are right to treat this as the question to ask before they let an AI feature near a data room.

How one shared retrieval path enforces the rule

Every AI feature in CogniSuite that grounds an answer in deal documents calls the same retrieval function. That includes data-room chat, Q&A answer drafting, due-diligence request drafting, and matching a request against the documents in the room. The function takes a folder-read check from the caller and applies that check itself, to each candidate document, before the document can enter the result. Those features do not carry their own copy of the permission logic.

Two paths sit outside that function and should be named. Semantic search is a separate implementation with its own scoring loop and its own, stricter relevance floor. It applies the same folder-read check, so the access guarantee holds, but it is a second place that rule has to stay right rather than the same place. And the step that proposes supporting files when a private thread is rewritten for the shared question board does not use retrieval at all: it keyword-matches the question against document summaries, and it applies no folder check. That step is available only to the deal team, whose access is unrestricted in any case, so it is a consistency gap rather than a disclosure one. Neither is covered by the guarantee above, and a reader auditing this claim should ask about both.

One implementation is easier to keep correct than five. If five features each implement their own filter, that is five chances to get it wrong, and a sixth chance every time a new feature is built. A retrieval filter that is wrong fails silently: the feature still returns an answer, and the answer looks fine. There is no error to catch and no failed request to alert on. With one path there is one place to review, one place to test, and one place a regression shows up.

For a normal user, the check resolves a folder to an access level in a fixed order: a per-user override sits over a grant made to that user's org, which sits over grants inherited from ancestor folders, which sits over the org-wide default. That is the same resolution the folder tree, the viewer and the download gate use. It is not a parallel implementation written for the AI.

Why the filter runs before ranking rather than after

The sequence is: embed the question, score every stored document vector by cosine similarity, drop anything under the relevance floor, then apply the folder-read check to each surviving document's parent folder, then admit it as a candidate. Sorting and the top-K cut happen over the admitted set only.

The similarity floor runs first purely as an optimization, because comparing vectors in memory is cheap and walking the access control list touches the database. It can only ever remove a candidate, never admit one. The access check is what decides admission.

The consequence is that top-K counts only readable documents. A restricted document cannot occupy a slot in the retrieved set and then get dropped, which would leave the asker with a thinner answer and no explanation of why. It never enters the candidate list, so it never reaches the model's context at all.

How counterparty-facing drafts are scoped to the counterparty

When the AI drafts an answer that a counterparty will read, "what can the drafter see" is the wrong question. The scoping step resolves the request's parent list, then enumerates every org that can see that list and is neither the advising firm nor its own client: by owning the list, by an explicit share, or, on the sell side, because the list has reached a review status the client can see. A folder is admitted only if every one of those orgs may read it. That is an intersection, not a union, so widening who can see a list can only narrow what the draft may quote. The org-level check deliberately ignores per-user overrides, so one person's elevated grant cannot widen the baseline for their org.

The path fails closed at every ambiguity. If the owning list cannot be resolved, if its data cannot be decrypted, or if the owning org cannot be positively confirmed as the advising firm or its client, the check denies everything. The Q&A equivalent behaves the same way: it scopes to the thread creator's own access and defaults to admitting nothing unless that creator resolves to a buyer-side role. When the scope cannot be resolved, the draft says the material is not available. The deal team then writes the answer manually.

A second gate runs at render time. Every citation the model produces must resolve to a document inside the permitted set that was passed in, and every quote must be a verbatim substring of that document. Citations failing either test are dropped. An affirmative answer left with no surviving citation is replaced with a line routing it for manual review.

Where this stops

Retrieval admits any folder whose access level is not "none", which includes the view-only and watermark tiers. The AI can therefore quote text from a document a reader may only view watermarked and may not download. If the text itself is the sensitive thing, view-only is not the right control. Put the document where the reader has no access.

Intersection scoping can produce an empty grounding set on a widely shared request list, and the draft will then say the material is not available without explaining that the cause was scope rather than absence. The deal team needs to read that outcome correctly.

Documents with no embedding are invisible to retrieval. Enrichment runs asynchronously and is best effort, so a failure leaves a document stored and viewable but not retrievable, with no indicator in the interface. Reprocessing is available to the deal team.

Injection defences written into the prompt reduce the risk that text inside a document is followed as an instruction. They enforce nothing on their own, because a model can be argued out of an instruction. The boundary is the per-deal database, the access check applied before retrieval, and the server-side quote verification.

Retrieval works on one vector per document over truncated text, so it locates documents rather than passages inside them, and it scores every document vector on each query. That is appropriate at the scale of a normal diligence room and is not a design for a room with tens of thousands of files.

Why deal isolation does not depend on a rule being applied

Each deal is a physically separate database file, served from its own subdomain, with its own users, sessions, access grants and audit table. Retrieval is scoped to the database handle resolved for the request. A query on one deal cannot surface another deal's documents. No rule in the code prevents it. The connection has no route to another deal's data, so the query cannot be written.

More detail on the access model, encryption and logging is on our security page.