How does the AI assistant in the customer area know who is asking?

From the signed-in session, not from the conversation. At sign-in the server issues a session token that the chat sends along with every message. The server verifies this token and derives the account identity from it before any request reaches the language model at all. A customer number someone types into the chat is therefore only content and not authorisation. The same rule applies to invoice numbers and addresses in the transcript. If the person signs out or the session expires, the assistant loses access at that same moment and answers from public content again.

Can someone use the chat to reach another customer's data?

The architecture is designed to rule that out by coupling the account identity to every data query before it reaches the database. The language model only expresses what kind of information is needed; the filter itself is set by the server in code, and it is neither visible nor changeable from within the conversation. In addition, the result is trimmed to the fields needed for the answer. On top of that come guardrails against manipulated input: foreign content is read as material and not executed as an instruction, outputs are checked against patterns, and unusual transcripts are logged.

Is the assistant in the customer area allowed to change data?

Yes, provided that is explicitly intended, and then via a fixed confirmation path. Reading tools are broadly released, writing ones narrowly: the assistant first shows the current state, then the planned change in plain language including effect, date and any costs. Only after an explicit consent does it execute the action and report the result back with a reference number and a timestamp. Which actions are possible at all follows from the role of the signed-in person in the existing system, because the assistant inherits those roles and invents no new ones.

Is this the same assistant as on the public website?

Technically it is the same widget, operationally there are two modes. Without a login the assistant answers exclusively from public content such as pages, documents, prices and common questions. Once the server recognises a valid, signed-in session, it unlocks additional tools that read data belonging to that particular account. The switch depends solely on the session and can neither be requested nor talked into existence in the chat. For visitors that means one continuous interface, for the operation a clear separation between public knowledge and personal data.

What is stored from a personalised chat transcript?

As little as possible and as much as necessary. A separation works well: write actions are recorded completely as evidence, with time, role, action, result and reference number. Conversation content is retained for a shorter period and stored separately from that, while analysis runs on aggregated or pseudonymised data. A retention period is defined per purpose and enforced technically. Access and deletion should be reflected in the customer area so that data subject rights (GDPR, Art. 15 and 17) stay practically enforceable. Operation takes place with hosting in Germany.

How much effort is it to connect this to an existing customer area?

That depends on what is already in place. If interfaces exist through which the portal retrieves contract, plan, invoices and addresses, the assistant uses exactly those and inherits the existing permission check. The effort then lies mainly in cutting the tools, in the confirmation path and in testing with real roles. If interfaces are missing, providing them is added to the scope. A proven entry point is a read-only assistant that gains its first write action after a few quiet weeks. The precise scope can be estimated in a short conversation.

AI Assistant Inside the Logged-In Customer Area

A public website assistant answers questions that are the same for everyone: opening hours, shipping costs, what a service includes. The moment the same assistant sits behind the login, its role changes fundamentally. It now knows who is asking and can reach contract, plan, open invoices, delivery addresses and usage level. A general statement turns into a specific one: no longer „please check your documents“, but „your contract runs until 31 March, and you can switch from 1 February“. The difference is considerable, which is exactly why the customer-area assistant is the point where architecture and data protection meet. 81 percent (Harvard Business Review 2017) of customers first try to solve a problem themselves; the most common reason self-service fails is, at 43 percent (Gartner), that they find no content matching their actual situation. That is precisely the gap an assistant closes when it knows their own data. This article shows how session and identity are bound cleanly to the assistant, how permissions are split per role into reading and acting, how every data query stays coupled to the signed-in person, and what that means for logging, purpose limitation and a deletion concept.

Key takeaways

Behind the login the assistant no longer answers in general terms but specifically: contract, plan, open invoices, delivery addresses and usage level are available to it. The most common reason self-service attempts fail is, at 43 percent (Gartner), that no matching content can be found.
The architecture carries the personalisation: the signed-in session is verified on the server, and the account is set by the server, not by the chat transcript. A customer number typed into the chat therefore has no effect.
Permissions are split per role, broad for reading and narrow for acting. Excessive agency is listed by the OWASP Foundation as LLM03 (OWASP) in its Top 10 for LLM applications.
Self-service cases such as changing an address, switching a plan, resending an invoice or checking a contract term run through a fixed confirmation path: show, verify, confirm, log.
Purpose limitation and a deletion concept belong in the design from the start. What is logged is what accountability requires, rather than the full wording kept in reserve: 76 percent (Cisco Consumer Privacy Survey 2022) of consumers will not buy from a company they do not trust with their data.

