RAG Access Control Starts at the Connector: Permissions That Survive Ingestion

A connector looks like plumbing. Point it at Slack or SharePoint, wait, and the documents show up in your knowledge base ready to answer questions. That framing is why so many enterprise AI rollouts quietly become data leaks: the plumbing copies the documents and loses the one thing that made them safe to store — who was allowed to read them.

RAG access control is decided long before anyone asks a question. The real job of a connector is not to move content. It is to carry each document's access-control list across intact, and to keep the identity graph — which person belongs to which group — current enough that a permission check at query time still means something. Get that right and retrieval can be permission-aware. Get it wrong and you have built a fast, confident way to answer a question with a document the asker was never cleared to open.

Why is a connector a permission problem?

Every source system already knows who can read what, and it says so in its own dialect. A connector's first responsibility is to translate that dialect faithfully, and to fail safe when it cannot.

• Slack. A thread is a document and its channel is the folder; a private channel carries its members as the people who may read it.
• File storage. A file in OneDrive, Box or Dropbox inherits the sharing on its folder.
• Email. A mailbox is private to the person whose mailbox it is.
• Code. A private GitHub repository is readable only by its collaborators.
• Notion. An integration sees nothing until someone explicitly shares a page with it — so an empty result is reported as "share the pages first", not as a successful sync of zero documents.

Behind these sits one uniform model. Every connector authenticates through the same token broker, which holds credentials sealed and refreshes them before they expire, and every connector writes into the same permission model. What differs between them is only the dialect each source speaks about access — and that is exactly the part that must not be papered over. It is how Connect is designed.

How do you make ingestion fail closed?

The discipline that makes ingestion safe is monotonous, and the monotony is the point. Every decision defaults to less access, not more.

• No permissions means closed. A source with no permission rows is readable by nobody but an administrator — never treated as public. That single default decides the direction every mistake fails in.
• Permissions before content. Because "no rows" means "closed", permission rows are written before the content and never left empty, so a document is never briefly readable by everyone while its grants are built.
• A failed lookup restricts. If the connector cannot confirm the membership of a private channel, the source is locked down rather than opened.
• Private by default. Mailboxes and private repositories start restricted to the connecting account and widen only when someone explicitly says so.
• Whole-segment paths. A grant on /Finance never leaks /Finance Archive.
• Atomic re-sync. When a source is re-synced, its permissions are replaced in one operation, so there is no moment when the old rows are gone and the new ones are not there yet.

Why should reading and writing be separate?

Ingesting a source is reading it. Acting on it — posting a reply, updating a ticket, closing an issue — is a different power, and it is granted separately.

Connector scopes split three ways: baseline scopes cover the connection, read scopes are added only when a source is ingested, and write scopes are added only when someone explicitly grants the ability to write back. Indexing a drive for search does not also confer the right to overwrite files in it. When write is granted, it belongs to a connection that can be revoked at once, without a redeploy.

Two more defaults protect the most expensive mistakes. A write with several accounts connected and none named is refused rather than guessed at. And a reply into a customer's helpdesk defaults to an internal note, not a message the customer sees. Every write then runs through the governed action lifecycle.

How do deletions reach the index?

There is a failure mode specific to a copy: a document deleted at the source that keeps answering questions from the index.

Where a source offers a real change feed, a deletion is reported and the document is removed promptly. Where it does not, the connector runs a full listing and treats anything no longer present as gone. Content is reconciled by fingerprint — an unchanged document is skipped, a changed one has its old chunks replaced, a removed one is pruned — and a periodic full sweep backs up the connectors that cannot see a deletion in real time. "This file was deleted last week" becomes true in the index in bounded time, not never.

How to evaluate a connector

Do not watch a connector import documents; watch it import a restricted one. Ingest a private channel or a permissioned folder, then ask a question as someone who was never a member. The answer should be nothing. Then break the connector's ability to read the membership and ingest again: a well-built connector locks the source down.

The same permissions are what make every answer traceable later — see what an AI audit trail should prove.

Frequently asked questions