Large language models can search documents, draft responses, support employees, and automate decisions. They also create a new path from sensitive enterprise systems to an unpredictable interface. A user prompt, retrieved document, tool call, or model response can expose information even when the underlying database remains protected.
Securing enterprise data for LLM applications therefore requires more than choosing a private model or adding a content filter. Security must be designed across the full lifecycle: data ingestion, indexing, retrieval, inference, tool execution, output handling, monitoring, and deletion. For Indian organisations, the design must also account for the Digital Personal Data Protection Act, sector-specific obligations, contractual data-residency requirements, and the operational realities of cloud and on-premise deployments.
Start with a data and threat inventory
Before selecting a model, document what the application can access and what it is allowed to do. Classify sources such as HR records, customer tickets, source code, contracts, health information, financial data, and public content. Record the owner, sensitivity, retention period, permitted users, geography, and approved processing purpose for each source.
Map the application’s trust boundaries:
- User interface and identity provider
- Application server and orchestration layer
- Document parsers and ingestion jobs
- Embedding and reranking services
- Vector and keyword indexes
- Foundation-model provider or self-hosted inference cluster
- Plugins, APIs, databases, email, and other tools
- Logs, evaluation datasets, backups, and analytics systems
This inventory exposes a common failure: an application may have strong database permissions but copy confidential records into prompts, traces, support tickets, or model-provider logs. Treat every copy as a separate data store with its own access and retention policy.
Build permission-aware RAG, not a shared document pool
Retrieval-Augmented Generation is usually preferable to putting proprietary material directly into model weights. It keeps documents updateable and makes deletion more practical. However, RAG is secure only when retrieval enforces the same permissions as the source system.
Attach document-level and chunk-level metadata during ingestion, including business unit, tenant, classification, owner, geography, retention date, and source-system permissions. At query time, resolve the user’s identity and entitlements before retrieval. Apply filters in the database or search engine—not after the model has already received the context. A response-level disclaimer cannot undo an unauthorised retrieval.
Use tenant isolation for multi-customer products. For highly sensitive workloads, separate indexes or accounts may be preferable to relying solely on metadata filters. Test for cross-tenant leakage with adversarial queries, including requests that combine innocuous terms to reconstruct a restricted document.
Data quality is also a security control. Poisoned, stale, or incorrectly labelled documents can produce unsafe answers and privilege mistakes. Teams working on high-stakes systems should pair access controls with data veracity infrastructure for high-stakes AI, including provenance, validation, versioning, and quarantine workflows.
Minimise and transform sensitive data
Do not send every available field to an embedding model or LLM. Apply purpose limitation at ingestion and query time:
- Remove fields that are not needed for the task.
- Tokenise or mask Aadhaar numbers, PAN details, bank information, phone numbers, and health identifiers.
- Keep the mapping between placeholders and real identities in a separately protected service.
- Restrict raw PII in prompts, traces, evaluation sets, and developer environments.
- Define retention and deletion procedures for source files, chunks, embeddings, caches, and backups.
Regular expressions help with predictable identifiers, but production pipelines need entity recognition, validation checks, and sampling by trained reviewers. Masking can also damage meaning; test whether the transformed text still supports accurate retrieval and whether rare combinations can re-identify a person.
Fine-tuning deserves additional scrutiny. It can improve specialised behaviour, but sensitive information embedded in model weights is difficult to remove and may be exposed through extraction attempts. If custom training is necessary, follow disciplined best practices for fine-tuning LLMs on custom data: use minimised datasets, segregated training infrastructure, evaluation for memorisation, and a documented deletion strategy.
Secure prompts, tools, and model outputs
System prompts are useful instructions, not an access-control mechanism. Assume that users and retrieved documents may attempt prompt injection. Treat all external text as untrusted data, clearly separate instructions from content, and never let retrieved text redefine the application’s policies.
Put an AI gateway between clients and model providers. It should enforce authentication, rate limits, model allow-lists, payload-size limits, PII detection, prompt and output policies, and provider-specific logging settings. Add canary secrets to test whether the application reveals protected instructions or credentials, but never place real secrets in prompts.
Tool use creates a higher-risk boundary. Give each tool a narrow schema and a separate service identity. Use allow-listed operations, parameter validation, timeouts, network egress controls, and approval gates for actions such as sending email, changing records, issuing refunds, or publishing content. Prefer read-only tools by default. A model should not receive a general-purpose database credential or unrestricted shell access.
Validate outputs before they reach users or downstream systems. Check citations, structured fields, policy constraints, sensitive-data patterns, and action authorisation. For legal, medical, financial, employment, and customer-impacting workflows, require human review before an irreversible action. Indian healthcare deployments should also account for domain-specific verification expectations, including ICMR-compliant medical AI data verification in India.
Choose deployment and vendor controls deliberately
Self-hosting can reduce exposure to external providers, but it does not automatically make a system secure. The organisation still owns patching, model files, GPU hosts, secrets, access management, network isolation, backups, and incident response. Private cloud deployments should use private endpoints, restricted egress, encryption in transit and at rest, workload identities, and separate development and production environments.
For managed APIs, confirm in writing:
- Whether prompts, outputs, and uploaded files are used for provider training
- Data retention, deletion, and backup timelines
- Storage and processing locations
- Subprocessors and incident-notification commitments
- Encryption, access logging, and customer-managed key options
- Support access and privileged-operator controls
- Availability of zero-retention or regional processing modes
A smaller open-source model deployed in a controlled environment may be safer than a larger model connected to excessive data and tools. Evaluate the whole system, including scaling backend infrastructure for AI applications, rather than comparing model benchmarks alone.
Monitor, test, and rehearse failure
Log enough to investigate incidents without creating another uncontrolled PII repository. Capture user identity, policy decisions, retrieved-document identifiers, tool calls, model version, latency, token usage, and output classifications. Where possible, store redacted prompt and response samples with strict access controls and defined retention.
Create an evaluation suite before launch and run it after every model, prompt, retrieval, or policy change. Include direct and indirect prompt injection, data exfiltration, cross-tenant queries, membership inference, jailbreaks, poisoned documents, excessive tool calls, and denial-of-service inputs. Measure both security and utility: false blocks can push users toward unsanctioned tools, while weak controls create silent leakage.
Red-team the complete application, not just the base model. Monitor unusual retrieval volume, repeated failed authorisation attempts, access to many unrelated business units, suspicious export patterns, and tool calls outside normal working profiles. Define playbooks for revoking tokens, disabling tools, isolating indexes, rotating credentials, notifying affected parties, and preserving evidence.
A practical rollout checklist for Indian teams
Use staged deployment rather than connecting an LLM to the entire enterprise on day one:
1. Start with a low-risk, read-only use case and a small approved corpus.
2. Establish data classification, identity integration, retention, and vendor review.
3. Implement permission-aware retrieval and PII minimisation before optimisation.
4. Add gateway controls, tool allow-lists, output validation, and human approval.
5. Test with realistic adversarial prompts and unauthorised-user scenarios.
6. Expand data sources only after security, accuracy, and operational metrics meet agreed thresholds.
If internal engineering capacity is limited, compare providers using a security-focused enterprise AI development studio buyer’s guide, and require evidence of deployment architecture, testing, support ownership, and data-handling practices.
Frequently asked questions
Does a private LLM guarantee security?
No. It reduces dependence on an external provider but does not prevent compromised accounts, insecure retrieval, prompt injection, insider misuse, vulnerable infrastructure, or excessive tool permissions.
Is RAG always safer than fine-tuning?
Not always, but RAG generally offers better control over updates, permissions, and deletion when implemented correctly. A poorly secured RAG index can still leak more data than a carefully governed model.
How should DPDP obligations affect design?
Identify the purpose and lawful basis for processing personal data, minimise collection, control access, define retention and deletion, manage processors contractually, and maintain evidence of safeguards. Obtain legal advice for sector-specific and cross-border requirements; technical controls should support, not replace, governance.
What is the most important control?
Enforce identity-aware authorisation before retrieval and tool execution. A strong model or prompt firewall cannot compensate for giving the application more data or authority than the user should have.