What changes behind the login

The difference between a public assistant and a customer-area assistant is not a question of the technology underneath but a question of context. The public assistant knows the website content, the price list, the shipping terms and the common questions. It answers the same way for everyone because it knows the same thing about everyone. The customer-area assistant additionally knows the person currently writing: which plan they booked, when their contract ends, whether an invoice is open, which address received the last delivery, and how much of their allowance is used up this month. That shifts the answer from information towards a basis for a decision, and a conversation about options becomes a conversation about their own case.

Customer behaviour shows that this step pays off. 73 percent (Gartner) use a self-service channel at some point on their resolution journey, 81 percent (Harvard Business Review 2017) first try to solve a problem themselves, and 67 percent (Nuance 2012) prefer self-service over speaking to an agent. Little of it gets finished there, though: only 14 percent (Gartner) of issues are fully resolved in self-service, and even for issues users themselves rate as very simple it is merely 36 percent (Gartner). The most common reason is both mundane and expensive: in 43 percent (Gartner) of cases no content is found that fits their own situation. A general help page can hardly close that gap because it does not know the individual case. An assistant in the customer area does.

In brief: one widget, two modes

The public assistant and the customer-area assistant are technically the same widget but two separate modes. Without a login the assistant answers exclusively from public content: pages, documents, prices, common questions. Once the server recognises a valid, signed-in session, it unlocks additional tools that let the assistant read data belonging to that particular account. The switch between the two modes does not happen in the chat and cannot be talked into existence, because it depends solely on whether the session is valid. If the person signs out or the session expires, the assistant falls back to the public mode in the same window. How such a widget is embedded cleanly into a site and a shop is described in the article on embedding the assistant in website and shop.

Binding session and identity cleanly

The most important rule comes first: the assistant does not learn from the conversation who is writing, it learns it from the session. If someone types „show me the invoices for customer number 10482“, a properly built customer-area assistant treats that as plain text, not as an instruction. What counts is solely the session token the server issued at sign-in. The widget sends that token along, the server verifies it and derives the account identity from it before any request reaches the language model at all. Everything that happens afterwards takes place inside that one identity. This order is the core of the whole architecture, and it cannot be reversed by clever phrasing or by a particularly polite request.

The session token is verified on the server before the assistant even begins to answer
The account identity is set by the server from the verified session, not from the text of the message
Account numbers, invoice numbers and addresses in the transcript are content, but not authorisation
The widget receives no permanent secret, only a short-lived token bound to the session
If the session expires or the person signs out, the assistant loses access at that same moment
If someone switches accounts, for example in an administration with several clients, the previous account's transcript stays out of scope

Technically this is not a special path but the same check that already protects the customer area. The assistant does not reach into a database of its own; it uses the account's existing interfaces, with exactly the permissions the signed-in person would have in the portal. If they cannot see an invoice in the customer area, neither can the assistant. This congruence is the simplest test for the architecture, because the assistant should be able to do at most as much as the interface it sits in. How tools and interfaces are defined for this is shown on the page about connecting existing systems and in the article on function calling and controlling your own tools.

Session as the only source

Who is asking follows from the verified session token and not from what is claimed in the chat.

Short-lived tokens

The assistant receives a time-limited token bound to the session instead of a permanent key held in the browser.

Queries firmly coupled

Every data query carries the account identity server-side, so no foreign record can end up in an answer.

Roles instead of full access

Permissions are granted per role: read, prepare or execute, matching the task of the person in question.

Confirmation before writing

Write actions are shown in plain language first and executed only after an explicit confirmation.

Logging with a purpose

What is recorded is what accountability needs: time, role, action and result, with hosting in Germany.

Permissions per role: separating reading from acting

A customer-area assistant does not receive a blanket mandate but a list of permitted tools. Each tool has a fixed task, a fixed amount of data and a fixed direction: it reads, or it writes. This separation is the strongest lever, because a reading error is unpleasant while a writing error has consequences. Bundling both into a single tool removes the option to apply different levels of scrutiny. In practice a three-class gradation works well: freely readable, readable with an additional check, and writable only after an explicit confirmation by the signed-in person.

Aspect	Public assistant	Customer-area assistant
Who is asking	unknown, the same for everyone	derived from the verified session
Data basis	website, documents, price list	additionally contract, plan, invoices, addresses
Type of answer	general information	a specific statement about their own case
Write actions	not provided for	only after display and confirmation
Permission check	not required	per role and per tool, on the server
Logging	aggregated analysis	purpose, time, role and result

