An AI CRM is a permissions problem wearing a chat interface

There is a version of "AI CRM" that takes a fortnight to build. You add a text box, you pass the user's question and a pile of their records to a model, and you render whatever comes back. It demos beautifully.

It is also, in the most literal sense, a data breach with autocomplete.

The question nobody demos

When an AI answers a question about your pipeline, something decided which records it was allowed to read. In most implementations that something is a prompt — a sentence in the system message asking the model nicely to only discuss the current user's data.

A prompt is not an access control. It is a suggestion to a system explicitly designed to be talked out of things.

The question worth asking any AI CRM is therefore not "what can it do?" but:

• Which identity is this request running as?
• What narrows it — and can any step in that chain widen access rather than reduce it?
• Where is the boundary enforced: in the prompt, in the application, or in the database?

What we built first

Workden's AI connectors are not live yet. We have said so on every page that mentions them, because we would rather be boring than wrong.

What is live is the part that has to exist before a connector is safe to build. Every request in Workden today resolves to a person, and then narrows:

1. The workspace comes from a signed session — never from a URL, a form field, or anything a caller can set.
2. The query layer rewrites every database call to add the workspace filter, and overwrites any value the calling code supplied. A developer cannot forget it because they never write it.
3. PostgreSQL row-level security compares every row against the workspace established for that transaction. If the first two layers both failed, the database returns nothing.

Each step can only reduce what the step above allowed. There is no path that widens.

Why the order matters

Adding permissions to an AI feature after it ships means retrofitting a boundary around something that was built assuming there wasn't one. That refactor never fully lands, and the gap is invisible until someone finds it.

Building the boundary first means the AI connector is a small piece of work: it resolves a provider identity to a Workden user, and everything downstream already knows what to do.

That is the whole argument. It is not a very exciting one, which is probably why it does not make it into many demos.