# A threat model for an LLM gateway, mapped to OWASP

URL: https://infro.io/blog/llm-gateway-threat-model
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-09-29
Last modified: 2026-09-29
Last reviewed: 2026-09-29 (next review due 2026-10-29)
Topic: Security and governance
Format: Analysis

> Threat-model an LLM gateway as an asset in its own right: it holds provider credentials, policy, spend authority and possibly captured content, across four trust boundaries. Against the OWASP Top 10 for LLM Applications 2025 it materially reduces sensitive information disclosure and unbounded consumption, limits the blast radius of prompt injection and excessive agency, and does nothing for poisoning, vector-store weaknesses or misinformation.

Most architecture diagrams draw an LLM gateway as a thin box between the application and the model provider. Security reviews that accept that drawing miss the point: the box holds every provider credential the organization uses, decides which models may be called and how much may be spent, and — if content capture is on — keeps copies of prompts and completions. It is an asset worth attacking in its own right.

This analysis threat-models the gateway itself, then maps the OWASP Top 10 for LLM Applications 2025 onto it, to separate the risks a gateway reduces from the ones it cannot touch. The distinction matters for procurement as much as for design: a vendor who claims its gateway "addresses the OWASP Top 10" is claiming something no gateway can do.

## What the gateway holds

Start with assets, because threats only make sense against something of value:

- **Provider credentials.** Keys and tokens that spend money on the organization's own provider accounts. In a bring-your-own-key design they belong to the customer, not the gateway operator.
- **Gateway keys and configuration tokens.** Inbound credentials that decide who can send traffic and who can change policy.
- **Policy.** Model allowlists, routes, budgets, guardrail rules, environment scopes. Weakening policy quietly is a more patient attack than stealing a key.
- **Request records.** Metadata about every call — model, provider, tokens, latency, estimated cost, the caller's own tags — which is operational evidence and can contain personal data in metadata fields.
- **Captured content.** Prompts and completions, if capture is enabled. The most sensitive asset, and the one a good default does not create at all.
- **Spend authority.** The ability to cause provider charges. OWASP lists unbounded consumption as its own risk, including attacks that exploit pay-per-use pricing to create unsustainable cost[1].

## Four trust boundaries

Each asset is exposed across one or more boundaries. Drawing them explicitly is what turns a list of worries into a set of controls with owners.

[Diagram: Four trust boundaries around an LLM gateway. Each has its own credential type, its own threats and its own evidence.]

**Applications to gateway.** The inbound boundary is authenticated by gateway keys. Threats are the familiar ones: a key committed to a repository, shipped in a mobile app, or used by a service that should not have it. Controls are scoping (project, environment, model, network), spend limits per key, and fast revocation.

**Gateway to providers.** The outbound boundary carries the customer's credentials and the full request content. Threats are disclosure of a credential from storage, a request sent to a provider or deployment the data should not reach, and silent fallback to a target nobody approved. Controls are authenticated encryption bound to the owning row, no read path for secrets, and model and route policy that applies to fallbacks as well as primaries. Provider-side retention sits on the far side of this boundary and outside the gateway's control; OpenAI, for example, documents that abuse-monitoring logs may be retained for up to 30 days unless an organization has approved data controls[2].

**People to consoles and configuration APIs.** Threats are account takeover, a departing employee who keeps access, and a policy change nobody reviews. Controls are phishing-resistant second factors, single sign-on with directory deprovisioning, configuration tokens that expire and follow their creator's role, and an audit log the application itself cannot rewrite.

**Gateway to telemetry and exports.** The least-watched boundary. Spans sent to an observability backend and CSV exports sent to a finance team both leave the gateway's access model. Threats are content or identifiers leaking into a system with far wider read access. Controls are field-by-field allowlists for telemetry and exports that exclude content by construction.

## Threats that follow from the gateway's position

A few threats are specific to sitting in the middle, and deserve their own line in the model:

- **Cross-tenant credential confusion.** In a multi-tenant gateway, a bug or a write to the credentials table that places one tenant's sealed credential in another's row. Binding each ciphertext to its row makes this fail closed instead of authenticating as the wrong account.
- **Policy bypass through indirection.** A route or fallback list that reaches a model the allowlist forbids. Policy must apply to what is actually called, not to the name the client sent.
- **Header trust.** Network allowlists evaluated against `X-Forwarded-For` or another client-controlled header can be spoofed; they must use the address the edge observed.
- **Retry amplification of cost.** Automatic retries and fallbacks multiply the requests a single abusive call produces. Spend controls have to count every attempt, not only the one that succeeded.
- **Error-message disclosure.** Upstream provider errors and internal identifiers passed through verbatim can reveal account structure. The gateway should translate them into its own documented error surface.

[Diagram: A leaked gateway key meeting three independent controls in turn. Each refusal happens before the provider is called, so each is also free of provider cost.]

## Mapping the OWASP Top 10 for LLM Applications

OWASP's 2025 list names ten risks, from prompt injection (LLM01) to unbounded consumption (LLM10)[3]. They are written for LLM applications as a whole, so the honest question for a gateway is which of them it can reduce at its boundary.