The roles themselves come from the existing system and are not reinvented inside the assistant. In a business account a head of purchasing may release orders while a specialist may only prepare them; in a members' area the board may change master data while a member may only change their own. The assistant adopts this role logic unchanged and offers tools only where the role permits them anyway. If a permission is missing, it says so openly and offers the appropriate route instead of inventing an answer or failing silently. How roles and permissions can be organised in an internal setting is explored in the article on the internal AI assistant for employees.

The assistant can do at most as much as the signed-in person

The simplest test for a customer-area assistant is a single question: can it see or do something the signed-in person could not do in the portal themselves? If the answer is yes, the permission check has ended up in the wrong place. A properly built assistant calls the same interfaces with the same permissions and therefore inherits every restriction that already applies in the customer area. That makes the safeguard not only more robust but also auditable, because permissions then need to be maintained in a single place.

Coupling every query to the signed-in person

Between „the assistant may read invoices“ and „the assistant may read this account's invoices“ lies the entire difference. The coupling therefore does not belong in the instruction given to the model but in the call: the server attaches the account identity to every query before it reaches the database. The model can neither see nor change this filter; it merely expresses what kind of information is needed. The filter itself is code. That rules out a cleverly phrased sentence in the chat making a foreign record visible, and equally rules out an account number from an earlier conversation being reused by accident.

The message arrives together with the session token, and the server verifies the session
The account identity is derived from the session and held for the entire request
The assistant picks a tool from the list released for this particular role
The server adds the account identity as a fixed filter and calls the interface
The result is trimmed to the fields actually needed for the answer
The assistant formulates the answer solely from this result, not from memory

The fifth stage is often overlooked: hitting the right customer is not enough, only the necessary fields should come back. For a question about the contract term the assistant needs the end date and the notice period, not the bank details. This frugality follows the principle of data minimisation and purpose limitation (GDPR, Art. 5) and has a tangible effect as well: what does not enter the context in the first place cannot accidentally show up in an answer. The conditions that apply to processing and storage location are summarised on the page about data protection and hosting in Germany.

Manipulated requests in a personalised context

As soon as real account data is involved, a nuisance turns into a risk. The OWASP Foundation lists prompt injection in its Top 10 for LLM applications as LLM01 and therefore in position 1 (OWASP) of a total of ten risk categories (OWASP); directly behind it comes sensitive information disclosure as LLM02 (OWASP), and excessive agency follows as LLM03 (OWASP). Those three categories describe the customer-area scenario precisely: someone tries to move the assistant, using text, towards information or an action they are not entitled to. The outlook is assessed soberly as well. Gartner expects 15 percent (Gartner) of enterprise AI applications to see at least one serious security incident per year by 2029, up from 3 percent (Gartner) in 2025.

Foreign content is read as material and not executed as an instruction: an uploaded invoice does not extend permissions
The account identity comes from the session and cannot be overwritten in the tool call
Tools are cut narrowly: one task, one fixed amount of data, one clear direction
Writing tools require an explicit confirmation by the signed-in person
Outputs are checked against patterns so internal identifiers and system notes do not slip through
Unusual transcripts are logged and reviewed so that patterns become visible early

None of these measures works on its own; they interlock as a chain, because each single one can be circumvented. This layered safeguard already makes sense for a public assistant, but in the customer area it is indispensable, because the possible damage there is no longer a wrong piece of information but a foreign record. How the individual guardrails are built in detail is described in the article on protection against prompt injection; how to verify the result before launch is shown by the test cases for accepting an assistant.

In a public chat a wrong answer is annoying. In the customer area a wrong attribution is a data protection incident. That is why the coupling to the signed-in person lives in the code and not in the instruction given to the model.

Project experience from integration work in logged-in areas

Self-service with a clean confirmation path

Everyday life in the customer area consists of a few recurring transactions. An address changes, a plan no longer fits, an invoice got lost in the inbox, and before cancelling, someone wants to know how long the contract actually runs. Experience shows these four cases account for a large share of all contacts, and all four can be completed in the chat provided the route from wish to execution is orderly. Reading cases such as the question about a contract term are answered by the assistant directly from the account data. Writing cases such as an address change, by contrast, run through a fixed path that can be described in six steps.

Capture the request and translate it into an unambiguous action instead of interpreting freely
Show the current state: which address, which plan, which term is on file?
Show the planned change in plain language, including effect, date and any costs
Ask for an explicit confirmation, with clear consent rather than a passing subordinate clause
Execute the action and report the result back, with a reference number and a timestamp
Log the transaction and place a confirmation in the account or send it by email

