What are the main AI security threats in financial services?

The main AI security threats in financial services fall into ten categories: (1) Prompt injection — adversarial instructions in user input or retrieved documents override system constraints; the highest-priority threat for banking AI, especially LLMs and agentic systems; (2) Adversarial examples — carefully crafted inputs fool ML models into making incorrect decisions; particularly severe for fraud detection (adversarial transactions designed to evade detection) and credit scoring (adversarial application data); (3) Model theft and extraction — systematic querying to replicate a proprietary model; banks invest heavily in fraud and credit models, and model extraction creates intellectual property loss and regulatory exposure (extracted model used by competitors or in AML evasion); (4) Data poisoning — corrupting training data to cause systematic model failures; particularly relevant for transaction data used to train fraud detection; (5) Supply chain attacks — malicious components introduced into AI model supply chains (pre-trained models, third-party datasets, ML libraries); OWASP LLM05 documents this for LLM supply chains; (6) Membership inference — determining whether specific records were in training data; high-risk for models trained on confidential BFSI data; (7) Model inversion — extracting training data from model outputs; creates DPDP Act exposure for models trained on customer data; (8) Cross-tenant data leakage — shared LLM inference infrastructure allows one customer's data to contaminate another's outputs; (9) Indirect prompt injection — adversarial instructions in retrieved documents hijack agent actions; (10) Multi-agent manipulation — compromising one agent in a pipeline to manipulate downstream agents.

How does AI security differ from traditional cybersecurity in banking?

AI security in banking differs from traditional cybersecurity in three fundamental ways: (1) Attack surface — traditional cybersecurity protects network infrastructure, endpoints, and application logic. AI security protects models themselves: the model's decision boundary (adversarial examples), its training data (poisoning), its parameters (model extraction), its context window (prompt injection), and its inference infrastructure (cross-tenant leakage). None of these exist as an attack surface in traditional systems. (2) Attacker profile — traditional cyber threats primarily come from external attackers. AI attacks are often conducted by the system's own authorized users — a customer submitting adversarial loan application data, a chatbot user finding prompt injection bypasses, a data scientist on a competing firm running model extraction queries. Authorization doesn't prevent AI attacks. (3) Detection difficulty — traditional security attacks often leave infrastructure evidence (network anomalies, log anomalies). AI attacks often produce no infrastructure signature — an adversarial example looks exactly like a normal transaction; a model extraction query looks exactly like a normal API call. Detection requires AI-specific monitoring, not traditional SIEM.

What AI security controls are required by banking regulators?

Banking regulators require AI security controls across three areas: (1) Adversarial robustness testing — required by RBI FREE-AI Security pillar, RBI draft eMRM guidelines, EU AI Act Art. 15 (accuracy and cybersecurity robustness), and NIST AI RMF MEASURE 2.7. Banks must demonstrate that AI systems have been tested against adversarial inputs specific to their deployment context. For LLMs: prompt injection, jailbreak, and indirect injection testing. For ML models: adversarial example testing with BFSI-specific attack patterns (adversarial credit applications, adversarial fraud transactions). (2) Runtime monitoring for adversarial activity — RBI FREE-AI Reliability requires continuous monitoring; the FREE-AI Security pillar requires detection capability for adversarial inputs in production. This means production-time classification of inputs and outputs, not just pre-deployment testing. (3) Incident reporting for AI security events — RBI Cyber Security Framework (2hr breach notification, 6hr forensic reporting), DPDP Act §8 (72hr personal data breach notification), EU AI Act Art. 73 (15 working days for serious incidents). AI security incidents that result in data exfiltration, unauthorized model access, or data poisoning trigger these reporting obligations.

AI Security for Financial Services: Attack Surface, Threat Actors, and Controls

A bank's SOC can tell you about a port scan in real time. It has no equivalent instinct for a fraud model being probed into revealing its decision boundary, because that probing looks exactly like normal traffic. AI security is not an extension of the existing cybersecurity program — it is a different attack surface, with attackers who don't need network access to do damage, and a detection problem the SOC's existing tooling was never built to solve.

The ten threats that matter, and why most SOCs miss them

Prompt injection is the one everyone has heard of and the one that still gets through most often, because indirect injection — instructions buried in a document the model retrieves rather than typed by the user — can't be caught at the input filter. If your guardrail only inspects what the customer typed, you have covered maybe half the attack surface for any RAG-based assistant.

Adversarial examples target a different layer entirely: inputs engineered to sit just across a fraud or credit model's decision boundary. Unlike a jailbreak, which manipulates an LLM's instructions, an adversarial example manipulates a statistical model's math, so the fraud and underwriting models banks have run for a decade are exposed here too, not just the new LLM deployments.

Cross-tenant leakage through a shared inference cache is the one that should worry a CISO most, because it produces no anomaly signature at all — it looks like ordinary inference traffic right up until a customer complains that a chatbot surfaced someone else's account details. Either way, the exposure scales with customer volume in a way a traditional data breach at a single point in time does not, and that alone should move KV-cache isolation up the priority list.

Model extraction is the quiet one: a competitor or fraud ring issuing enough API calls to reverse-engineer a proprietary fraud or credit model's decision logic, indistinguishable from a high-volume legitimate integration until someone notices the query pattern looks like a grid search rather than real transactions. Data poisoning and AI supply chain attacks both bet on banks trusting an upstream provider's attestation instead of validating independently — the dangerous version of a poisoned model is the one that passes every standard validation metric and only fails on the specific pattern the attacker planted.

Agentic authorization evasion is the newest and, for any bank running LLM agents against payment or account-modification APIs, the most consequential: a system prompt telling an agent not to exceed its scope is not a security control, because a sufficiently motivated prompt injection can talk the agent out of following it. Authorization has to be enforced at the tool-call layer, where the agent physically cannot call an API outside its granted scope, regardless of what the prompt says.

Controls regulators actually expect to see

The table of threat-to-control mappings in the original holds up reasonably well on substance — runtime classification for injection, adversarial testing pre-deployment, KV-cache tenant isolation, API rate-limiting for extraction, data provenance for poisoning, and independent vendor-model validation for supply chain risk. Where it overreaches is in the specific statutory and framework citations: treat "MAS TRM §12/§13," "RBI eMRM," and "OWASP LLM01/LLM05/LLM08" as pointers to verify against the current version of each document rather than settled citations, since section numbering in TRM-style guidelines and OWASP's own list both get revised.

What this means for a bank's security program

A traditional pen test tells you nothing about whether your fraud model can be evaded by an adversarial transaction, and a traditional SOC dashboard tells you nothing about whether your chatbot leaked one customer's balance into another customer's session. Those require AI-specific red-teaming and AI-specific monitoring, run by people who understand both the attack techniques and the specific model in production — not a checkbox added to the existing annual pen test scope.

Where to start

Run adversarial testing against every production fraud and credit model, not just the LLM-based tools — the oldest models in your stack are exposed to the oldest attack class here.
Treat indirect prompt injection as a document-ingestion problem, not a user-input problem, and test your RAG pipelines accordingly.
Instrument KV-cache or shared-inference infrastructure for tenant-isolation violations before a customer complaint finds one for you.
Move agentic authorization enforcement to the tool-call layer — audit every agent with payment or account-modification access and confirm the system prompt is not the only control standing between it and an unauthorized transaction.
Independently validate every vendor and foundation model in production; a vendor's security attestation is not evidence your bank can present to an examiner as its own.