Securing LLM Applications: Prompt Injection, the OWASP Top 10, Red Teaming, and API Gateways

Application-layer AI security starts from an uncomfortable premise, and OWASP states it plainly: "it is unclear if there are fool-proof methods of prevention for prompt injection."^[1] Every control below is therefore impact-limiting, not preventive. Architect on the assumption that an injection eventually lands, and spend your budget on what the model is allowed to *do* once it does.

This guide covers attacks on what the model does inside your application: injected instructions, unsafe handling of model output, over-broad tool permissions, leaked system prompts, and abuse at the API edge. It deliberately excludes attacks on the model as an artifact — malicious checkpoint files, dependency compromise, weight theft, training-data extraction — which are a different surface with different owners and different tooling, covered separately in the model-security guide linked at the foot of this page.

1. Build against the list that exists

The OWASP Gen AI Security Project publishes the Top 10 for LLM and generative-AI applications. As of August 2026 the current edition is the 2025 list, and the previous edition is the 2023/24 list; both are published side by side on the project's own site.^[2][3] If a vendor deck, a training module, or an AI-written explainer cites a different year, ask which page it came from — the project publishes each edition, its translations, and its version history openly, so the claim is checkable in about a minute.

Two 2025 entries have no counterpart by title in the previous edition: System Prompt Leakage (LLM07:2025) and Vector and Embedding Weaknesses (LLM08:2025) — the second of which is why RAG retrieval security now sits inside the Top 10 rather than beside it. Two 2023/24 titles no longer appear as standalone entries: *Insecure Plugin Design* and *Model Theft*. Model theft has not been dropped as a concern, though: the 2025 Unbounded Consumption entry lists "Model Extraction via API" and "Functional Model Replication" among its own vulnerability examples, so extraction is now framed as a consumption problem rather than a separate risk.^[5] Retitle your control mappings accordingly; do not assume old and new numbers line up.

2. Prompt injection: two threat models, one root cause

OWASP splits the class in two. Direct prompt injections "occur when a user's prompt input directly alters the behavior of the model in unintended or unexpected ways," while indirect prompt injections "occur when an LLM accepts input from external sources, such as websites or files" whose content, once interpreted, alters model behavior.^[1] The distinction is not academic — it decides who your adversary is. In the direct case the user of your application is the attacker. In the indirect case the user is a victim, and the attacker is whoever can influence a web page, an inbound email, a shared document, or a tool response your agent reads on that user's behalf.

The indirect case is the one that surprises architecture reviews, because it turns ordinary product features into attack surface. The 2023 paper that named the technique, Greshake et al.'s "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection," describes adversaries who "remotely exploit LLM-integrated applications by strategically injecting prompts into data likely to be retrieved," with impacts the authors characterize as acting "as arbitrary code execution, manipulate the application's functionality, and control how and if other APIs are called."^[6] Anything your system retrieves — a crawled page, an OCR'd upload, a wiki space, a tool result — is a delivery channel.

OWASP also notes that the input need not be legible to a person: "These inputs can affect the model even if they are imperceptible to humans, therefore prompt injections do not need to be human-visible/readable, as long as the content is parsed by the model."^[1] That single sentence rules out human review as a control for high-volume ingestion, and it is why multimodal pipelines widen the problem rather than narrow it — OWASP's own scenario list includes a malicious prompt embedded in an image that accompanies benign text.

Read that as a design constraint, not a counsel of despair. It says: do not buy a control whose value proposition is that injection stops. Buy controls that cap the blast radius — and note that OWASP's own mitigation list is dominated by architecture, not filtering. Of its seven prevention measures, only one is input and output filtering; the rest are constraining model behavior in the system prompt, validating output formats with deterministic code, enforcing least privilege by giving the application its own API tokens instead of exposing them to the model, requiring human approval for high-risk actions, segregating and clearly labeling external content, and adversarial testing that treats the model as an untrusted user.^[1]

3. What the platform guardrails do — and what their own docs say they miss

All three major platforms ship a screening product or a documented pattern. Their value is real and their limits are documented — in each case by the vendor, on the same page that describes the feature. Read the limitations section before you budget for the feature, because that is where the residual risk you are still carrying is written down — Azure's Prompt Shields page, for instance, closes with "Prompt Shields may not catch all attack vectors or may flag legitimate prompts. Always implement additional validation layers," and notes that its models are trained and tested on eight languages, so a multilingual product inherits uneven coverage.^[7]

Notice what the three approaches agree on, since agreement across competitors is the closest thing to consensus this field has: untrusted content must be structurally distinguishable from your instructions — Bedrock does it with input tags, Azure with a separate document-screening path, Anthropic with tool-result placement and JSON encoding. If your prompt assembly concatenates retrieved text into one undifferentiated string, no screening product can fully compensate, because you have destroyed the boundary each of them depends on.

4. The controls that hold when the filter is bypassed

