GDPR is the world's most-cited data protection law for AI. HIPAA is the most-cited in US healthcare AI. For Indian banks, neither is the primary obligation — the Digital Personal Data Protection Act 2023 (DPDP Act) is. And no global AI security or data privacy framework has yet mapped LLM-specific exfiltration vectors to DPDP Act's specific obligations.
This gap matters because LLMs create new data exfiltration channels that traditional data security controls were not designed to detect. An SQL injection attack against a database is visible in network logs and access logs. An LLM that discloses another customer's data through a cross-tenant RAG retrieval leaves no obvious signature in conventional monitoring — the LLM produced a response, which is normal behavior. The exfiltration is in the content of the response, not the channel.
This guide maps four LLM-specific data exfiltration vectors to specific DPDP Act obligations — and identifies the controls that address them while generating the evidence trail DPDP compliance requires.
DPDP Act Obligations Relevant to LLM Deployments
Before mapping attack vectors, the relevant DPDP Act obligations:
- Section 4 — Lawful processing. Personal data may only be processed with consent or for a specified legitimate purpose. Using customer data to fine-tune an LLM requires a lawful basis. If the original consent did not cover AI training, fresh consent or a valid statutory basis is needed.
- Section 8(3) — Data accuracy. Data Fiduciaries must ensure personal data used for decisions affecting data principals is accurate and complete. LLM hallucinations about a customer's own financial data trigger this obligation.
- Section 8(5) — Storage limitation. Personal data may not be retained beyond the necessary period. Personal data absorbed into LLM training weights effectively has no retention limit — the model retains statistical traces of training data indefinitely.
- Section 8(6) — Breach notification. Data Fiduciaries must notify the Data Protection Board and affected data principals of any personal data breach, in the prescribed form within the prescribed period. LLM-caused disclosures (cross-tenant leakage, training data reproduction) are breaches under this section.
- Section 9 — Children's data. Processing personal data of children requires verifiable parental consent and prohibits tracking or behavioral monitoring of children. Banks serving minors with AI systems (youth savings accounts, student loan advisors) are subject to this section.
- Section 17 — Data Principal rights. Right to correction, erasure, and grievance redress. An LLM that has been fine-tuned on customer data raises unresolved questions about the right to erasure — whether a model must be retrained when a customer exercises erasure rights over data that was used in training.
Vector 1: Cross-Tenant RAG Retrieval Exposure (OWASP LLM06)
RAG (Retrieval-Augmented Generation) is the dominant architecture for banking chatbots and advisory AI. A RAG system retrieves relevant documents from a knowledge base in response to a query and includes them in the LLM's context for answer generation.
In a multi-tenant deployment — a shared customer service AI serving thousands of customers — the RAG knowledge base may include both general product information and customer-specific documents (prior applications, support tickets, account notes). If the retrieval layer does not enforce tenant isolation, a customer query may retrieve another customer's documents.
Attack scenario
A customer asks: "What is the status of my loan application?" The RAG system queries the document store. A misconfigured retrieval layer returns not only this customer's application status document but also a similarly-worded status document belonging to another customer with an adjacent record ID. The LLM incorporates both documents in its response, producing an answer that includes the other customer's application status, loan amount, or identification details.
The customer received another person's personal data. Under DPDP Act Section 8(6), this is a personal data breach — the bank must notify the Data Protection Board and the affected data principal (the customer whose data was disclosed).
DPDP Act obligations triggered
- Section 8(6): Breach notification to Data Protection Board and affected data principal
- Section 8(1): Obligation to take reasonable security safeguards to prevent personal data breach
Controls
Tenant isolation enforcement at the retrieval layer: every RAG query must be filtered by the authenticated customer's tenant ID before retrieval. The tenant filter must be applied at the vector database level, not the application level — an application-layer filter can be bypassed by injection; a database-level filter cannot. Retrieval output validation: every retrieved document must be validated to confirm it belongs to the requesting tenant before it is included in the LLM context.
Vector 2: KV Cache Cross-Tenant Leakage
KV Cache (Key-Value Cache) is an inference optimization in transformer-based LLMs. When a system prompt or conversational prefix is identical across requests, the model's computed attention keys and values for that prefix can be cached and reused, dramatically reducing inference latency and compute cost.
In a shared LLM deployment, multiple customers share the same inference infrastructure. If the KV Cache is not tenant-isolated, a cached inference state from Customer A's session can be read into Customer B's session when the two sessions share a common prefix (a standard bank greeting, for example).
This is not a hypothetical architectural risk — it is an active concern in every shared LLM serving deployment, including managed API deployments from major LLM providers that Indian banks use through their cloud contracts.
Attack scenario
Customer A completes a session with a banking chatbot that discussed their account balance, upcoming EMI, and a pending transaction dispute. The session state is partially cached for performance.
Customer B initiates a session immediately after. Due to KV Cache mismanagement, B's session inherits context from A's cached state. B asks "what's my balance?" and receives an answer that incorporates A's account balance in addition to (or instead of) B's own.
Unlike a database breach, there is no access log entry for this disclosure. The LLM produced a response — normal behavior. The disclosure is in the response content. Under DPDP Act, this constitutes a personal data breach regardless of whether it was intentional or detectable through conventional monitoring.
DPDP Act obligations triggered
- Section 8(6): Breach notification
- Section 8(1): Reasonable security safeguards (KV Cache isolation is an LLM-specific security safeguard with no equivalent in prior-generation architectures — banks must now govern it explicitly)
Controls
Tenant-isolated KV Caches: each customer session must have its own isolated cache namespace, preventing cross-tenant cache reads. Cache invalidation on session end: a customer's session cache must be invalidated when the session closes, preventing residual context from contaminating subsequent sessions. For managed API deployments: contractual requirement that the LLM API provider implements and certifies tenant-isolated cache management, with evidence available for DPDP compliance documentation.
Vector 3: Training Data Memorization
Large language models memorize subsets of their training data. This is an empirically documented phenomenon — models can reproduce specific phrases, records, and personal identifiers from their training corpora in response to sufficiently targeted queries. The memorization probability increases with:
- Frequency of occurrence in training data (repeated records are more memorized)
- Uniqueness of the data point (rare or distinctive records are more recoverable)
- Model scale (larger models memorize more)
- Fine-tuning on domain-specific data (customer-specific fine-tuning increases memorization risk)
India BFSI scenario
A bank fine-tunes an open-source LLM on its internal corpus: customer support logs, loan origination documents, and KYC correspondence. The fine-tuned model is deployed as an internal assistant for bank staff.
A researcher probing the model's outputs discovers that targeted queries reproduce specific customer names, Aadhaar numbers, and account identifiers verbatim from the training corpus. Under DPDP Act Section 8(6), this constitutes a personal data breach — the model is reproducing personal data it was trained on without authorization.
DPDP Act obligations triggered
- Section 8(5): Storage limitation — training data memorized in model weights effectively has no storage limit. The model retains statistical traces of personal data beyond the declared retention period for the underlying data.
- Section 8(6): If memorized data is reproduced in model outputs, this is a personal data breach.
- Section 17: Right to erasure — if a customer requests erasure of their personal data, does the bank need to retrain models that have memorized that customer's data? DPDP Rules have not yet resolved this question, but the legal risk is real.
Controls
Personal data minimization before training: remove or pseudonymize personal identifiers from training corpora before fine-tuning. Differential privacy for fine-tuning: apply differential privacy techniques that provide mathematical guarantees on memorization bounds. Output monitoring: deploy a PII detection classifier on model outputs to detect and block responses reproducing personal data patterns. Consent review: ensure fine-tuning data was collected with consent covering AI model training as a processing purpose.
Vector 4: Insecure Output Handling — Personal Data in Downstream Systems (OWASP LLM02)
LLM outputs in banking workflows are often piped to downstream systems — CRM records, audit logs, case management systems, API responses. If the LLM output contains personal data that was not authorized for transmission to the downstream system, this is an unauthorized data transfer under DPDP Act.
India BFSI scenario
A customer service AI receives a query about a fraud dispute. In the course of resolving the query, it accesses account details, transaction history, and identification data. The AI's response — including some of this personal data — is automatically logged to a customer interaction analytics platform operated by a third-party vendor.
If the customer did not consent to their personal data being shared with the analytics vendor, this transfer violates DPDP Act Section 4. If the analytics vendor is outside India, RBI data residency requirements and DPDP Act cross-border transfer provisions are additionally engaged.
Controls
Output PII scrubbing before downstream transmission: a PII classifier applied to LLM outputs before they are logged or transmitted to any system outside the primary processing context. Downstream data flow mapping: maintain an up-to-date map of every system that receives LLM output, its data processing agreement, and whether affected data principals have consented to transmission to each downstream system. Cross-border transfer controls: LLM outputs containing personal data of Indian data principals must not be transmitted to servers outside India's designated "adequate" countries without Data Protection Board approval — including to LLM API providers hosting outside India.
DPDP Act Compliance Checklist for LLM Deployments
Lawful basis and consent
- Lawful basis documented for each LLM processing activity (consent, legitimate interest, or statutory)
- Consent notices updated to include AI-assisted processing as a specified purpose
- Fine-tuning data reviewed: confirm consent covered AI model training
- Children's data flagged: separate consent and prohibition on behavioral tracking
Security safeguards
- Tenant isolation in RAG retrieval layer — validated, not assumed
- KV Cache tenant isolation for all shared inference deployments
- PII scrubbing applied to LLM outputs before logging or downstream transmission
- Training data personal data minimization process documented
Breach detection and notification
- LLM-specific breach monitoring: RAG retrieval anomalies, cross-tenant response patterns, PII in outputs
- Breach notification procedures cover LLM-caused breaches (not just traditional data incidents)
- 72-hour notification capability to Data Protection Board from breach discovery
- Data principal notification process tested
Data principal rights
- Right to correction process covers AI-generated personal data inaccuracies
- Right to erasure policy addresses model training data — legal position documented
- Grievance redress officer designated and accessible for AI-related complaints
Data residency and cross-border transfer
- LLM API provider processing location documented: does inference occur on India-resident servers?
- Customer personal data included in prompts treated as cross-border transfer if processed outside India
- Data Processing Agreements with LLM API vendors reviewed for DPDP Act compliance
DPDP Act + LLM security, covered together
Zytra's KV Cache Governance prevents cross-tenant leakage at the inference layer. Aval's LLM06 controls detect and block sensitive information disclosure in real-time. Every incident generates DPDP Act-aligned evidence: what was disclosed, to whom, when, and what control was in place. Breach notification timelines start from a governed, timestamped event record.
Related reading
- OWASP LLM Top 10 for BFSI India 2026: full vulnerability and control guide
- Agentic AI security India BFSI: prompt injection in UPI and credit agents
- India BFSI AI governance: complete multi-regulator guide
- DPDP Act 2023: AI compliance obligations for Indian banks
- RBI MRMF 2026: model risk management for banking AI