Cap what a single request can ask for and how many requests one caller can make. That means body size, input and output tokens, parallel output samples, queue depth, timeouts and per-user rate. OWASP lists these under unbounded consumption, and vLLM documents a limit on the samples-per-request parameter.
What unbounded consumption means
OWASP's 2025 list for LLM applications includes LLM10, Unbounded Consumption. It describes an application that lets users run excessive and uncontrolled inferences. The result can be a service outage, a large bill, or model theft through volume of queries.
With a hosted API, the provider caps some of this and bills you for the rest. With a self-hosted server, your GPUs are the bill, and one caller can fill the queue for everyone.
The parameters worth capping
| Control | What to set | Where |
|---|---|---|
| Request body size | A limit that fits your longest legitimate prompt | Reverse proxy |
| Output length | A server and per-key maximum on generated tokens | Server config, app layer |
| Parallel samples | A low cap on the n parameter | Server and proxy |
| Concurrency and queue | A bound on in-flight and queued requests | Server, proxy |
| Timeouts | A wall clock limit per request | Proxy, app |
| Per-user rate | A quota per key or account | Proxy, app |
The vLLM docs describe the n parameter, which sets how many independent output sequences are produced per request. A very large value makes memory and GPU time grow in proportion and can cause out of memory conditions that block other requests. vLLM enforces an upper bound through VLLM_MAX_N_SEQUENCES, with a default of 16384, and the docs suggest values such as 64 or 128 for public-facing deployments.
OWASP mitigations, in plain words
The OWASP page lists ten mitigations. The ones that map most directly to a self-hosted server are:
- Input validation, with strict size limits.
- Limit exposure of logits and logprobs, so responses do not reveal more than needed.
- Rate limiting and user quotas.
- Resource allocation management, so no request takes everything.
- Timeouts and throttling for heavy operations.
- Logging, monitoring and anomaly detection on resource use.
- Graceful degradation under load.
The page also lists sandboxing and watermarking. Those are worth reading, but the first seven are what you can configure this week.
A quick build order
- Put a reverse proxy in front. Set the body size, timeout and rate limit there.
- Pick a maximum output length per key and enforce it in the layer that calls the model.
- Lower the parallel samples cap from its default.
- Set a queue limit and decide what happens at the limit. Return a clear busy error instead of letting latency grow without end.
- Log tokens in and out, latency and the caller id for every request, without logging the prompt text itself where it holds sensitive data.
- Alert on a caller who uses far more than their usual share.
The vLLM docs also advise monitoring per-request resource use to spot anomalous patterns, which fits step six.
Test it
Send an oversized body, a request with a very large n, and a burst of parallel calls from one key. Confirm each is rejected or throttled, and that other users keep getting responses during the burst.
Quick check
Is rate limiting per IP enough?
Not usually. Limit per authenticated key or account, and add an IP limit as a second layer.
Does a smaller model remove the need for limits?
No. A small model is cheaper per request, but an unbounded caller can still saturate it.
Where Safeguard fits
Safeguard handles dependency scanning, policies and gates, and compliance evidence automation, which can record that limits like these are part of your release checks. A free scan takes a few minutes.
Sources
- OWASP LLM10:2025 Unbounded Consumption, read 19 October 2026.
- vLLM security documentation, read 19 October 2026. This is the developer preview version of the docs.
Last reviewed: 19 October 2026.
