AI Security in Banking: The Attack Surface Traditional Cybersecurity Doesn't See — and What RBI FREE-AI's Security Pillar Requires

Why AI Security Needs a Different Mental Model Than Network Security

Prompt injection doesn't look like an attack to anything watching your network traffic — it looks like a user typing a normal-looking message. Adversarial manipulation of a credit model doesn't trip a fraud rule, because it's not fraud in the sense your fraud engine was built to catch; it's a crafted input designed to shift a model's output without crossing any threshold your rules engine monitors. KV cache attacks leak customer data through infrastructure your network security team has never been asked to audit. None of these register as attacks in a SOC dashboard, because the attack surface isn't the network — it's the model's inputs, and traditional cybersecurity tooling was never pointed at that layer.

Four Threats That Belong in Your Critical Risk Register, Not Your Backlog

Direct prompt injection overrides system instructions through the model's own input channel — in banking this means overriding compliance filters, exfiltrating account data, or manipulating an agentic workflow into doing something it was never authorized to do, and it's an attack inside the model's input, not inside your network. Indirect prompt injection does the same thing through documents the model processes as part of a normal workflow — a loan application, an email, a PDF — which makes it harder to catch precisely because it arrives through a channel you've already decided to trust by design.

KV cache cross-tenant leakage is the one I'd flag hardest for any bank running shared LLM inference infrastructure: one customer's session cache can contaminate another customer's context, meaning one customer's query can retrieve another customer's account data with no application-layer access violation anywhere in the chain. Agentic scope violations turn a successful prompt injection into an action with real-world consequences — an agent manipulated into executing a transaction or approving a workflow outside its authorized scope doesn't produce a wrong answer, it produces an irreversible event.

Three More Worth Taking Seriously, Even If They're Lower Frequency

Adversarial credit manipulation — systematic probing to find feature combinations that shift a credit score favorably, or to map a model's decision boundary for extraction — is an ML-specific attack pattern your fraud rules were never designed to detect, because nothing about the individual query looks fraudulent. PII exfiltration through conversational manipulation combines old-fashioned social engineering with a new failure mode: a banking LLM with legitimate data access can be talked into disclosing account or transaction information through a conversation that never triggers a policy violation on any single turn. Model extraction and IP theft through systematic API querying matters more for banks running proprietary credit or fraud models than for most LLM-only deployments, but it's worth a line in your risk register if you've built and are exposing a proprietary scoring model via API.

Mapping to OWASP's LLM Top 10, and Why the Mapping Matters

LLM01 (Prompt Injection) is the highest-priority item for banking specifically because both the direct and indirect variants hit customer-facing and document-processing workflows simultaneously. LLM02 (Sensitive Information Disclosure) is where your DPDP Act exposure lives — and that exposure is a Data Protection Board determination against a statutory ceiling, not a fixed formula, so don't let a compliance deck present it as simple arithmetic. LLM06 (Excessive Agency) is squarely the agentic governance problem — the primary controls are an authorization scope manifest and human checkpoints on irreversible financial actions, not a better prompt. LLM08 (Vector and Embedding Weaknesses) covers RAG pipeline poisoning, which matters acutely for banking RAG systems serving compliance and product queries off a knowledge base someone else maintains. LLM09 (Misinformation) is your hallucination exposure — fabricated regulatory deadlines or product terms — and catching it needs grounding verification against source documents, not a general quality score.

What This Means Day to Day for a CRO

None of these eight threats will show up on a security dashboard built before 2023. If your bank's AI security review is still running through a traditional cybersecurity checklist with "AI" added as a bullet point, you are reviewing the wrong layer. The review needs to start from the model's inputs — what it reads, what it retrieves, what tools it can call — not from the network perimeter around it.

Action Checklist: Building an AI-Native Security Review

1. Add all eight threats above to your risk register as named entries, not a single generic "AI risk" line item — each needs its own control and its own test.
2. Prioritize LLM01 and LLM06 first — prompt injection and excessive agency carry the most direct path to irreversible financial consequences.
3. Audit your shared inference infrastructure specifically for KV cache isolation; this is the threat traditional application security review is most likely to miss entirely.
4. Stop presenting DPDP exposure as a fixed per-incident multiplier in board materials — present it as a Board-determined ceiling and model your worst case accordingly.
5. Build grounding verification against source documents for every RAG-backed LLM deployment before you trust its output on a regulatory or product-terms question.