How to Deploy an LLM Securely in an Enterprise Environment

Secure LLM deployment is the practice of running a large language model with controls that protect the data it sees, limit what it can do, and make its behavior auditable, from model files and serving infrastructure to retrieval, agent tools, and logs. Traditional application security still applies, but LLMs add risks it does not cover: instructions hidden in documents, answers that reveal data a user should not see, and agents that act on manipulated output. The OWASP Top 10 for LLM Applications (2025) maps those risks, and each one translates into specific controls.

The Risk Map: OWASP Top 10 for LLM Applications (2025)

The rest of this guide groups these into layers, with the controls that close each risk.

Layer 1: Model Supply Chain

A model is code and data from an outside party. Treat it like any third-party dependency.

• Prefer safetensors over pickle-based formats. Pickle-based checkpoint files can execute code when loaded. Safetensors stores only tensors.
• Pin and verify. Record the source, version, and file hashes of every model you deploy, and verify hashes at load time.
• Review licenses. Open-weight model licenses vary in commercial and acceptable-use terms. Record approval before production.
• Scan containers. Inference images include drivers, CUDA libraries, and Python packages. Scan them like any production image and rebuild on a schedule.
• Keep a private registry. Store approved models and fine-tuned weights in an internal registry with access control, rather than pulling from public hubs at deploy time.

Layer 2: Serving Infrastructure

Limits Against Unbounded Consumption

LLM10 is an infrastructure risk with a measurable cost. KV cache memory grows with context length. For a 70B model in BF16, the cache needs about 0.33 MB per token. A single request that fills a 131,072-token context therefore holds about 43 GB of GPU memory, more than half of an 80 GB GPU, for as long as it runs. A handful of such requests can starve every other user.

Set these limits at the gateway and in the inference engine:

Layer 3: Data and Retrieval

Most enterprise LLM incidents involve data the model was given, not data it was trained on. Retrieval-augmented generation (RAG) is where access control most often fails.

Permission-Aware RAG, Step by Step

1. Index with permissions. When documents are chunked and embedded, store the source system's access control list with each chunk.
2. Authenticate the user, not just the application. The retrieval service must know which user is asking.
3. Filter at query time. Retrieve only chunks the user is allowed to read, using the stored permissions as a filter in the vector search.
4. Re-check sensitive sources. For high-sensitivity documents, verify access against the source system at query time, because permissions change after indexing.
5. Log what was retrieved. Record which chunks were returned for each request, so disclosures can be investigated.
6. Re-index on permission changes. Update or remove chunks when documents are deleted or access changes.

Pass criterion: a test user without access to a document receives no content from it, even when asking for it by title.

Training and Fine-Tuning Data

Minimize sensitive data in fine-tuning sets. Models can reproduce training examples, and a fine-tuned model inherits the sensitivity of its data. Treat fine-tuned weights with the same access controls as the dataset.

Layer 4: Prompts, Outputs, and Agents

Prompt injection cannot be fully prevented by filtering. Instructions can hide in emails, web pages, and documents the model reads. The reliable defense is limiting what injected instructions can achieve: the model should not hold permissions that would cause harm if it followed malicious text.

Treat output as untrusted input. Validate model output before it reaches a database query, a shell, a browser, or another system. Escape it for the context where it is displayed.

Constrain agents. For each tool an agent can call, define the narrowest permission it needs, allowlist target systems, and require human approval for irreversible actions such as payments, deletions, or external messages.

Keep secrets out of system prompts. Assume users can extract the system prompt. Credentials and access logic belong in the systems the model calls, not in its instructions.

Layer 5: Logging, Monitoring, and Retention

Logs are needed for investigation and evaluation, but prompts and responses are sensitive data in their own right.

Keep logs and traces in the same controlled environment as the model. Sending prompts to an external observability service moves sensitive data outside your controls.

Layer 6: Evaluation and Red Teaming

Run security tests before launch and after each model or prompt change:

• Prompt injection tests using documents with embedded instructions
• Data disclosure tests with users who lack access to specific documents
• Agent misuse tests that try to trigger unauthorized tool calls
• Load tests with long-context requests to verify limits
• Regression tests on an evaluation set for accuracy and refusal behavior

NIST's Generative AI Profile (NIST AI 600-1, published July 2024) provides a framework for documenting these risks and tests. Documented testing also has legal value: Texas's TRAIGA, for example, treats violations found through internal red teaming, and substantial compliance with the NIST AI Risk Management Framework, as grounds for a safe harbor.

Go-Live Checklist With Pass Criteria

For the broader operational go-live process for AI models, see the secure AI model deployment checklist.

Where the Model Runs Matters

Self-hosting an open-weight model on dedicated infrastructure keeps prompts, retrieved documents, and logs inside one controlled environment. OneSource Cloud's Private AI Infrastructure provides that environment in U.S. data centers, including Richardson, Texas. The OnePlus Platform, OneSource Cloud's AI orchestration platform, runs inference services, quotas, and developer tools inside it, and Managed AI Infrastructure covers patching, monitoring, and incident response.

FAQ

What is the biggest security risk when deploying an LLM?

For most enterprises, it is sensitive information disclosure through retrieval: the model returns content from documents the user could not open directly. Permission-aware RAG, with filtering at query time, is the main control.

Can prompt injection be prevented?

Not completely. Filters reduce it, but instructions can hide in any content the model reads. The reliable control is limiting the model's permissions and validating its output, so injected instructions cannot cause serious harm.

Is self-hosting an LLM more secure than using an API?

It gives you more control over data location, logging, and access, which matters for regulated data. It also makes you responsible for patching, network security, and model supply chain controls.

How should LLM prompts and responses be logged?

Log request metadata for audit, and keep prompts and responses for a defined period with redaction and restricted access. Keep logs inside the controlled environment rather than sending them to external services.

Which framework should we use for LLM security?

Use the OWASP Top 10 for LLM Applications (2025) to map technical risks, and NIST AI 600-1 to document risk management and testing. Map both to your existing security and compliance frameworks.

Summary

Deploying an LLM securely means controls at six layers: model supply chain, serving infrastructure, data and retrieval, prompts and agents, logging, and testing. Map each control to the OWASP Top 10 for LLM Applications. Enforce limits against unbounded consumption, since one long-context request can hold tens of gigabytes of GPU memory. Build permission-aware retrieval, constrain agents, and keep logs inside the controlled environment. Then prove it with tests that have pass criteria before go-live.

To run LLMs on infrastructure where prompts, data, and logs stay under your control, explore OneSource Cloud's Private AI Infrastructure.