On a multi-tenant LLM inference gateway, we would fix the attack paths that cross the tenant boundary first: leakage through the shared KV/prefix cache, endpoints that sit outside authentication, tenant escape through untrusted models or adapters, and resource exhaustion that lets one tenant degrade everyone else. To arrive at that shortlist in a way that survives a customer security review, use threat modeling with STRIDE to scope the whole pipeline, then rank what it finds with a documented scheme such as DREAD or OWASP likelihood times impact. Be explicit that the scores are structured judgement, not measurement. DREAD’s own categories give assessor-dependent results.
An informal list of AI risks can’t tell you which items matter for your deployment. A structured method can, because it forces you to tie each threat to a component, a trust boundary and a scoring rule someone else can check.
Applying threat modeling with STRIDE across the whole gateway pipeline
STRIDE sorts threats into six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege. Applying it means drawing a data flow diagram of the architecture, breaking it into components, identifying the threats against each component, then documenting and ranking them, often with DREAD alongside to rate severity. STRIDE has no prioritisation step of its own, so the ranking has to come from somewhere else.
For a gateway, we would draw the data flow diagram to include at least these components and boundaries:
- the client-facing gateway layer (authentication, per-tenant keys, rate limits, routing);
- the inference server’s HTTP and gRPC surfaces;
- the engine and scheduler, including the KV cache that requests share;
- the worker channels between nodes, which in vLLM run over PyTorch Distributed, KV cache transfer and parallelism traffic that is insecure by default and has to sit on an isolated network;
- model, adapter and cache storage, where vLLM loads cache contents without cryptographic integrity checks;
- any code interpreter, plugin or tool path, since vLLM’s endpoint plugins can register arbitrary routes that reach the engine and must be treated as trusted code.
The weakness of per-component STRIDE is that it looks at components one at a time. Research on threat modelling practice points out that STRIDE doesn’t account for interactions between components, so it misses threats that only appear once components are connected. The prefix cache on its own is a performance feature, and so is the scheduler. The two together give a cross-tenant side channel. A second pass over every edge of the diagram (“what can a tenant learn or change through this interaction?”) catches what the per-element pass misses. The OWASP Threat Modeling Cheat Sheet also says traditional STRIDE and data-flow techniques need adapting for multi-tenant, identity-federated and dynamic cloud infrastructure.
Credential flow deserves its own edge on the diagram. vLLM treats a whole Ray cluster as one trust domain, and by default it copies credentials scoped to the API server into worker environments, where a process under the same OS user may be able to read them.
Should we use STRIDE or PASTA for an LLM inference gateway?
Use STRIDE when engineers who know the architecture need a threat inventory of the system as built. Consider PASTA when the analysis has to be framed around assets and risk. STRIDE is the most mature threat-modelling method, and it models the system as built through data flow diagrams of entities, events and boundaries, which suits a gateway whose architecture already exists.
PASTA brings risk-based notions of assets and threats, but it doesn’t explicitly define how a threat should be prioritised. So choosing PASTA doesn’t remove the need for a scoring scheme. For a time-boxed review with a small security-literate team, STRIDE per element, then per interaction, plus a documented scoring rubric is the leaner route. What makes a ranking defensible is the scoring and its documentation, and both methods leave that to you.
Which AI attack vectors are actually plausible for a multi-tenant gateway?
The plausible attack vectors for a multi-tenant gateway are the ones a realistic threat source can reach with the access it already has, and the ones with evidence of real exploitation. Everything else in a generic list of AI attacks is possible but lower priority. Generic taxonomies are long: one 2025 study catalogues fifty attacks on LLMs, split between attacks on models and attacks on their infrastructure.
Two filters cut that list down. The first is threat-source filtering. The MATRA method selects only threat sources whose capability and access realistically intersect the deployment’s attack surface, and in its case study it named a malicious customer using a legitimate channel as the most realistic source. On a gateway, the equivalent is an ordinary paying tenant. The NDSS 2025 KV-cache attack assumed exactly that: an adversary with the same capabilities as any user and no control over the server.
The second filter is observed exploitation. CVSS v4.0’s Exploit Maturity metric rates likelihood from the availability of exploit code and reported in-the-wild attacks. Oligo reported that the ShadowRay campaign exploited a disputed, unpatched Ray vulnerability for seven months. The cause was a Jobs API with no authorisation, which let anyone with network access to the dashboard run arbitrary jobs.
The four paths we would expect at the top
Shared prefix cache timing (Information Disclosure). vLLM doesn’t isolate tenants that share a server process: their requests are scheduled together and share caches. In multi-tenant deployments, prefix caching is a timing side channel (CVE-2025-46570). An attacker on the same backend can compare Time to First Token to infer whether a guessed prefix matches another user’s cached prompt, and the vLLM documentation cites research showing a ROC AUC of 0.99 at prefix lengths of eight tokens. The mitigation is vLLM’s cache_salt parameter, which mixes a salt into the hash of the first KV cache block so that only requests with the same salt share prefix blocks. The salt must be a secret random value (the documentation suggests 256 bits), not a predictable identifier such as an account ID. Even then, vLLM says cache_salt reduces specific risks but is not an isolation boundary. The NDSS 2025 PROMPT PEEK paper corroborates the threat, reporting 95% to 99% success in reconstructing other users’ prompts through KV cache sharing on SGLang with a Llama2-13B model on an A100.
Endpoints outside authentication (Spoofing, Elevation of Privilege, Denial of Service). vLLM’s --api-key protects only endpoints under the /v1, /v2, /inference and /cohere prefixes. An attacker who can reach the server can run inference without credentials through paths such as /invocations or /score, cause denial of service through /pause or /abort_requests, and manipulate server state through /update_weights. The gRPC interface has no authentication, authorisation or encryption by default.
Tenant escape through untrusted models (Elevation of Privilege). Wiz Research compromised Hugging Face’s custom-model service by uploading a malicious model and using container escape to gain cross-tenant access to other customers’ models. The route was a pickle-serialised model carrying a remote code execution payload. vLLM states that dynamic LoRA loading isn’t safe for deployments exposed to untrusted clients, and that its code interpreter container has no network isolation by default, which can expose the host network and cloud metadata services.
Resource exhaustion and blast radius (Denial of Service). A very large n parameter makes vLLM allocate resources in proportion to it, which can exhaust memory and block other requests. vLLM caps it through VLLM_MAX_N_SEQUENCES, with a default of 16384. At the gateway layer, one misconfigured service calling an expensive model can exhaust a shared budget for everyone. Hierarchical virtual keys, each with its own spending cap, rate limit and model-access policy, contain that blast radius.
Prompt injection and jailbreaks are recognised attack types on LLMs. On a pure inference gateway without tools, though, we would expect their impact to stay inside the attacker’s own tenant and rank them below cross-tenant paths. That changes once tools, retrieval or a code interpreter are wired in. Where injection matters, MATRA’s conclusion is that prompt injection can’t be eliminated, so risk reduction comes from architectural controls that limit what injected instructions can achieve.
| Attack path | STRIDE category | Why it is plausible | First mitigation | Relative effort (judgement) |
|---|---|---|---|---|
| Prefix/KV cache timing channel | Information Disclosure | Any ordinary tenant can mount it; CVE-2025-46570 | Per-tenant random cache_salt |
Low: a gateway-side parameter |
| Unauthenticated endpoints | Spoofing, Elevation of Privilege, Denial of Service | --api-key covers only some path prefixes |
Path allow-list at a reverse proxy; keep gRPC private | Low to moderate |
| Untrusted model or adapter loading | Elevation of Privilege | Demonstrated cross-tenant escape | Disable dynamic LoRA for untrusted clients; sandbox untrusted models | Moderate to high |
| Resource exhaustion | Denial of Service | n and shared budgets let one tenant starve others |
Parameter caps and hierarchical per-tenant keys | Moderate |
How to score threats so the ranking holds up in a customer security review
A ranking holds up in review when the method is named, the scales are written down, the evidence behind each likelihood rating is attached, and the subjectivity is stated rather than hidden.
DREAD rates five criteria, Damage, Reproducibility, Exploitability, Affected Users and Discoverability, each from 0 to 10. One course text sums the five ranks, while other studies average them. Pick one rule and record it, because a reviewer comparing an averaged score out of 10 with a summed score out of 50 will otherwise find a contradiction that isn’t there. The same course text describes STRIDE as anticipating threat categories at design time and DREAD as scoring known threats, so the two complement each other.
The OWASP Risk Rating Methodology defines risk as likelihood times impact. It scores likelihood and impact on a 0 to 9 scale, with bands for low (0 to under 3), medium (3 to under 6) and high (6 to 9). It recommends tuning the model against ratings the business agrees are accurate, because a tailored model saves time otherwise lost arguing over ratings. The NIST AI RMF uses the same composite definition, the probability of an event combined with the magnitude of its consequences.
The main caveat is subjectivity. A 2024 study of four scoring systems on 56 adversarial LLM attacks describes DREAD’s categories as highly subjective, leading to inconsistent scoring across assessors. In that study, three LLM scorers gave the same attack Damage ratings of 6, 5 and 8 out of 10 and diverged on OWASP’s Opportunity factor as well. The OWASP method shares the problem, because factors such as threat-agent skill are subjective. The authors of a DREAD study of educational LLMs note that other experts would likely score differently. The same 2024 study also found that existing scoring systems produce minimal variation across the adversarial LLM attacks it scored, especially rigid, context-specific ones such as CVSS.
Two anchors make the scores more defensible. For infrastructure flaws such as the unauthenticated endpoints and the timing CVE, CVSS v4.0 lets the consumer adjust the vendor’s Base score with Threat metrics, such as active exploitation, and Environmental metrics, such as mitigations already in place and the criticality of the system. Its Value Density metric distinguishes diffuse targets from concentrated, resource-rich systems such as a central server. We would rate a shared gateway as concentrated. For triage decisions, CISA’s SSVC uses a decision tree instead of a numeric score, ending in Track, Track*, Attend or Act, with decision points such as whether exploitation is automatable. We would use CVSS v4.0 for the infrastructure findings and a documented DREAD or OWASP rubric for model-behaviour threats, since CVSS’s technical-impact factors fit attacks on model behaviour poorly.
Which threats do we fix before the security review, and which can wait?
Fix the highest-severity band first, and order the work within that band by risk reduction per unit of effort. Severity alone leaves fix cost out, and cost alone lets cheap fixes for trivial risks jump the queue. The sources pull in two directions here. OWASP’s guidance is that the most severe risks come first, and that fixing less important risks does not help the overall risk profile even when they are cheap. The OWASP Threat Modeling Cheat Sheet notes that likelihood times impact ignores the work needed to fix a problem, and that some practitioners fold effort into the priority. QuantTM notes that threats can also be ranked by return on security investment, the cost of the mitigated impact minus the cost of the control. Taken together, OWASP’s severity-first rule governs the top of the list, and the effort ratio is useful inside a severity band.
Applied to the table above, cache_salt and a path allow-list in front of the inference server are cheap, close cross-tenant paths, and would land first. Sandboxing untrusted models takes longer, but its severity keeps it in the pre-review set as a committed plan if not a finished fix. SSVC’s mitigation-status criteria help here. They weigh whether a mitigation is available, how hard the system change is, and whether it is an official fix or a workaround, which SSVC rates as worse. MATRA shows the payoff of architectural controls: a read-only database role cut one rated risk from High to Moderate. It also shows that one control can leave other vectors open, so layered controls are needed.
Whatever waits needs a recorded response. The OWASP cheat sheet lists mitigate, eliminate, transfer and accept, and asks teams to record why any remaining risk is accepted. NIST’s AI RMF prioritises treatment by impact, likelihood and available resources, and documents the risks that will not or cannot be measured. Auditable adversarial-testing evidence mapped to red-team attack scenarios is a separate need, answered on its own page.
Where the ranked list stops being trustworthy
A ranked list is only as good as the threat model’s coverage of the real architecture. A component left off the diagram gives false confidence rather than a low score. Effort estimates and likelihoods go stale as the gateway changes. NIST notes that measuring risk at different lifecycle stages can give different results. Penetration testing finds what it targets, so a clean result isn’t proof that no vulnerability exists. We treat the ranked list as an input to a release-readiness review: one of the artefacts that catches failures before customers do, not a substitute for the regression and isolation checks that follow.
The gateway is also only the front of the AI infrastructure and production SaaS stack. Threat modelling the inference pipeline, from GPU isolation to sensor spoofing covers tenant isolation, plugin sandboxing and shared-GPU side channels in the vLLM pipeline.
FAQ
What is repudiation in STRIDE?
Repudiation covers threats where someone denies having taken an action, which undermines accountability.
What are the four types of risk mitigation?
The NIST AI RMF lists four risk responses: mitigating, transferring, avoiding and accepting. The OWASP cheat sheet’s threat responses are similar: mitigate, eliminate, transfer and accept.
