Data Privacy in AI Customer Support

Put an AI agent on your support page and the privacy question arrives before the feature questions do. Visitors will type things into that chat box: order numbers, email addresses, the occasional frustrated paragraph about a problem. The agent reads your business knowledge to answer them, and on the paid tiers it can act on a real customer's account. So the fair thing to ask, before you ask how clever it is, is plainer. What data does this thing touch, where does that data go, and who can reach it.

This page answers that for our widget without hand-waving. We will not point at a compliance badge, because data privacy in AI customer support is not a logo, it is a set of choices about data you can actually inspect. Here is the short version, and the rest of the page is the long one. The agent only reads the public material you point it at and the docs you upload. A visitor's message stays inside your own account, walled off from every other business on the platform. Any action that touches a specific customer's account runs behind a verified identity, not a name typed into chat. And the credentials that reach your tools never sit in our database in the clear. Each of those is a control you can name, and how we encrypt and handle credentials is documented in full.

What data the agent actually touches

Start with the smallest honest answer to "what does it see," because most privacy worry is really worry about an unknown surface. The agent works from two kinds of material, and that is the whole list. First, the knowledge you give it: documents you upload (PDF, DOCX, TXT, MD) and the web content it crawls from a domain, a sitemap, or a single URL you name. Second, the live conversation: what a visitor types while chatting, plus, on the paid tiers, the account data an action pulls back, like an order status or a booking slot.

Notice what is not on that list. The agent does not roam your internal systems, scrape your private dashboards, or wander off the material you handed it. We built it to answer from your knowledge base and decline when a question falls outside that material, which is the same control that stops it from inventing facts. A bot bounded to what you gave it has a small, knowable data surface by design, and a small surface is an easier one to keep private. The deeper reasoning behind declining instead of guessing lives in our writeup on a no-hallucination AI support agent, but the privacy point here is narrower. You can draw a box around what the agent reads, and nothing it touches lives outside that box.

Only public pages get crawled

When you train the agent on your website, a reasonable fear shows up fast: will it suck in something it should not. A staging page, a logged-in account area, a private PDF sitting on a server somewhere. So we want to be specific about the boundary. The web crawl reads public pages, the same pages any visitor or search engine could already load. It does not log into gated areas, and it does not reach content that is not already reachable on the open web.

That line matters because it changes who is responsible for what. The agent's knowledge of your site is a copy of what you have already chosen to publish. If a page is behind a login, the crawl does not see it, which means your private account areas, internal tools, and unpublished drafts stay out of the agent's reach unless you deliberately upload that material yourself. I think that is the right default, because the safe behavior should be the one you get without thinking about it. You decide what becomes knowledge by choosing what to publish and what to upload. The crawl does not make that decision for you behind your back.

Verified identity before any customer data is read

Answering a general question is one privacy class. Pulling up a specific person's order is a different one entirely, and it is the one worth being strict about. The moment the conversation turns from "what is your return policy" to "where is my order," the agent is about to read data tied to a real account, and "who is asking" stops being a detail.

So those lookups sit behind a verified visitor identity. Your site signs a token for the logged-in visitor, the agent reads it, and the customer's email and name come from that signed claim, not from whatever someone typed into the chat. A stranger cannot talk the agent into reading another person's order by spelling out a different email, because for an account lookup the agent trusts the token, never the message. No verified identity means the customer-specific action is blocked or kept to a safe anonymous path, with nothing degrading quietly into a guess. The full mechanics of how that token is issued and checked live in identity-verified actions with JWT. For privacy, the rule is short. Personal account data is only ever read for a visitor the system can actually prove is that person.

Where a visitor's data lives, and who cannot see it

Every message a visitor sends and every action your agent takes belongs to one place: your account. BestChatBot runs many businesses on the same platform, so the promise that keeps that private is isolation. Each account's conversations, uploaded knowledge, and connections are kept separate at the data layer. Another business running an agent on the same platform has no path to your visitors' messages or your customers' data.

Practically, this means a chat your visitor had with your agent does not surface in someone else's account, and the order your agent looked up for your customer is not visible to a different tenant. Their agent is trained on their content and bounded to their account, and yours is bounded to yours. Isolation here is structural, not a checkbox you remember to tick. It is how the data is partitioned in the first place, which is the only version of the promise worth making, because a wall you can switch off is not a wall. I want to be precise about the limit of this claim. It is strong separation between accounts, not a named compliance certificate, and if your industry requires a specific audit standard you should ask us directly rather than read one into the word "isolated."

Credentials your agent uses without ever holding them

To read that order or book that slot, the agent has to reach the tool that holds the data, and reaching a tool means credentials. That is a quiet privacy hazard, because a pile of long-lived secrets is exactly what an attacker wants. We made a deliberate call: BestChatBot does not store your third-party credentials directly. A specialist provider holds them encrypted and refreshes the tokens, and the agent borrows short-lived access through that layer. OAuth and API-key connections both work this way. So the long-lived secret that could reach your customer data does not land in our database as a target, it lives with a service built to guard exactly that, and how the connection is authorized is laid out in secure connections with OAuth and API-key. The part most worth protecting is held by the party best equipped to protect it.

FAQ

What customer data does the AI agent store?

The agent works from the knowledge you give it (uploaded documents and crawled public pages) and the live conversation (what a visitor types, plus any account data an action reads back on the paid tiers). All of it stays inside your own account, walled off from every other business on the platform. The agent does not roam your internal systems or read anything outside the material you pointed it at.

Does the website crawl read pages behind a login?

No. The crawl reads public pages, the same content any visitor or search engine could already load. It does not log into gated areas or reach private account sections. If you want internal material to become knowledge, you upload it yourself, which keeps the decision of what is private firmly in your hands.

How does the agent stop someone from reading another person's data?

Account-specific lookups run only behind a verified visitor identity. The customer's email and name come from a signed token your site issues, not from what a visitor types into the chat, so a stranger cannot pull another person's order by typing a different email. No verified identity means the lookup is blocked or kept to a safe anonymous path.

Can another business on the platform see my visitors' messages?

No. The platform is multi-tenant, but each account is isolated at the data layer. Your conversations, uploaded knowledge, and connections stay inside your account, and another tenant has no path to them. The separation is structural, not a setting you have to remember to enable.

Where are the credentials for my connected tools kept?

Not in our database. A specialist provider stores them encrypted and refreshes the tokens, and the agent borrows short-lived access through that layer. OAuth and API-key connections both flow through it, so the long-lived secret that could reach your customer data never sits with us as a target.

Data privacy in AI customer support is not a feeling you ask people to extend on faith. It is a set of choices you can point at: a small, knowable data surface, public-only crawling, a verified identity gating every account lookup, strict separation between accounts, and credentials held by a specialist rather than piled up with us. The wider picture of how those controls fit together sits on the trust and privacy overview, and when you are weighing what the agent costs against what it protects, the plans are on the pricing guide.

Related on trust: GDPR compliance for AI support, identity verification, and the guardrails bounding the agent.

More on trust: multi-tenant data isolation and grounding and hallucination liability.