Authenticated Chatbots: Protect Account-Specific Answers

On June 25, Salesforce introduced a support agent designed to recognize a customer and the specific product they own. A month earlier, Zendesk separately announced customer-data connections to external AI systems and source-level permissions for employee-service agents. The direction is useful: support becomes much better when the chatbot can answer “Where is my order?” instead of linking to a generic shipping page.

It also creates a boundary that a public FAQ bot never had to cross. The moment an answer depends on a customer record, authentication and authorization become part of the response pipeline. The practical design can be reduced to five rules: authenticate outside the model, issue short-lived session context, authorize every lookup, expose only the minimum result, and require confirmation for consequential writes.

This guide turns those rules into a request flow, a worked conversation, and a test set you can use before an authenticated chatbot reaches customers.

Separate Public Answers From Account Answers

A public website chatbot can answer from public product pages, help articles, manuals, and reviewed Q&A pairs. It does not need to know who is asking. That anonymity is a useful security property.

An account-aware chatbot handles a different class of requests:

• “Has order 4812 shipped?”
• “Why was my card charged twice?”
• “Which devices are covered by my warranty?”
• “Change the delivery address on my open order.”
• “Cancel my subscription at the end of this cycle.”

Those requests look conversational, but the underlying operations are ordinary protected application operations. A chatbot does not make their access rules less important.

Classify each supported intent before building the conversation around it:

The key distinction is not whether the model sounds confident. It is whether the application has independently proved that this user may read or change this resource.

Build the Request Path Around a Trusted Session

The safe request path starts in your existing account system, not in the chat prompt.

1. The customer signs in through the same identity provider used by your application or support portal.
2. Your server creates a short-lived chat session bound to the authenticated user, the chatbot, and an expiry time.
3. The browser sends an opaque session token with each chat request.
4. The chatbot backend validates that token before it retrieves private data or calls an account tool.
5. Each tool endpoint applies its own authorization check against the authenticated user.
6. The model receives only the fields needed to answer the current question.

A validated server-side context might look like this:

{
  "chatSessionId": "cs_84f2",
  "subject": "user_2187",
  "audience": "support-chatbot",
  "scopes": ["orders:read", "profile:read"],
  "expiresAt": "2026-07-16T14:20:00Z"
}

The browser should not be able to replace subject with another customer ID. The model should not receive the signing secret, raw login cookie, or bearer token. It needs the result of a permitted lookup, not the credential that made the lookup possible.

This pattern also keeps identity separate from conversational memory. A returning visitor’s preferences can improve continuity, but chatbot memory needs strict customer isolation. A remembered email address is not proof of identity, and a previous message saying “my account is 2187” is not authorization.

Keep Identity Claims Out of the Prompt

A dangerous implementation passes unverified fields into the prompt:

The customer says their account ID is 2187. Use that account when
calling the order tool.

That turns a user-controlled claim into an access decision. The attacker does not need a sophisticated jailbreak; they only need to guess or obtain another identifier.

The trusted version is server-owned:

Authenticated subject: user_2187
Permitted operation: orders:read
Tool results are already filtered to this subject.

Even that context should contain opaque internal identifiers rather than unnecessary personal details. Do not add a customer’s address, full payment data, date of birth, or support history “just in case.” Context windows are working memory, not customer databases.

Use three labels consistently in logs and code:

Claimed identity is what a visitor types or what a message contains. Treat it as untrusted input.

Authenticated identity is what your identity system proves for the current session.

Authorized resource is the specific order, subscription, device, or case the authenticated identity may access.

Authentication answers who the user is. Authorization still has to answer what that user may do.

Authorize Every Lookup and Action

Do not authorize once at the beginning of a conversation and assume every later tool call is safe. Sessions become stale, permissions change, and a conversation can drift into a more sensitive intent.