Excessive Agency (LLM06:2025) is where an injection becomes an incident. OWASP defines it as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction," and roots it in three failures: "excessive functionality; excessive permissions; excessive autonomy."^[10] Its worked example of excessive functionality is the one to take to your next design review: a team needs an agent that can read documents from a repository, and adopts a third-party extension that also happens to expose modify and delete. The agent never needed write access; the integration handed it over anyway.

Improper Output Handling (LLM05:2025) is a familiar web vulnerability class wearing new clothes. OWASP defines it as "insufficient validation, sanitization, and handling of the outputs generated by large language models before they are passed downstream to other components and systems," and warns that because "LLM-generated content can be controlled by prompt input, this behavior is similar to providing users indirect access to additional functionality." The listed consequences are entirely conventional — "XSS and CSRF in web browsers as well as SSRF, privilege escalation, or remote code execution on backend systems" — as are the examples: model output piped into exec or eval, generated SQL executed without parameterization, generated paths used without sanitization.^[11] Your existing appsec controls apply directly. Treat the model as an untrusted client that happens to sit inside your perimeter, and the encoding, parameterization, and allowlisting rules you already enforce cover most of this entry.

System Prompt Leakage (LLM07:2025) is the entry most likely to be mis-prioritized, and OWASP is blunt about why: "the system prompt should not be considered a secret, nor should it be used as a security control," and "disclosure of the system prompt itself does not present the real risk — the security risk lies with the underlying elements."^[12] The failure it points at is architectural. If leaking your prompt is damaging, it is because the prompt contained credentials or connection strings, or because the application delegated authorization to the model instead of enforcing it in code. Fix that, and the leak becomes an embarrassment rather than a breach. OWASP also notes the practical ceiling on secrecy here: even without the exact wording, "attackers interacting with the system will almost certainly be able to determine many of the guardrails and formatting restrictions."^[12]

For threat modeling that goes beyond the Top 10's ten headings, NIST's adversarial machine-learning taxonomy gives a common vocabulary for attack types and mitigations spanning both the application and model layers, and it is the reference most enterprise AI risk programs can already anchor inside their existing NIST framing.^[13]

5. Red teaming: making the failure reproducible

OWASP's seventh mitigation is to "perform regular penetration testing and breach simulations, treating the model as an untrusted user to test the effectiveness of trust boundaries and access controls."^[1] Two open-source tools make that repeatable rather than artisanal. NVIDIA's garak describes itself as an LLM vulnerability scanner that "checks if an LLM can be made to fail in a way we don't want" and "probes for hallucination, data leakage, prompt injection, misinformation, toxicity generation, jailbreaks, and many other weaknesses," combining "static, dynamic, and adaptive probes"; it is Apache-2.0 licensed.^[14] Microsoft's PyRIT — the Python Risk Identification Tool for generative AI — is "an open source framework built to empower security professionals and engineers to proactively identify risks in generative AI systems," MIT-licensed.^[15] PyRIT is published under the microsoft GitHub organization; if a runbook or CI job in your estate still points at an older location, repoint it at the repository cited here before you rely on its output.^[15]

Scanners test the model. They do not test your application, and that gap is where most enterprise red-team value sits. Anthropic's guidance is explicit that the exercise must run end to end: "before deploying, test your workflow with documents, emails, and tool outputs that deliberately contain injection attempts, and confirm that Claude ignores them and that your screening and confirmation steps catch the rest."^[9] The deliverable is not a pass rate. It is a set of reproducible cases — payload, entry point, observed downstream effect — that become regression tests in CI, so that a prompt-template edit or a model upgrade cannot silently reopen a finding you already closed.

6. The API edge: rate limits, Denial of Wallet, and the gateway

Unbounded Consumption (LLM10:2025) is the entry that turns an availability problem into a finance problem. OWASP names the pattern Denial of Wallet (DoW): "by initiating a high volume of operations, attackers exploit the cost-per-use model of cloud-based AI services, leading to unsustainable financial burdens on the provider and risking financial ruin."^[5] Its other listed vectors are just as practical — variable-length input floods, continuous input overflow past the context window, and deliberately resource-intensive queries. Its mitigations start where you would expect: strict input size validation, rate limiting and user quotas, timeouts and throttling, dynamic resource-allocation management, and limits on queued actions.^[5]

One mitigation is easy to overlook and cheap to apply: "restrict or obfuscate the exposure of logit_bias and logprobs in API responses. Provide only the necessary information without revealing detailed probabilities."^[5] Token-level probabilities are useful to your evaluation harness and useful to an attacker building a shadow model. Return them to internal callers if you need them; do not pass them through to a public surface by default.

Upstream limits are not your quota system. OpenAI documents rate limits measured in RPM (requests per minute) and TPM (tokens per minute) alongside images-per-minute and audio-minutes-per-minute for some models, notes that "rate limits can be hit across any of the options depending on what occurs first," defines them at the organization and project level, graduates accounts through usage tiers as API spend rises, and returns remaining requests and tokens in the response headers.^[16] All of that protects the provider's infrastructure and puts a ceiling on your bill — none of it stops one tenant of your application from consuming the whole organization-level quota. Per-tenant limits are yours to build.

7. How to apply this