When banks use AI in customer service, fraud detection, application review, or employee support, the security question is often framed too narrowly: is the model secure? In practice, even a capable model can become a source of risk if it uses inappropriate data, receives excessive access, connects to other systems without adequate controls, or operates without clear human accountability. AI security in banking cannot therefore be assigned only to the technology team. It is a governance issue covering the full path through which AI receives data, produces responses, and affects systems.
This risk is becoming more important because AI can strengthen both defence and attack. A September 2026 report by the Bank for International Settlements argues that advanced AI systems can shorten the time needed to identify vulnerabilities, develop exploits, and conduct multi-step cyber operations. This gives financial institutions less time to respond. Yet the same technology can support vulnerability discovery, anomaly detection, and faster incident response. The relevant question is not whether banks should use AI, but where its boundaries should be and how it should be controlled.
1. Protect data before protecting the model
The most sensitive asset is not always the model. It is often customer data, account information, transaction histories, credit files, internal documents, and authentication data. If employees enter such information into an unapproved AI tool, the bank may lose control of the data even when the tool produces a correct answer.
The starting point should be to classify data by sensitivity and define what each AI system is allowed to receive. Test data should be minimised, de-identified, or replaced by synthetic data where appropriate. Knowledge sources available to AI should also be separated by role; employees should only receive content they are already authorised to view. The simple principle is that AI must not become a shortcut around existing access restrictions.
Applied example
An internal AI assistant may help employees search account-opening procedures. If the same assistant is connected directly to customer records, transaction histories, and notification systems, its risk profile changes completely. Each integration needs its own assessment rather than being treated as another feature of a question-answering tool.
2. Control access and the ability to act
A system that only drafts text presents a different level of risk from one that can freeze an account, modify a record, send a notification, or initiate a transaction. AI permissions should therefore follow the principle of least privilege: read-only by default, access only to necessary sources, and no autonomous authority over high-impact actions.
Human approval should be required before decisions that affect money, customer rights, or access to services. Secrets such as passwords, access keys, and connection details should not be placed in prompts or model instructions. Every data access and tool call should be logged so the bank can determine who made the request, which sources were used, and what action took place.
3. Protect instructions and integrations
AI can be manipulated by harmful content embedded in a question, email, document, or web page that the system has been asked to read. NIST includes direct and indirect prompt injection within its broader treatment of adversarial machine-learning risks. A seemingly ordinary document may contain instructions intended to make the AI ignore its rules, reveal information, or use a tool in an unintended way.
Banks should not treat every input as trustworthy. Systems need to separate data from instructions, restrict which tools a model can call, check outputs before they move to the next step, and block requests that exceed scope. For important processes, an explicit list of permitted actions is safer than allowing an AI system to choose any available operation.
4. Manage third-party risk
An AI application rarely depends on a single provider. It may combine a model, an application interface, a retrieval database, monitoring services, extensions, and computing infrastructure supplied by different organisations. If one component changes its data-retention policy, delays a security patch, or becomes unavailable, the bank’s operational risk can increase.
Banks need a complete inventory of AI components, current versions, data shared with each party, and accountable owners. Contracts should clarify data retention and use, incident-notification periods, patching requirements, audit rights, and exit arrangements. This also reflects the direction of the Financial Stability Board’s proposed sound practices: AI governance should operate across the organisation and throughout development, deployment, and use.
5. Monitor behaviour, not only answers
Testing a small set of answers before launch is not enough. Risk can emerge when the model is updated, data sources change, user volume grows, or attackers try new techniques. Banks need to monitor system behaviour over time: which sources the AI accesses, whether tool-call frequency is unusual, whether human rejection rates are rising, and whether data is moving outside expected boundaries.
Practical safeguards include regular adversarial testing, rate limits, anomaly alerts, complete audit trails, and a rapid stop mechanism. Each change to the model, system instructions, data sources, or access rights should be versioned so that the service can return to a safe state. The BIS paper on generative AI and cyber security similarly shows that potential gains in threat detection coexist with concerns about social engineering and unauthorised data disclosure.
Where should a bank start?
A prudent approach is to begin with an internal workflow that has clear value but limited consequences, such as an assistant that searches approved policies and operating guidance. At the first stage, the system should only read authorised sources, should not access real transaction data, and should have no transaction authority. The bank can then measure answer quality, correction rates, out-of-scope cases, and traceability before expanding the service.
Each use case should be assessed through three questions: what data can the AI see, what decision can it support, and what action can it take? If all three are highly sensitive, the control requirements must be substantially stronger. Expansion should not be based merely on the convenience of an early pilot; it should depend on evidence of accuracy, controllability, and incident readiness.
Conclusion
AI security in banking is not achieved by building another protective layer around the model. Banks need to protect data, restrict access, control integrations, manage providers, and monitor behaviour throughout operation. The more an AI system can act, the clearer human accountability must become. A secure AI system is not one that never fails. It is one designed so that an error is less likely to become a loss and, when an incident occurs, the organisation can detect, stop, and recover quickly.
References
Bank for International Settlements. (2026). When machines attack: Frontier AI cyber threats and policy responses in the financial sector.
Financial Stability Board. (2026). Sound practices for the responsible adoption of artificial intelligence.
National Institute of Standards and Technology. (2025). Adversarial machine learning: A taxonomy and terminology of attacks and mitigations.
