Ask a vendor whether their AI chatbot works on members only content and you will usually get an enthusiastic yes. Ask how, and the answers separate quickly into two very different architectures, only one of which is safe.
Why crawler based chatbots stop at the login
Most AI chatbots on the market work by crawling your website the way a search engine does. They fetch public pages, extract the text, and index it. This works fine for a marketing site and fails completely for a knowledge base, because the crawler hits your login screen and sees exactly what an anonymous visitor sees, which is nothing.
Some vendors offer to work around this by giving the crawler a service account. That is worse than it sounds. The crawler now sees everything that account can see, and the index it builds has no memory of which article belonged to which access level. Every user then queries one flat index containing all of it. The only thing standing between a basic member and premium content is an instruction in a prompt, and instructions in prompts are not a security control.
The architecture that does work
A chatbot for gated content has to live inside the CMS and read content through it. On Drupal, that means reading nodes through the entity API and capturing, for every passage indexed, the access information Drupal already holds: roles, node access grants, Group memberships, or membership tiers.
At query time the sequence is fixed:
- Identify the user from the existing session, not from anything they typed.
- Build an access filter from their roles and grants, server side.
- Apply that filter to the search, so only permitted passages are retrieved.
- Give the language model those passages and nothing else.
The model never sees restricted content, so no amount of clever prompting can make it reveal any. That is the property you need, and it is only achievable by filtering before retrieval.
The subtle leaks worth knowing about
Getting the main filter right is necessary but not sufficient. A few smaller channels leak information if you ignore them:
- Existence disclosure. Telling a basic member "there is an article about this, but you cannot see it" reveals something. Sometimes that is exactly what you want, because it drives upgrades. Sometimes it is a confidentiality breach. That should be a deliberate setting, not an accident.
- Conversation memory. If a user's permissions are reduced mid session, earlier answers may still sit in the conversation history. Re-evaluate access per question rather than per session.
- Logs. Query logs contain retrieved passages, which means your logging system now holds restricted content. It needs the same access rules as the content itself.
- Caching. Caching answers by question text alone will serve one user's permitted answer to another user. Any cache key has to include the access context.
Where it runs matters more here
For public content, sending text to a commercial AI provider is a manageable question. For content behind a login, it usually is not, because that content is gated precisely because it is not meant to travel. This is why gated knowledge bases push organisations towards on-premise or European hosting far more often than public sites do. We compare the options in on-premise AI vs cloud AI.
What to check before you start
Three things are worth confirming before any project like this begins. First, is your access model in the CMS actually correct today? A chatbot enforces the permissions you have, not the ones you meant to configure, and these projects regularly uncover articles that were never restricted properly. Second, can you audit it? You should be able to show, for any answer, which sources were used and whether that user was entitled to each of them. Third, can you test it? Ask questions as a low privilege user that can only be answered from restricted content, and confirm the system declines. That test belongs in your acceptance criteria, not in a nice to have list.