AI and confidential data: what a connector has to refuse

Four in ten professionals name access to confidential data as their main concern about AI. The answer is not to forbid it: it is knowing exactly what the server refuses — and in the right place.

In a recent survey of the Brazilian marketing industry, 40% of respondents named access to confidential data as their main concern about using AI. It is the right concern, and it usually gets two bad answers: forbid it, which pushes the team into copy-pasting into a personal tool; or allow everything, which is the same thing in a better mood.

The useful answer is a list of specific refusals. If you are evaluating a connector, that is what to ask — and the answer has to be about the server, not the prompt.

Why an instruction is not protection

There is a temptation to solve this in the prompt: "you may only query client X's tables". That is not access control. It is a polite request to the model, and it will be honoured most of the time — which is exactly the problem with any protection that works most of the time.

A control that lives in the prompt is a suggestion. A control that lives in the server is a rule. Only the second survives a change in the conversation.

The seven refusals that matter

1. 01A query naming another client's schema. If the model can write SQL, it can write another project's name. The refusal has to happen when the query is parsed, before it runs.
2. 02Global tables. Every multi-tenant platform has raw tables where everyone's data coexists before being separated. They cannot be within reach.
3. 03Any statement that writes. An analytics connector does not need create, alter or delete. If a tool is declared read-only, the server has to refuse the write at call time — declaring is not enforcing.
4. 04Remote table functions. Several databases let a query read from an external address. It is the shortest path between an innocent query and an exfiltration.
5. 05System tables. They describe the structure of everything on the server, including what is not yours.
6. 06Queries with no ceiling. A badly formed question can scan terabytes. On one Sunday night we measured, a single project scanned 1.47 TB, and more than a hundred queries were blocked by the concurrency limit — the limit did its job.
7. 07A call from someone who is no longer on the team. This is the least obvious one and it lasts the longest.

Refusal number 7 deserves a paragraph

The active project is usually validated once, at authorisation, and then travels inside the token. Renewal copies the value forward without re-checking. When someone leaves the team, the membership record is deleted and the token stays intact — so access survives the departure, for the token's full lifetime.

The fix has two parts, and both are necessary: re-check membership in the funnel every call passes through, with a short cache; and clear the active project of anyone removed, so the cut is immediate in the normal case. With both, the worst case stops being months and becomes about a minute.

And the re-check has to fail closed. An error reading the permission cannot become a free pass — that is the difference between a system that denies when unsure and one that allows when broken.

On masking personal data

A common practice is masking email and phone in the samples the AI sees. It is worth saying why this is often theatre: in an internal audit, we found the same row that had the masked field also carried the buyer's email in three other fields and their national ID in a fourth. The mask removed no exposure at all, and it hid exactly what was needed to diagnose identity.

Inconsistent protection is worse than none: it creates the feeling that the matter was handled, and moves attention away from where the exposure actually is.

Real protection is scope — who can ask for what — not obfuscating what already circulates openly across the whole system.

What to ask for in writing

• The list of tools that write, and how the read scope is enforced.
• What happens to access when someone is removed from the team, and how fast.
• Whether the AI's query is parsed before it runs, and what that parsing refuses.
• Whether there is a record of who asked what, and how long it is kept.

In CrazyLeads, the AI's query goes through a sandbox that refuses another project's qualified schema, global tables, write statements and remote table functions; write scope is derived from each tool's own annotation, and the person's membership is re-checked at the single point every call passes through, failing closed.