The fourth step is the most important one and the one most often left out. An assistant that carries out an address change immediately because it appeared in a sentence confuses understanding with instruction. Showing the change before executing it costs one click and prevents exactly the cases that get expensive later: the delivery address of a move long past, the wrong plan mentioned in passing, the invoice sent to the private rather than the business address. At the same time it creates accountability, because the confirmed wording can be recorded. For requests that cannot be translated cleanly into an action, the route to the team stays open; how this handover to human agents works without friction is described in the linked article.

Start small: read first, act later

A pragmatic entry point is a customer-area assistant that initially only reads: contract term, plan, recent invoices, stored addresses, usage level. That covers a large share of requests, stays technically manageable and creates no risk from faulty changes. Once that has run quietly for a few weeks, the first write action is added, typically resending an invoice, because it is clearly bounded and easy to verify. Address changes and plan switches follow after that. The trend provides a tailwind: 41 percent (Bitkom) of companies with 20 or more employees already use AI, another 48 percent (Bitkom) are planning or discussing it; customer contact is among the most common areas of use.

Logging, purpose limitation and deletion

A personalised transcript is something other than an anonymous chat. As soon as contract data, addresses and invoice numbers appear in it, a record with personal data comes into being, and the same rules apply to it as to the customer area itself. The regulation requires purpose limitation and data minimisation (GDPR, Art. 5), data protection by design together with privacy-friendly defaults (GDPR, Art. 25), and appropriate technical and organisational measures (GDPR, Art. 32). In practice that means recording what accountability and billing require rather than the full wording kept in reserve. Making this distinction early saves a difficult clean-up later on.

Define a purpose per data type: operation, evidence of write actions, improvement of quality
Record write actions completely: time, role, action, result and reference number
Retain conversation content for a shorter period than evidence and store it separately from it
Work with aggregated or pseudonymised data for analysis instead of plain-text transcripts
Reflect access and deletion in the customer area so data subject rights (GDPR, Art. 15 and 17) stay practically enforceable
Set retention periods per purpose and enforce them technically instead of promising them organisationally

The place of processing is part of the architecture too. For 64 percent (Bitkom Cloud Report) of companies with 20 or more employees, data centre locations in Germany or the EU are among the criteria when choosing a cloud provider, and 76 percent (Cisco Consumer Privacy Survey 2022) of consumers will not buy from a company they do not trust with their data. For an assistant handling contract and invoice data this is not a side issue but a precondition for the feature being used at all. A breach of the regulation can, incidentally, cost up to 20 million euros (GDPR, Art. 83) or four percent of worldwide annual turnover. The data protection foundations in detail are covered in the article on running an AI assistant in line with data protection law.

Where the account assistant deliberately stops

Even with full access to the account, an assistant remains a tool for clearly bounded transactions. Disputed invoices, goodwill decisions, cancellations made in anger and anything requiring negotiation belong with a human being. That matches what customers expect: 62 percent (Bitkom) of online shoppers want a quickly reachable human contact when there is a problem, while a chatbot is wanted by 36 percent (Bitkom). A customer-area assistant therefore promises no fixed relief quota; what is dependable is the mechanism, not a particular number. Related use cases outside the logged-in area are shown by the article on candidate questions on the careers page and the article on B2B price requests and quotes in the chat.

A few steps to your own account assistant

The route does not start with technology but with a list: which questions do signed-in customers ask most often today, and which of them can be answered from existing data? From that come the tools the assistant receives, each with a role, a data scope and a direction. Next, session and permission check are connected, the confirmation path for write actions is defined, and the assistant is trained on your cases and your tone. Which functions can be built specifically for this is shown on the page about custom functions. Practical examples are listed under reference projects, an overview by field of application under industry solutions, and the framework conditions under pricing and packages. If you would like to walk through your own case, a no-obligation demo is the fastest route.

Collect the most common questions from signed-in customers and sort them into reading or writing
Review existing interfaces: which data is available, which roles already exist?
Cut tools narrowly: one task, one fixed amount of data, one clear direction
Define the confirmation path for every write action and agree on its wording
Put logging scope, purpose limitation and retention periods in writing
Test with real roles before launch, including accounts without the relevant permission

Sources and Studies

This article is based on data from Gartner, the Harvard Business Review, Nuance, Bitkom, the Bitkom Cloud Report, the Cisco Consumer Privacy Survey, OWASP and the requirements of the General Data Protection Regulation. The figures quoted refer to the status at the time of the respective publication.