LLM Security in Banking: Six Threat Categories Your Firewall Cannot See — and How to Build a Guardrails Architecture That Passes Examination

Why a Network Firewall Can't See the Attacks That Matter Here

A firewall inspects packets for known-bad patterns. An LLM's attack surface isn't a packet — it's meaning, embedded in a document that looks completely ordinary to every security tool that came before generative AI. A customer submitting a loan application with adversarial text buried in a PDF isn't generating malicious network traffic; they're generating a normal-looking document that, once your retrieval pipeline pulls it into context, activates instructions the model has no way to distinguish from your own system prompt. Catching that requires a classifier trained on what the content means, not an inspector trained on what the traffic looks like.

I've reviewed incident writeups where the SOC dashboard showed nothing unusual, because nothing unusual happened at the network layer — the entire attack lived inside a document that passed every conventional check on the way in.

Six Threats, and Why Banking Makes Each One Worse

Direct prompt injection tries to override your system instructions through user input, aiming to bypass compliance filters or redirect an agent's actions — the highest-priority category under OWASP's LLM Top 10, and the one RBI's security expectations most clearly anticipate. Indirect prompt injection does the same thing through documents your RAG pipeline retrieves, which is more dangerous precisely because it travels through a channel you've already decided to trust. PII exfiltration uses ordinary-sounding conversation to coax account or transaction data out of an LLM that has legitimate data access — DPDP Act exposure applies the moment this succeeds, and the penalty ceiling (up to ₹250 crore for a breach stemming from inadequate security safeguards) is not a number any bank wants to test in practice.

Jailbreaks try to override safety constraints directly, pushing the model into financial advice or disclosures it isn't authorized to make. KV cache leakage is the one most security teams haven't thought about at all: in shared inference infrastructure, one customer's session data can bleed into another's context at the cache layer, which is a cross-tenant data breach that has nothing to do with application-layer access controls. And hallucination with financial consequences — a fabricated regulatory deadline or invented beneficiary detail that a staff member or customer acts on — is a security failure with a compliance price tag attached, even though it doesn't look like a traditional attack at all.

A Three-Layer Architecture, Because One Layer Always Misses Something

Pre-generation input classification has to screen every input before it reaches the model, using a classifier trained on BFSI-specific adversarial data rather than generic regex rules, and it has to do this fast — under roughly 20 milliseconds, or you're adding latency your customer notices — and accurately, because a false-positive rate above roughly 1% means real customers getting blocked at a rate that shows up in your complaint volume. Post-generation output verification catches what gets through anyway: check that account numbers, product names, and regulatory citations in the output actually match the source documents retrieved, and separately classify the output itself for policy violations the input classifier never saw coming, because a jailbreak that succeeds doesn't announce itself at the input stage. Behavioral consistency monitoring is the layer most banks skip, and it's the one that catches slow drift and successful injection alike — both show up as a shift in the output distribution over time, which no single-query check will ever notice.

The Multilingual Attack Surface No Procurement Checklist Asks About

Here's the gap that doesn't show up in a vendor demo: prompt injection and jailbreak patterns translated or reconstructed in Hindi, Tamil, Bengali, or Telugu get past English-trained detection classifiers at a dramatically higher rate than the same attack in English — recall drops sharply, often below the level that would be acceptable in English. If your bank deploys LLMs in regional languages and your guardrail vendor only shows you English red-team results, you have not actually tested your deployment; you've tested a different deployment that happens to share a model. This is not a theoretical gap — it's an operational one sitting in production today at banks that assumed a guardrail's English performance would generalize.

What an Examiner Will Actually Ask to See

Expect to be asked for pre-production adversarial test results — the model version tested, the methodology, the failure cases found, and what you did about them — not a summary paragraph claiming testing occurred. Expect a request for runtime guardrail performance metrics broken out by threat category, with language-specific numbers if you run a multilingual deployment. Expect a question about KV cache isolation architecture for any multi-tenant inference setup, and expect that "we handle it at the application layer" will not satisfy a question about the inference layer specifically. And expect a Forensic Replay request: reconstruct a specific LLM output, with its model version, system prompt version, and input context, as if it happened yesterday.

Action Checklist: Closing the Gaps Before an Examiner Finds Them

1. Deploy pre-generation input classification trained on BFSI adversarial data, with FPR under roughly 1% and latency under roughly 20ms, and measure both numbers yourself rather than trusting a vendor benchmark.
2. Add post-generation output verification — entity consistency against source documents, plus a second classification pass on the generated text itself.
3. Stand up behavioral consistency monitoring on output distribution, not just accuracy metrics, so drift and successful injection both surface before a customer complaint does.
4. Run adversarial testing in every regional language you deploy in, not just English, and treat a vendor's English-only red-team report as an incomplete answer.
5. Build Forensic Replay capability now — model version, system prompt version, and input context reconstructable for any past output — before an incident forces you to build it under deadline pressure.