Public AI Chatbot vs. Customer Portal: Securely Separating Identity and Data Access

A chatbot on a public website may answer product questions, explain opening hours, or guide users to the right service page. However, as soon as it needs to view order status, contracts, invoices, or support cases inside a customer portal, more than just the content changes. A new security boundary is created. An authenticated AI chatbot must cleanly separate identity, authorization, session, and concrete action from one another.

Therefore, the most important architectural decision is not: "Which model do we use?" It is: "Which information and which action is permitted in which trust domain?" Answering this question before designing prompts reduces data leaks, misallocated accounts, and unintended actions. The following guide provides technical and organizational guidance, not individual legal advice.

Why Public and Authenticated Are Two Distinct Operating Modes

In a public chat, the person is initially unknown. At most, the system knows the conversation context, the chosen language, and technically necessary session data. Responses should therefore be limited to approved, publicly accessible sources. An entered email address, order number, or claim like "This is my contract" is not proof of authorization.

In the customer portal, on the other hand, an authenticated session exists. But even there: logging in does not automatically mean every resource and action is allowed. The OWASP Authentication Cheat Sheet distinguishes authentication, identity proofing, and session management. The current NIST Digital Identity Guidelines, Revision 4 also treat identity proofing, authentication, and federation as separate building blocks. For website teams, the takeaway is: the chat must only rely on trust signals that the surrounding system verifiably provides.

Three Zones Instead of an All-Powerful Chatbot

A robust solution divides knowledge and tools into at least three zones:

• Public Zone: approved website content, general product information, processes, contact channels, and non-binding assistance.
• Authenticated Zone: data and processes linked to the logged-in account, an organization, role, or authorization.
• High-Security Zone: sensitive changes, payouts, contract conclusions, new delivery addresses, permission changes, or other actions requiring additional confirmation or human review.

These zones should not only exist in the system prompt. They must be mapped across data sources, APIs, roles, tool permissions, and server-side checks. A prompt can guide behavior, but it is not access control. The same applies to RAG: searching across public and private documents in a single, unfiltered index creates an unnecessarily broad attack surface.

Authentication Is Not Authorization

To put it simply, authentication answers: "Which digital identity is logged in?" Authorization answers: "Is this identity allowed to read this exact object or execute this function?" The distinction is easily blurred in chat because users naturally phrase requests with object numbers: "Show me invoice 4711" or "Change the address for order 815."

The OWASP recommendations for IDOR prevention require object-level authorization checks, even if identifiers are hard to guess. In practice, this means: the server derives the current account from the protected session and verifies with every request whether the invoice, order, or ticket belongs to this permitted data space. The language model must never accept a freely entered customer or object ID as a trust anchor.

What the Public Website Chat Is Allowed to Answer

For the public area, an allowlist is better than a long blocklist. Approved topics might include return windows, delivery regions, product features, guides, general pricing logic, or instructions on how to log in. What is not approved includes individual order statuses, contract details, personal appointments, internal notes, or stating whether a specific account even exists.

Even seemingly harmless answers can leak information. "There is no account associated with this email address" confirms an enumeration attempt. A neutral response such as "Please log in to the customer portal to retrieve account-related information" keeps the boundary solid. Protecting against manipulation attempts requires additional safeguards, as described in the article on prompt injection in website chatbots.

What the Authenticated AI Chatbot Requires in Addition

After login, the assistant is allowed to do more, but only within the context determined on the server side. Sensible input data includes an internal session reference, the permitted organization or tenant, roles, and a tightly defined functional scope. Raw credentials, passwords, full session tokens, or unnecessary personal data fields do not belong in the model context.

The OWASP Authorization Cheat Sheet recommends authorization checks for every specific resource and function. For tool calls, this means: the model does not decide whether an invoice is visible. It requests the allowed information from a service; the service re-verifies session, role, tenant, and object. The chat then receives only the fields strictly necessary for the answer.

Structuring Data and Tool Boundaries in Practice

Reading and writing should be separate tools. A tool named "manage customer account" is too broad. Smaller functions like "list own open orders," "read status of permitted order," or "prepare support ticket" are better. Each function receives a minimal input schema, a server-side authorization check, clear error cases, and scoped output.

