
ACLs That Survive a Resync: Keeping Connector Permissions Correct
The hard part of permission-aware AI isn't checking access once — it's keeping the source system's permissions correct as connectors re-sync. A naive integration can quietly turn a restricted document into an open one.
- Dmytro SheinSolution Architect
In this article
Permission-aware retrieval only works if the permissions are right, and keeping them right is harder than it sounds. Connectors to systems like SharePoint, Confluence, and shared drives re-sync continuously, and every resync is an opportunity to lose or flatten the source's access controls. Get it wrong and a restricted document quietly becomes readable to everyone — a breach nobody notices until it's exploited.
Why one-time permission checks aren't the problem
Checking access at the moment of a query is the easy part, and most systems get it right. The hard part is that the permissions themselves have to stay accurate over time. Source systems are alive — documents get reclassified, groups change, sharing is revoked — and the AI's copy of who-can-see-what has to track those changes. A permission check is only as good as the access data it checks against, and that data is exactly what a resync can corrupt.
How a resync breaks permissions
When a connector re-ingests content from a source, it has to re-capture the access controls along with the content. A naive connector treats the content as the payload and the permissions as an afterthought — so it re-imports the document but loses, flattens, or fails to update the ACL. The result is a document whose content is current but whose permissions are wrong, often wrong in the dangerous direction: a file that was restricted in the source is now readable in the AI's index.
A resync that keeps the content but loses the permissions turns a restricted document into an open one — silently.
Permissions as first-class payload
The fix is to treat the source's access controls as first-class data that's re-captured with the same rigor as the content, on every sync. When a document is re-ingested, its current permissions are re-ingested too, so the AI's enforced access always reflects the source system's present state — not the state at first setup. Permission-aware retrieval then has accurate data to enforce against, which is the whole point. Correct enforcement over stale permissions is still a leak.
Detecting drift, not assuming correctness
Because a permission error is invisible until exploited, you can't just assume the sync worked. The safe posture is to treat permission accuracy as something to verify, not assume — reconciling the AI's access model against the source and surfacing discrepancies rather than trusting that every resync preserved everything. A silent leak is the worst kind, so the goal is to make permission drift loud instead of invisible.
Why this is a security control
ACL integrity through resync isn't a data-plumbing detail; it's the foundation the entire permission-aware story rests on. All the retrieval-time access checking in the world is undermined if the permissions being checked are stale. Getting resync right is what lets you actually trust that an AI answer only drew on what the user was entitled to see — which is the claim the whole approach is built to make. It's security work wearing a plumbing disguise.
Frequently asked questions
Keep the permissions as current as the content. See how connectors re-capture source ACLs on every sync and surface drift — so permission-aware retrieval enforces the truth, not a stale snapshot. Book a walkthrough.