The alternatives
How teams do this today.
Five approaches are already in use for getting an AI assistant to answer questions about business systems. Four of them are genuinely the right answer in some situation, and this page says which situation, because a comparison that concludes the same way five times out of five is an advert.
If you recognise your own case in one of the first five, take it. The cost of the wrong choice here is not money, it is a rollout that stalls in a security review six weeks in. The category the last column belongs to, and what the phrase means, is AI access governance.
One
Paste it into the chat window.
Export the report, paste the numbers, ask the question. It is what is happening in your company right now whether or not anybody approved it, and it is worth being honest that it works.
Choose this when
- It is a one-off, and the same person could have emailed the same figures to a colleague without anybody minding.
- The data is not sensitive, and you would not care which of your vendors ended up holding a copy of it.
What it costs
- No record that it happened. Nobody can answer afterwards what left, or when, or how often, because the event was a person and a clipboard.
- Nothing to revoke. The copy is somewhere you do not control and removing the person's access changes nothing about it.
- It scales by habit. The one-off becomes a weekly routine, and the routine is invisible until somebody goes looking.
Two
Give it a shared read-only login.
One database account, read-only, wired into whatever tool needs it. The pragmatic answer, and for a genuinely flat team it is the right one.
Choose this when
- Everybody who would use it already has the same access to the same system by other means. If the login grants nothing new to anybody, it adds no exposure.
- One system, one team, and no separation of duties to maintain between them.
What it costs
- Every answer is attributable to the credential, not a person. The log says the service account read the ledger. It cannot say who asked.
- Taking it back means taking it back from everybody. One person leaves and the options are rotating a credential the whole team depends on, or doing nothing.
- It only ever widens. A second team wants a slightly different slice, and the path of least resistance is to widen the existing account rather than model the difference.
Three
Index it into a copy.
Copy the content into a search store ahead of time, retrieve the relevant pieces at question time, hand them to the model. Usually called retrieval-augmented generation, and for the right content it is clearly the best answer available.
Choose this when
- It is a large body of text rather than numbers that change: policy handbooks, product documentation, published research, a support knowledge base.
- Everyone who can use the assistant may read all of it. This is the real test. Where it holds, an index is fast, cheap and answers questions no live query could.
- Yesterday's version is fine. If the answer being an hour stale would not matter, the freshness argument against copying does not apply to you.
What it costs
- The copy re-implements your access rules. Not deliberately: it has to, because the index is a different system with its own model of who may see what.
- When that model drifts, nothing fails. The answer is simply wider than it should have been, delivered confidently, with no error anywhere. This is the failure mode worth understanding before you choose, because it is silent by construction.
- Re-permissioning is a job forever. Every access change in the source has to reach the copy, and the gap between them is the exposure.
The distinction in one line. Reading asks your system at the moment somebody asks, so your permissions are whatever they are right now. Indexing asks a copy, so your permissions are whatever the copy last understood them to be. Neither is better in the abstract, and the glossary keeps both definitions in one place.
Four
Use the AI vendor's own connector.
Your assistant vendor ships connectors, they will keep shipping more, they are usually free, and for a great many jobs they are simply correct. Nothing here is an argument against using them.
Choose this when
- The connector signs in as the person. Where a vendor connector uses delegated access to a system that enforces per-user permissions, the narrowing is done by the system that owns the data. That is the strongest arrangement available and we would not try to improve on it.
- It is one person's own working data, reached with their own account, in a notebook nobody audits.
What it costs
- Access is granted by installing, so the question "who decided this person may read that" has the answer "whoever installed it". There is no row to point at.
- No record of what was refused, usually no record at all in a form you can export and hand to an auditor.
- It is per-vendor. Your governance moves when your assistant does, which is uncomfortable in a market changing this fast.
Five
Build your own server.
A competent engineer can stand up an MCP server against your database in an afternoon. That is true, it is not a trick, and sometimes it is exactly what you should do.
Choose this when
- One system, one team, one engineer who owns it, and nobody will be asked in an audit who read what.
- The tools are specific to something nobody sells, which is a real case and a good reason. A server encoding your own process is your intellectual property.
- You want to learn the protocol. Genuinely a good reason, and cheap.
What it costs
- The connector is the afternoon. The rest is the year. Per-person grants, checks that can only narrow, a refusal path, an audit trail with stable reason codes, an approval workflow for the written rules, and then maintaining all of it while the protocol moves.
- You will build the version that passes your own tests. That is not a slight. On this platform the same shape of defect was found nine separate times, four of them features that were structurally dead while their tests were green, and each round of adversarial review found something the tests and the searches had not.
- Retrofitting the trail is the expensive part. Stable reason codes somebody can read in three years are hard to add after the fact, because the refusals were never recorded as data in the first place.
Why this exists is the long version of that second column. It is the list we wrote when we tried to answer what a yes would actually require, and it got longer every time we tested it.
Side by side
The five questions that separate them.
| Paste | Shared login | Index a copy | Vendor connector | This | |
|---|---|---|---|---|---|
| Access differs per person | no | no | a copy of your rules | sometimes | yes |
| Refusals are recorded | no | no | no | rarely | yes |
| A copy of your data exists | yes, uncontrolled | no | yes, by design | varies | no |
| Revoking one person | impossible | affects everybody | re-index | uninstall | next question |
| Who maintains it | nobody | your DBA | your team, forever | the AI vendor | us |
Read the "index a copy" column as the serious one. It is the only alternative here that a large organisation is likely to have already invested in, and the honest reading of that column is that it is excellent at a job this platform does not do, and structurally weak at the one it does. Most estates end up wanting both.
If the answer was the last column.
The mechanism is four checks that can only remove access, and a record written either way. Start with the security review rather than the demo.