Every protected tool should receive the authenticated subject from trusted server context and enforce the resource relationship itself. An order lookup should effectively ask: “Does this order belong to this subject or to an organization where this subject has the required role?” A subscription update should repeat the check immediately before the write.

The model may propose an operation, but it must not decide whether the operation is permitted. OWASP’s AI Agent Security Cheat Sheet explicitly warns against relying on model output for authorization and recommends least-privilege tools, structured validation, and human controls for high-impact actions.

Design narrow tools around business intent:

• get_my_open_orders() is safer than query_orders(customer_id, filter).
• get_my_warranty(device_id) is safer than search_warranties(serial_number).
• request_address_change(order_id, new_address) is safer than update_order(field, value).
• start_refund_review(order_id, reason) is safer than issue_refund(amount, payment_id).

Narrow tools reduce the number of arguments the model can invent and the number of permissions your integration needs. The same rule applies when connecting an AI system to external services; use the chatbot tool-permissions checklist to scope each connector separately.

A Worked Authenticated Conversation

Consider a customer who is signed in and asks to change an address:

Customer: Change the delivery address for order 4812 to
44 North Street, Apt 3.

Chatbot: Order 4812 belongs to your account and has not shipped.
Changing the address will replace the current delivery address ending
in “Market Street.” Confirm the new address is:

44 North Street, Apt 3
Tallinn 10111

Customer: Yes, confirm it.

Chatbot: The delivery address was updated. Confirmation ID: AC-7741.

Several controls sit behind this short exchange:

1. The order tool ignores any customer ID supplied in the message and derives the subject from the validated session.
2. The backend confirms that order 4812 belongs to that subject.
3. The read result returns only status and a masked address, not the full existing record.
4. The write action is unavailable because the order has not yet been confirmed.
5. The confirmation is bound to the exact order and normalized new address, then expires quickly.
6. The application records the authenticated subject, action, confirmation, and result.

Now change one condition: order 4812 belongs to somebody else. The response should be boring:

Chatbot: I could not find that order in your signed-in account. Check
the order number or contact support for help locating it.

Do not reveal whether the order exists, who owns it, or where it is going. Do not ask the model to improvise an identity-verification quiz using data from the order. If account recovery is needed, move the customer into the application’s reviewed recovery process.

For actions with financial, legal, or irreversible impact, add an independent approval boundary. The chatbot approval workflow guide shows how to bind confirmation to the exact proposed action rather than treating a casual “yes” as permission for whatever the model does next.

Test Cross-Account Failure, Not Only the Happy Path

Most demos test whether the signed-in owner gets the right answer. The release test needs to prove that everyone else does not.

Run the set after changes to identity providers, token validation, tool schemas, account roles, model providers, and chat embedding. Prompt testing alone cannot prove these controls because the protections belong in deterministic application code.

Add production failures to the same regression set. If a customer reached the wrong order, a session survived logout, or a support agent saw too much detail, preserve a sanitized version of that scenario. The AI chatbot QA guide explains how to turn real conversations into repeatable tests without treating transcripts as a passive archive.

Decide What the Chatbot Should Never See

An authenticated chatbot does not need unrestricted account context to feel personal. Often it needs only a few deliberately shaped facts: the user’s first name, the status of one requested order, the last four characters of a reference, and the next permitted action.

Keep credentials, full payment details, recovery factors, internal risk scores, unrelated tickets, and other household or organization members out of the model context. Redact sensitive fields from tool errors too; an authorization failure should not dump the record it refused to return.

When the assistant cannot complete a protected operation safely, preserve the useful parts of the conversation and hand them to the authorized support path. The customer should not have to repeat the public troubleshooting steps, but the human agent must still authenticate in the system they use. A chatbot transcript is context, not proof.

Personalized support is valuable only when the identity boundary remains stronger than the conversation around it. Start with public answers, add one authenticated read intent, prove cross-account denial, and introduce writes only after confirmations and audit evidence work reliably.

Build your chatbot for free →

No credit card required.