Production Large Language Model Reliability: Security, Cost and Incident Response

Security for LLM systems extends beyond traditional application security. The OWASP Top 10 for LLM Applications identifies the primary vulnerability categories, including prompt injection, insecure output handling, training data poisoning, model DoS and supply chain vulnerabilities. Each category requires specific controls in the LLMOps layer.

Prompt injection is the most discussed LLM security risk. It occurs when user input contains instructions that override the system prompt—causing the model to follow adversarial commands instead of its intended behaviour. Controls include input filtering (detecting injection patterns), instruction hierarchy (system prompts take precedence over user input), and output safety checks (detecting when the model has been manipulated).

PII handling is a related concern. If user input contains personally identifiable information, the system must decide whether to log it, transmit it to a third-party API provider, or use it for training. PII should be filtered or redacted before logging, and data sharing agreements must cover what is sent to API providers. Access control—determining who can view production logs, change prompts, or deploy models—is a traditional security control that remains essential.

Resilience is the system's ability to continue operating—possibly in a degraded mode—when components fail. For LLM systems, the primary resilience pattern is provider fallback: if the primary model provider (API or self-hosted) fails, the system routes requests to a secondary provider. The fallback chain might be: self-hosted vLLM → API provider A → API provider B → cached response or graceful degradation message.

Circuit breakers prevent cascading failures. If a provider returns errors continuously, the circuit breaker opens and stops sending traffic to that provider, allowing it to recover. Rate limiting prevents any single user or tenant from consuming disproportionate resources—important for both cost control and availability.

Graceful degradation is the ability to provide a reduced but still useful response when the full system is unavailable. For a RAG system, this might mean returning search results without a generated summary. For a chat system, it might mean returning a cached response to a common question. Degradation is better than a hard failure—users get something useful while the system recovers.

Capacity planning for LLM systems must account for both normal load growth and provider failure scenarios. Normal capacity planning estimates traffic growth and provisions GPU or API capacity ahead of demand. Provider failure capacity planning ensures that when the primary provider fails, the fallback provider has enough capacity to absorb the redirected traffic.

For self-hosted systems, autoscaling (Kubernetes HPA or custom autoscalers) adds GPU replicas when load increases. The autoscaling metric should be queue length or TTFT, not just GPU utilisation—GPU utilisation can be high while users are waiting in queue. Autoscaling for GPU resources is slower than for CPU (GPU initialisation takes minutes, not seconds), so headroom must be provisioned in advance.

For API-based systems, capacity is the provider's problem—but rate limits and quota must be understood. If the primary API provider enforces a rate limit of 1000 requests per minute, the system must either stay within that limit or use multiple providers to handle bursts. Multi-provider setups add complexity (different model behaviours, different API formats) but provide resilience.