Map the AI security threat landscape from prompt injection to data exfiltration. Learn which controls work at the gateway, model, and application layer.
The AI security landscape has a framework problem. Not a shortage of frameworks, but a surplus. OWASP publishes a Top 10 for LLM applications. MITRE maintains ATLAS with 16 tactics and 170 techniques cataloging adversarial threats against AI systems. Every cloud provider ships a "shared responsibility model" for AI. And engineering teams are left wondering which threats actually apply to them and where to put the controls.
This is a practical map. We will walk through the threat categories that matter for teams deploying LLM-based applications, then break down which controls belong at which layer: gateway/middleware, model, or application.
The OWASP Top 10 for Large Language Model Applications (2025 edition) identifies ten risk categories for LLM-based systems. Not all of them are created equal from an engineering perspective. Some you can mitigate with infrastructure. Others require changes to how you train, fine-tune, or deploy the model itself. A few demand application-level logic that no middleware can provide.
Here is how they break down.
Prompt injection remains the top risk on the OWASP LLM Top 10. A prompt injection vulnerability occurs when user prompts alter the LLM's intended behavior, leading to unauthorized access, data breaches, or compromised decision-making. It comes in two forms: direct (the user crafts a malicious prompt) and indirect (the malicious content is embedded in external data the model retrieves).
Direct prompt injection is partially addressable at the gateway layer through input scanning and pattern matching. Indirect prompt injection is harder because the payload arrives via RAG sources, tool outputs, or other data the model consumes during inference. That requires application-level controls: sanitizing retrieved content, restricting what the model can act on, and validating outputs before they reach downstream systems.
Sensitive information can affect both the LLM and its application context. This covers two scenarios: the model leaking training data (memorization attacks) and users inadvertently sending sensitive data to the model: the shadow AI problem most organizations already face.
The second scenario is where a gateway layer earns its keep. PII redaction, data masking, and content filtering applied before the request reaches the provider prevent sensitive data from ever leaving your perimeter. The first scenario, training data memorization, requires model-level controls: differential privacy during training, output filtering, and restricting the model's ability to reproduce verbatim training content.
LLM supply chains are susceptible to various vulnerabilities, which can affect the integrity of training data, models, and deployment platforms. This includes compromised model weights, poisoned fine-tuning datasets, and malicious packages in your inference pipeline.
Supply chain risk is almost entirely outside the gateway's scope. It lives at the model layer (verifying model provenance, auditing training data) and the application layer (dependency scanning, artifact signing, secure deployment pipelines).
Data poisoning occurs when pre-training, fine-tuning, or embedding data is tampered with to introduce vulnerabilities, backdoors, or biases. If your RAG pipeline ingests documents from sources you do not fully control, you have a data poisoning surface.
Model-level control. Validate your training and fine-tuning datasets. Audit your embedding sources. Monitor for distribution shifts in your vector stores. A gateway cannot inspect the semantics of training data.
Improper output handling refers to insufficient validation, sanitization, and handling of LLM-generated outputs before they are passed to downstream components. Think SQL injection via LLM output, or an LLM generating HTML that gets rendered unsanitized in a browser.
This is an application-layer problem. The fix is the same as it has always been for untrusted input: validate, sanitize, and apply least-privilege principles to every system the LLM output touches. A gateway can flag suspicious output patterns, but the enforcement point is your application code.
An LLM-based system is often granted a degree of agency by its developer, allowing it to call functions, execute code, or interact with external systems. Excessive agency is the risk that an LLM takes actions beyond its intended scope.
Application-layer control. Define strict tool schemas. Implement approval workflows for high-risk actions. Limit the model's available tools to the minimum required for each task. A gateway can enforce rate limits on tool calls, but the permission model lives in your application.
Every AI security control maps to one of three layers. Mixing them up is how teams end up with expensive middleware that does not actually address their risk, or application-level security theater that ignores the infrastructure gaps underneath.
The gateway sits between your application and the model provider. It sees every request and every response. That position makes it the natural enforcement point for:
Provider API keys should never be embedded in application code or passed through client-side requests. A gateway holds your keys, decrypts them on demand per request, and ensures they are never returned in plaintext to any client. Tenant-isolated key lookups prevent one customer's credentials from leaking to another.
Scan outbound prompts for personally identifiable information, replace sensitive values with tokens, and restore them in the response. This is the single most effective control against accidental data exposure to model providers.
Unbounded consumption (the tenth risk on the OWASP LLM Top 10) refers to LLMs consuming excessive resources through uncontrolled requests. Per-user and per-application rate limits, token budgets, and spend caps are gateway-native controls.
Every prompt and completion passes through the gateway. Log them. This gives you the audit trail that compliance teams need and the forensic data security teams need when something goes wrong.
Pattern-based detection for known prompt injection techniques, jailbreak attempts, and policy violations. Not bulletproof against novel attacks, but it raises the cost of exploitation and catches the low-hanging fruit.
Semantic caching at the gateway reduces the number of requests that reach the provider. Fewer requests means less exposure surface and lower cost.
Model-layer controls are about what happens inside the LLM itself, whether you are training, fine-tuning, or selecting a third-party model.
Validate and audit the data used for pre-training and fine-tuning. Data poisoning is a model-layer threat that no downstream control can fully remediate.
System prompts, guardrails, and structured output formats that limit what the model can generate. These reduce the surface area for improper output handling and sensitive information disclosure.
Know where your model comes from. Verify checksums. Track versions. The OWASP Top 10 for LLM Applications flags supply chain vulnerabilities as a distinct risk category because compromised models are compromised at the root.
Systematic adversarial testing to find vulnerabilities before attackers do. MITRE's ATLAS framework provides a structured approach, cataloging 57 real-world case studies of attacks against AI-enabled systems alongside 35 documented mitigations.
Application-layer controls govern how your software interacts with the LLM and what happens with its outputs.
Treat LLM output as untrusted input. Never pass it directly to a SQL query, a shell command, or an HTML renderer without sanitization.
Define exactly which tools the LLM can call, with what parameters, and under what conditions. Implement human-in-the-loop approval for destructive actions.
Control what information persists across conversations. System prompt leakage (identified as a distinct vulnerability in the OWASP LLM Top 10) occurs when the system prompt is exposed to users through crafted queries. Protect system prompts and limit context window manipulation.
Not every user should have the same model access, the same tool permissions, or the same data visibility. Role-based access control at the application layer is table stakes.
Each OWASP LLM Top 10 risk category, matched to the layer where effective controls exist.
| Threat | Gateway | Model | Application |
|---|---|---|---|
| Prompt Injection | Input scanning, pattern detection | System prompt hardening | Context isolation, output validation |
| Sensitive Info Disclosure | PII redaction, data masking | Differential privacy | Access control |
| Supply Chain | - | Provenance verification, artifact signing | Dependency scanning |
| Data Poisoning | - | Training data validation | Embedding source auditing |
| Improper Output Handling | Response scanning | Output constraints | Sanitization, parameterized queries |
| Excessive Agency | Rate limiting, tool call caps | - | Permission models, approval workflows |
| System Prompt Leakage | - | Prompt protection techniques | Context management |
| Vector/Embedding Vulnerabilities | - | Embedding validation | Access control on vector stores |
| Misinformation | - | Grounding, RAG | Fact-checking workflows, citations |
| Unbounded Consumption | Rate limits, token budgets, spend caps | - | Usage monitoring |
Three patterns emerge from this table.
The gateway handles the perimeter. Key management, PII, rate limiting, and logging. These are infrastructure concerns that do not require understanding the model's behavior. They work the same way regardless of which provider or model you use.
The model layer handles integrity. Training data, model provenance, and output constraints. If the model is compromised, no amount of gateway filtering fixes the root cause.
The application handles authorization and trust. Who can do what, what the model can act on, and how its outputs get used. This is where business logic meets AI security.
No single layer solves AI security. The teams that get this right build depth.
Start at the gateway. It is the fastest control to deploy and covers the widest surface. Key management, PII redaction, rate limiting, and logging are non-negotiable for any production AI deployment. If you are running LLM traffic without a gateway, your provider keys are likely in environment variables, your prompts are unlogged, and your spend has no ceiling.
Harden the model layer. Choose models with clear provenance. Red team your deployments. If you are fine-tuning, validate your training data with the same rigor you apply to your application code.
Enforce at the application. Treat LLM outputs as untrusted. Scope tool access tightly. Build audit trails. The OWASP LLM Applications Cybersecurity and Governance Checklist provides a structured starting point for teams that need to formalize these controls.
Agentic AI systems introduce a compounding risk. When an LLM can plan multi-step actions, call tools, browse the web, and execute code, every threat on the list above gets amplified. Excessive agency is no longer a single function call gone wrong. It is a chain of actions, each one expanding the blast radius of a successful attack.
MITRE ATLAS now covers Agentic AI as a distinct platform category alongside Predictive AI, Generative AI, and Enterprise systems. The OWASP GenAI Security Project has published specific crosswalks for agentic applications.
For agentic systems, the gateway becomes even more critical as a choke point. Every tool invocation, every external API call, every data retrieval should pass through a controlled layer that can enforce policy, log activity, and kill a runaway chain before it causes damage.
If you are shipping AI and have not mapped your threat surface yet, here is the sequence:
shim provides a tenant-isolated boundary for native OpenAI, Anthropic, and Google requests, with managed provider-key storage, PII placeholder processing, and request accounting. Integrate each provider through its documented native route with shim gateway authentication.
const openai = new OpenAI({
baseURL: "https://api.getshim.tech/v1",
apiKey: process.env.SHIM_API_KEY
})AI security is not a product you buy. It is a set of controls you deploy across three layers, each one covering threats the others cannot. The teams that treat it as a checkbox exercise will keep finding their data in places it was never supposed to be.