For RAG, the same logic applies: public sources belong in a public search space; account-related documents belong in a search space filtered by tenant and role. Filters are constructed on the server side from the session, not from freely formulated chat inputs. Changes to sources, roles, and approvals belong in a documented process; a template is provided in the article on content governance and change control.

Accounting for Session Expiration, Logout, and Shared Devices

A chat interface must not create the impression that authorization persists indefinitely. The OWASP Session Management Cheat Sheet describes a session as the tie between authentication, HTTP traffic, and access control. If the session expires, the next request for private data must safely fail. An old response in the visible chat history must not be interpreted as fresh authorization.

Teams should also test logouts, account switching, role changes, and shared devices. Private conversation histories must not leak into the next account after a switch. When a session expires, the assistant should clearly prompt for re-login without repeating sensitive details from the previous session. For logging and evaluation, data minimization applies; the article on data-minimized chatbot analytics outlines appropriate event and retention boundaries.

Sensitive Actions Require Step-Up Confirmation

Logging into the portal is not necessarily sufficient for every action. If the chat changes a shipping address, confirms a contract, or triggers a payment, the system should require explicit, action-specific confirmation. The OWASP Transaction Authorization Cheat Sheet separates authentication from transaction authorization and mandates server-side controls as well as verification of key transaction data.

A secure pattern works as follows: the chat captures the user's intent, displays a clear summary, and the portal verifies current authorization, requesting re-authentication or a second factor if needed. Only then does a server-side service execute the exact confirmed action. If the target, amount, or other key parameters change, the previous authorization expires.

Example: Returns Without Data Leaks

An anonymous user asks: "Can I return my order?" The public chat explains the general return policy and links to the portal. It does not ask for full address or payment details. After login, the portal chat can list the user's eligible return orders via a read tool. Once the user selects an order, the server re-verifies object authorization and applicable business rules.

For the actual return, a separate action tool generates a summary. The user confirms items and pickup options within the portal UI. If authorization fails, the chat avoids revealing internal risk signals and instead offers a safe next step. If human intervention is required, a controlled human handoff follows, passing only necessary, approved context.

Test Matrix Before Go-Live

A test matrix should not only cover happy paths. Use at least two accounts with similar roles and separate data, testing the following scenarios:

• Anonymous request for general information vs. private account data.
• Logged-in Account A reads its own object and then attempts to access an object identifier belonging to Account B.
• Expired session, logout, account switch, and role revocation during an active chat.
• Language switch mid-process without changing data scope or authorization.
• Prompt injection in user input and retrieved documents.
• Failure of a read tool, timeout, and conflicting backend data.
• Write action without confirmation, with altered parameters, and with an expired confirmation.
• Human handoff with minimal, traceable conversation context.

Expected outcomes must be defined in advance: Which response is publicly permissible? Which HTTP error code is returned server-side? Which information may be visible in chat? Which event is logged without sensitive content? A planned degraded mode helps when identity or backend services fail; a dedicated incident response and rollback guide details this setup.

Checklist for a Resilient Portal Boundary

• Document public, authenticated, and high-security zones.
• Model authentication, authorization, and transaction authorization separately.
• Derive account and tenant strictly from the secure session.
• Verify object-level authorization on the server for every read and write operation.
• Technically separate and filter public vs. private RAG sources.
• Scope tool permissions minimally; separate reading and writing.
• Handle session expiry, logout, account switching, and role changes in chat.
• Summarize sensitive actions clearly and require explicit step-up confirmation.
• Limit handoff context and logging to essential data.
• Reproducibly test horizontal access attempts using at least two separate accounts.

An authenticated AI chatbot does not become secure simply by placing it behind a login. Security exists when every piece of information and every action has a verifiable boundary. Start with the zone map and test matrix before connecting private data sources or state-changing tools. This keeps the public chat helpful and the portal chat actionable without blurring the two trust domains.

References

• NIST SP 800-63, Revision 4: Digital Identity Guidelines
• OWASP Authentication Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Session Management Cheat Sheet
• OWASP Insecure Direct Object Reference Prevention Cheat Sheet
• OWASP Transaction Authorization Cheat Sheet