Abstract

As large language model integrations move from prototype to production through 2025 and into 2026, security teams are discovering that prompt injection - while real - is only one entry in a broader threat taxonomy specific to LLM-integrated systems. This article applies a STRIDE-adjacent threat modeling lens to the architecture of a typical LLM application, surfacing threats in training data integrity, retrieval pipeline poisoning, model output trust boundaries, and the tool/function call surface, with concrete mitigations for each.

Threat Surfaces Beyond the Prompt

The architecture of a production LLM application typically includes several components beyond the model itself: a vector database for retrieval-augmented generation (RAG), a tool dispatch layer that calls external APIs or executes code, a conversation memory store, and an orchestration layer connecting them. Each is a distinct attack surface. RAG pipeline poisoning - inserting adversarial documents into the vector store that redirect model behavior when retrieved - is structurally similar to prompt injection but requires write access to the knowledge base rather than to the user prompt. This threat is particularly relevant where the vector store is populated from external sources (web crawls, third-party document feeds) without integrity verification. The mitigation is a document provenance policy: treat documents entering the retrieval index as untrusted input, apply the same sanitization and allowlist logic that would apply to any external data, and consider signing document embeddings to their source so poisoned retrievals can be traced.

The Tool Call Surface and Confused Deputy Risks

When an LLM is granted tools - web search, code execution, database reads, API calls - the model’s output becomes code in the sense that it is executed on behalf of the user. The “confused deputy” class of problem applies directly: a user with low-privilege access to the LLM can craft inputs that cause the model to invoke tools with higher privileges than the user themselves possesses. The mitigation is to enforce the principle of least privilege at the tool dispatch layer independently of the model - every tool call should be re-authorized against the requesting user’s actual permissions before execution, not delegated to the model’s judgment. Microsoft’s Semantic Kernel and LangChain both have extension points for this; neither enforces it by default.

Model Output Trust and Downstream Injection

LLM output that flows into downstream systems - SQL queries assembled from model output, shell commands, API request bodies - represents a code-injection risk that does not require adversarial user input. A model hallucinating a plausible-but-malicious SQL fragment or a shell metacharacter in a file path is sufficient to create a vulnerability if the output is not properly escaped and parameterized before use. The standard advice applies: never interpolate model output directly into queries or commands. Use parameterized queries, argument arrays instead of shell strings, and structured output parsing (JSON schema validation against expected shapes) rather than free-text parsing. Logging all model inputs and outputs at the application boundary, with retention sufficient for forensic investigation, closes the observability gap - without logs, post-incident analysis of what the model was asked and what it produced is effectively impossible.