How should banks stop sensitive data from leaking into AI prompts?

Why prompt leakage in banks is a governance problem, not just a filtering problem

Banks should assume that prompt leakage is usually caused by business context, not just a bad phrase. The control objective is to stop regulated data, client information, and internal secrets from reaching a model in the first place, which means the policy decision has to happen before the prompt is assembled, routed, or stored.

This is why banks need contextual classification of the interaction, not a simple denylist. A harmless-looking request can still contain account details, trading information, customer identifiers, source code, or operational notes that should never be exposed to a model. The right guardrail is decisioning on intent, sensitivity, and permitted use, with enforcement tied to the workflow that creates the prompt.

Prompt handling also sits inside the wider control stack for data loss prevention, records management, and acceptable use. If the bank only treats prompts as transient text, it misses the fact that prompts can become durable artefacts in logs, monitoring tools, vendor systems, or conversation history. For that reason, the policy needs to cover collection, retention, redaction, and review, not just the model call itself.

Where banks need to classify and block before the model sees the data

Effective prompt controls start with a practical classification model. The bank should distinguish between routine internal queries, customer-facing interactions, and higher-risk use cases where employees may paste material that is confidential, regulated, or privileged. The blocking decision should be based on the content and the business context together, because either one alone can be misleading.

That is also where human workflow design matters. If employees must copy and paste sensitive material into general-purpose AI tools to get work done, the bank has already lost part of the control battle. Better patterns include pre-approved use cases, field-level redaction, controlled retrieval from approved systems, and prompt templates that minimise raw sensitive content.

For banks, the most durable control is to make the safe path the easiest path. Where a use case genuinely needs sensitive information, the bank should prefer constrained tools, scoped retrieval, and explicit access checks rather than hoping users will self-censor. NHIMG’s Samsung ChatGPT leak 2023 is a useful reminder that employees will paste material into AI tools when the workflow is convenient, even when the material is not appropriate for that channel.

What breaks when prompt controls rely on keywords or after-the-fact review

Keyword-only detection fails because sensitive content often appears in ordinary language. Customer complaints, legal drafts, deal notes, incident updates, and analyst commentary can contain protected data without using obvious trigger terms. Once that material is in the prompt, downstream review is often too late, because the exposure may already exist in model telemetry, vendor retention, or conversation logs.

A second failure mode is over-broad blocking. If the bank blocks too aggressively, employees work around the control by moving to unsanctioned tools or manual copy-paste habits that are even harder to govern. The better approach is to combine classification with proportional controls, so genuinely sensitive prompts are stopped or sanitised, while low-risk work can still proceed.

There is also an availability and assurance problem. If the bank cannot explain why a prompt was allowed or denied, it cannot tune the control, investigate anomalies, or prove compliance to auditors and risk owners. A good prompt policy therefore needs traceable decisions, approved exceptions, and periodic testing against realistic bank workflows.

Risk and Threat Considerations

Banks face both leakage and abuse risk when prompts are treated as ordinary user input. The main exposure is that customer data, trading material, credentials, or internal operational details can be copied into systems that retain, replicate, or expose them beyond the bank’s intended control boundary.

Failure mechanism: Weak pre-prompt classification, permissive logging, or unsafely broad AI access paths allow sensitive content to enter the model flow before any control can redact, reject, or scope it. That can create downstream disclosure through vendor retention, internal logs, or model-assisted summarisation of material that should never have been available to the tool.

Impact: The bank can create privacy, confidentiality, conduct, and regulatory exposure at the same time, especially if the leaked content includes client data, transaction details, or privileged internal information. In practice, the cost is usually not just a single bad prompt, but loss of confidence in the bank’s ability to govern AI use safely.

Practitioner Guidance

What to prioritise: Start with the highest-risk workflows, such as client servicing, legal, HR, trading support, and incident response, because these are the places where sensitive context is most likely to be pasted into prompts. Then define which classes of data must be blocked, redacted, tokenised, or routed into a controlled AI experience.

What to verify: Test whether the control acts before submission, not after the model call, and confirm that logs, prompts, and retrieved context follow the same handling rules as the original source data. If the control cannot explain a decision, it is not ready for sensitive bank use.

Common mistake: Banks often buy a prompt filter and call it governance. The stronger pattern is policy-driven prompt assembly, content minimisation, and exception handling with clear ownership from risk, compliance, and technology.

Practitioner takeaway: The bank should design AI access so that sensitive information is excluded by default, because once the prompt exists, the leakage problem has already moved from prevention to damage control.

Related resources from NHI Mgmt Group

• How should security teams stop employees pasting sensitive data into AI prompts?
• How should security teams prevent sensitive data from leaking through AI prompts and copilots?
• How should security teams govern browser-based AI prompts that may contain sensitive data?
• How should security teams govern AI prompts that include sensitive data?