An internal copilot that only shows what you may see
Staff ask in plain language; the copilot answers from HR, engineering, finance and operations content with the same permissions as the source systems, enforced inside every search.
Organisations where the answer exists, but finding it means asking around
The internal copilot is for the questions that interrupt people all day: what is the expenses policy for taxis, where is the runbook for the payment service, which template do we use for a supplier contract.
These questions are easy to answer and expensive to leave unanswered. They are also the questions where a naive assistant causes real harm, because the answer to "what is the redundancy process" must not come from a confidential HR document the asker should never see. Permissions are the whole problem, and this page explains how we solve it. For the wider operating model, read knowledge management.
Outcomes we design for
Every answer respects SharePoint, Confluence, Drive and chat permissions
Staff with limited access still get good answers from what they can see
Sources are cited and open in the original system
Live personal data comes from tools with the user's own identity
Permission changes reach the index within a measured window
Every question and answer is logged for audit, with no forbidden text in the logs
The mechanism
Filter inside the search rather than after it
The difference between a safe internal copilot and a data leak is where the permission check runs. The diagram shows both designs with the same question.
Design A attaches the user's groups to the query and the index applies the access-control filter while searching, so the top results are all permitted and the prompt is full. Design B searches everything, drops the forbidden results afterwards, and often has nothing left to answer with, having already fetched and logged text the user may not see.
In practice this means every chunk carries an allowed-principals list, and every search includes a metadata filter on the caller's groups. PostgreSQL with pgvector does this with an ordinary WHERE clause; Milvus does it with a filter expression that runs before scoring. Either way the forbidden content is never a candidate. The same principle underpins our secure RAG architecture.
Source systems
How permissions in each system become a filter on the index
Every source models access differently. The job of the connector is to compute who may read each item at sync time and keep that list current.
Source
Native permission model
How it reaches retrieval
SharePoint and OneDrive
Site, library and item permissions via directory groups
Effective groups resolved at sync and stored on each chunk; the user's groups come from the SSO token at query time
Google Drive
Per-file sharing with users, groups and domain-wide links
Allowed principals stored per chunk; group membership expanded on a schedule; "anyone in the organisation" mapped to a domain principal
Confluence
Space permissions plus page-level restrictions
Effective readers computed per page; restricted pages re-synced on change events, spaces reconciled nightly
Slack and Teams
Channel membership; private channels and direct messages
Public channels indexed with the workspace principal; private channels only with their member list; direct messages never indexed
HR systems (including our own ZekoHR)
Role-based: own record, direct reports, HR admin
Policies and handbooks indexed as documents; personal data served by a tool call under the user's identity, never embedded
Databases and data warehouses
Row-level security and views
Public reference tables summarised and indexed; everything else queried live through a tool with the user's credentials
Ticketing and CRM
Queue, team and record ownership
Owner and team fields stored as metadata; sensitive fields excluded at ingest, not masked later
What we deliver
The copilot, the connectors and the controls around them
Identity integration
Single sign-on with your identity provider; groups, role and region carried into every request and every log line. No service-account shortcuts for retrieval.
Permission-capturing connectors
Connectors for the sources in the table above, each computing effective readers at sync and reconciling on a schedule. Sync lag is measured and shown to administrators.
Filtered hybrid retrieval
Keyword and vector search with the access filter inside the query, plus reranking. Built on pgvector or Milvus in your environment, chosen with our selection guide.
Tools for live data
Leave balances, ticket status, directory lookups and similar values come from MCP tools that call the system of record as the user. Nothing personal is embedded.
Guardrails and audit log
Injection screening, refusal rules for out-of-scope requests and a per-question log with sources. Logs store chunk identifiers, not forbidden text.
Permission test suite
Synthetic users in each role ask the same questions; the suite asserts that no answer or citation crosses a permission boundary. It runs on every release.
How we work
Source by source, with permissions proven before content is indexed
Source and permission audit
Two weeks. For each candidate source we document the permission model, the owner, the content quality and the sync options. Sources with unclear ownership wait.
Identity and filter design
Principal model, group expansion, token handling and the filter expression per store. The permission test suite is written now, before any content is loaded.
Connect and index
Connectors built one at a time, each passing the permission suite before the next starts. Content fixes from the audit feed into a migration where needed.
Pilot with real roles
A pilot group spanning departments and access levels uses the copilot for two to four weeks. We review unanswered questions and any permission edge cases weekly.
Launch and operate
Rollout by department, administrator dashboard, runbooks and a handover to your platform team. Optional retainer for new sources and tuning.
What goes wrong when permissions are an afterthought
The common failure is a pilot built with a service account that can read everything. It demos well, and then legal or the works council asks how access is enforced, and the honest answer is "it is not". Retro-fitting permissions means re-ingesting every source and re-testing every path. It is far cheaper to design the filter first and load content second, which is why our process does it in that order.
Two reasons. First, if the top results are mostly documents the user cannot see, dropping them afterwards leaves too few passages to answer from, so quality collapses for exactly the people with the least access. Second, the forbidden text has already been fetched, scored and often logged, which is a data-handling failure even if the user never sees it. Filtering inside the query avoids both.
How do you keep permissions in sync with the source systems?
Each connector captures the effective readers of a document at sync time and writes them as metadata on its chunks. Permission changes trigger a re-sync for that item where the source supports events, and a scheduled reconciliation catches the rest. The gap between a permission change and the index reflecting it is measured and reported.
Can the copilot answer questions that need live data, such as my leave balance?
Yes, but not through retrieval. Personal or fast-changing values come from a tool call to the system of record, made with the user's own identity, so the HR system applies its own permissions. We build these as MCP servers so the same tools work across assistants.
Where does the data and the model run?
Inside your tenant or VPC. The vector store is PostgreSQL with pgvector or Milvus under your control, and the model can be a regional cloud endpoint or a self-hosted open-weight model. Options and trade-offs are on the AI data privacy page.
How long does an internal copilot take?
Typically 8–12 weeks for a first release over two or three sources with a pilot group of a few hundred staff. Permission mapping for each source is the main variable, so we scope it source by source. Tell us which systems you want covered.
Talk to us about your AI project
Tell us what you are trying to do, which systems are involved and what is in the way. We reply within one business day with an opinion and a suggested next step.