Permission-scoped AI retrieval

What permission-scoped retrieval is

Every AI feature that retrieves deal documents to answer with goes through one retrieval function, and that function applies the same per-folder access check as the file tree, before ranking. Data-room chat, Q&A drafting, request drafting and request-to-document matching all call it. One path sits outside it: the keyword step that suggests supporting files when your team publishes a Q&A entry, which is open to advisory roles only. Set folder permissions once and the AI inherits them. There is no separate index to keep in sync, and no toggle deciding whether AI features respect the access control list.

Ask any VDR vendor two questions. Which index does your assistant read? Does the access check run before or after ranking?

What it changes on a live deal

The same question gets different, correct answers for different people.

• A bidder asking data-room chat about customer concentration is answered from the documents that bidder can open.
• The deal team asking the same question also gets internal material, because they can open it.
• A draft going to the other side narrows again, to what that side can read, not what the drafter can read.

One function covers data-room chat, Q&A answer drafting, due-diligence request drafting, and matching documents against a request list. One place to review, and one place a regression shows up.

How the filter works

1. Embed the question and cosine-score every stored document vector.

2. Drop anything below the relevance floor. This is an optimization, because comparing vectors in memory is cheap and walking the access list touches the database. It can only remove a candidate, never admit one.

3. Apply the folder-read check to each surviving document's parent folder. This is what decides admission.

4. Sort and cut to top-K over the admitted set only.

Why before ranking? So that top-K counts only readable documents. A restricted file cannot take a slot and then get stripped, leaving the asker with a thinner answer and no explanation. It never enters the candidate list, so it never reaches the model's context.

Whose permissions? The check resolves a folder to an access grade in fixed order: a per-user override, over a grant to that user's org, over grants inherited from ancestor folders, over the org-wide default. That is the same resolution the folder tree and the download gate use.

Drafts the counterparty will read

Two gates, both server-side.

Scope before generation. CogniSuite resolves the request's parent list, enumerates every org that can see that list and is neither the advising firm nor its client, and admits a folder only if every one of those orgs may read it. That is an intersection, so widening who can see a list can only narrow what the draft may quote. Org-level checks ignore per-user overrides, so one person's elevated grant cannot widen the baseline for their org. Ambiguity denies: an unresolvable list or an unconfirmed owner org returns a deny. The Q&A equivalent defaults to admitting nothing.

Verification after generation. The model returns a structured draft through a forced tool call. The server then checks it: every citation must resolve to a document inside the permitted set, and every quote must be found in that document's extracted text, matched with whitespace normalised and an alphanumeric-only fallback so extraction artefacts do not discard a real quote. 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 it stops

• View-only is not confidentiality. Retrieval admits any folder above "none", including the watermark and view tiers, so the AI can quote a document a reader may view but not download. If the text is the sensitive part, move the document out of reach.
• Semantic search is a second implementation. It applies the same folder check with a stricter relevance floor, so the access guarantee holds, but the rule lives in two places rather than one.
• Documents without an embedding are invisible to retrieval. Enrichment runs asynchronously and is best effort, so a failure leaves a file stored and viewable but not retrievable, with no indicator in the interface. Reprocessing is available to the deal team.
• Injection defences are prompt-level. They reduce the risk that text inside a document is treated as an instruction, and enforce nothing on their own. The boundary is the per-deal database, the access check, and the quote verification.
• One vector per document, over truncated text. Retrieval locates documents rather than passages inside them, and scores every vector on each query. That suits a normal diligence room, not one with tens of thousands of files.

Cross-deal isolation is a separate matter. Each deal is a physically separate database file on its own subdomain, and retrieval is scoped to the handle resolved for that request. The connection has no route to another deal's data, so the query cannot be written.

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