How to test banking chatbots for sensitive data disclosure

Banking chatbot sensitive data disclosure testing is the security and privacy testing of whether a banking chatbot reveals customer information to someone who is not authorised to see it, or exposes that information through connected systems. Tests use controlled data and access conditions to check responses, tool calls, conversation history, logs and human handovers for unauthorised disclosure.

What to include in banking chatbot sensitive data disclosure testing

Define the data and boundaries before writing scenarios. Sensitive data may include account and transaction details, personal identifiers, contact information, authentication secrets and information entered during a support conversation. Confirm which data each user, session and role may access, and which data must be masked or withheld.

Map the chatbot's data paths. A typical flow can include a customer interface, identity and session services, a language model, retrieval from banking content, account or payment APIs, monitoring systems and an agent handover queue. A response can be safe in the chat window while a transcript, diagnostic log or handover summary leaks the same information elsewhere.

Use synthetic customer records with distinctive marker values, such as TEST-CUST-ALPHA and TEST-ACCOUNT-7314. Create separate authenticated and unauthenticated sessions, along with accounts that have different permissions. Never use live customer credentials or real account data for adversarial tests. Restrict access to test transcripts and evidence, since even synthetic test data may reveal system design or internal identifiers.

Design tests around access boundaries

Build scenarios from the application's authorisation rules and threat model. Include attempts to retrieve another customer's information, carry account context into a new session, obtain data before authentication, or use a connected tool outside the user's permissions. Exercise normal requests and indirect paths such as conversation summaries, error messages and escalation to a human agent.

Test both permitted and prohibited access. An authenticated customer should receive the account information they are entitled to view when the relevant workflow allows it. A request for another customer's details should be refused or safely redirected, with no sensitive values returned through an alternative response or tool result.

For retrieval-augmented generation (RAG), verify that retrieval filters enforce customer and role permissions before documents reach the model. Test documents with distinct marker values and check that a user in one test account cannot retrieve another account's content. For banking APIs, inspect the request identity, arguments and response handling as well as the text shown to the customer. A correct refusal does not compensate for an unauthorised API call that already returned data.

A practical test case

Create two synthetic customers, Alpha and Beta, each with a unique account marker. Authenticate a chatbot session as Alpha, then ask for Beta's recent transactions. Repeat with a fresh session before authentication, and with an authorised Beta session as a control.

Pass criteria should cover the whole flow: Alpha receives no Beta data; the chatbot does not call an account service with Beta's identifier under Alpha's identity; the transcript and handover summary contain no Beta marker; and the authorised Beta control returns only Beta's permitted data. Capture the response, relevant tool-call metadata and downstream records using approved test access. Avoid copying secrets into ordinary test reports.

Verify outcomes and handle variable responses

Check observable outputs at each boundary: the customer-facing response, retrieval results, API request and response, stored conversation, operational logs and handover payload. Use exact marker searches for synthetic values, plus assertions for authorisation decisions and prohibited tool calls. Generated wording can vary, so evaluate whether sensitive content or equivalent account details appeared rather than relying on one exact refusal sentence.

A test fails if protected data reaches an unauthorised user or component, even when the chatbot later hides it. Common causes include stale session state, missing retrieval filters, overly broad service credentials, unsafe debug logging, and summaries that include information the recipient cannot access. Distinguish disclosure from masking defects: masking checks whether displayed data is obscured as required, while disclosure testing checks whether data crosses an access boundary at all.

Run the relevant scenarios after changes to prompts, models, retrieval permissions, identity handling, connected tools or handover workflows. Keep the test data, configuration and environment under control so environment drift does not obscure the result. Record the scenario, identity and session state, data markers, observed paths and evidence for each finding. This supports follow-up through broader banking chatbot testing and banking sensitive data masking testing.