[Diagram: The OWASP 2025 list seen from the gateway. The mapping is this article's analysis; OWASP does not classify risks by component.]

Two risks are squarely in the gateway's reach. **Sensitive information disclosure (LLM02)** is reduced by never capturing content by default, restricting who can read it when captured, and redacting known formats before a request leaves. **Unbounded consumption (LLM10)** is reduced by rate limits, budgets per key and project, and caps per end customer — the operational controls OWASP itself lists, such as rate limiting, user quotas and resource allocation limits[1].

Four are partial. For **prompt injection (LLM01)**, OWASP states that it is unclear whether fool-proof prevention methods exist[4]; a gateway cannot distinguish an injected instruction from a genuine one, but it can bound what a manipulated call reaches — which models, what spend, whether a credential-shaped string leaves. **Excessive agency (LLM06)** is mostly an application concern, because tool permissions live where tools execute. **System prompt leakage (LLM07)** is best addressed, per OWASP, by not treating the system prompt as a secret or as a security control at all[5]; output checks for credential formats help only with the formats they know. **Supply chain (LLM03)** benefits from an approved-model list and a record of which provider served each call.

Four are out of reach. Poisoning (LLM04) happens in training data. Vector and embedding weaknesses (LLM08) live in the retrieval store. Improper output handling (LLM05) must be solved by the application that renders or executes output. Misinformation (LLM09) is an evaluation problem.

## Organizing the model with NIST AI RMF

The NIST AI Risk Management Framework, released in January 2023 for voluntary use, organizes AI risk work into four functions: Govern, Map, Measure and Manage[6]. A gateway threat model fits into it cleanly. The asset and boundary inventory above is Map work. Request records, refusal counts and audit events are Measure inputs. Budgets, allowlists and revocation are Manage controls. And who may change policy, and how that is reviewed, is Govern. Using the framework's vocabulary makes the gateway's controls legible to a risk team that already uses it for the rest of the AI program.

## INFRO against this threat model

INFRO is a gateway, so it is subject to this model like any other. The controls it has today, from its documentation and [Trust Center](https://infro.io/trust):

| Boundary | Control in INFRO | Where documented |
| --- | --- | --- |
| Applications → gateway | Keys scoped by project, environment, model allowlist and up to 32 allowed networks; per-key spend limits; rotation with overlap | [Authentication](https://infro.io/docs/authentication) |
| Gateway → providers | AES-256-GCM sealing bound to organization and connection; no reveal; model policy applied to route targets and fallbacks | [Connect a provider](https://infro.io/docs/providers), [Model allowlists](https://infro.io/docs/org/model-allowlists) |
| People → consoles | Two-factor and passkeys on every plan; SAML/OIDC SSO and SCIM from the Business plan; expiring, role-bound management tokens; append-only audit log | [SSO & SCIM](https://infro.io/docs/org/sso), [Management tokens](https://infro.io/docs/manage/tokens), [Audit log](https://infro.io/docs/org/audit-log) |
| Gateway → exports | Content capture off by default; CSV export never includes content; OpenTelemetry attributes built from an allowlist | [Privacy & data](https://infro.io/docs/privacy), [Request traces](https://infro.io/docs/observability/traces) |

Table: INFRO controls by trust boundary, as documented on 2026-09-29.

The gaps belong in the model too, and INFRO publishes them. Guardrails are pattern-based and do not detect prompt injection, jailbreaks or toxicity. There is no control that refuses a single unusually expensive request; budgets cap totals. Rate limits are counted per location rather than by one global counter, so a key can briefly exceed its nominal limit. There is no independent penetration test, and no SOC 2 or ISO 27001 certification is held. A reviewer should weigh those as stated rather than infer their absence from silence.

## Using the model

A threat model is useful when it produces decisions. For each boundary, write down the credential that crosses it, the control that limits it, the evidence that the control works, and the person who owns it. For each OWASP risk the gateway cannot reach, name the component that must carry it instead — the retrieval store, the output renderer, the evaluation suite — so that buying a gateway does not quietly leave those risks unowned.

## Sources

1. LLM10:2025 Unbounded Consumption — OWASP GenAI Security Project. https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/ (accessed 2026-09-29)
2. Data controls in the OpenAI platform — OpenAI. https://developers.openai.com/api/docs/guides/your-data (accessed 2026-09-29)
3. OWASP Top 10 for LLM Applications 2025 — OWASP GenAI Security Project. https://genai.owasp.org/llm-top-10/ (accessed 2026-09-29)
4. LLM01:2025 Prompt Injection — OWASP GenAI Security Project. https://genai.owasp.org/llmrisk/llm01-prompt-injection/ (accessed 2026-09-29)
5. LLM07:2025 System Prompt Leakage — OWASP GenAI Security Project. https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/ (accessed 2026-09-29)
6. AI Risk Management Framework — NIST. https://www.nist.gov/itl/ai-risk-management-framework (accessed 2026-09-29)