Generative AI Security Risks: Which Ones a Policy Gateway Governs, and Which It Cannot

The OWASP GenAI Security Project publishes an LLM Top 10, and its current revision ranks prompt injection (LLM01) as the leading risk, followed by sensitive information disclosure (LLM06), supply-chain vulnerabilities (LLM05), and excessive agency (LLM08). That list catalogs what goes wrong. For a security or platform owner planning the next quarter of work, the more useful cut is where each risk is governable, meaning which control sits on the path the risk actually travels.

I want to walk through the concrete security risks of running generative AI inside an enterprise, grouped by where you can put a control on them. For each one I will say plainly whether it sits inside the boundary a policy gateway enforces, the HTTP path between an authenticated user or agent and the model, or outside it, where a different control owns the problem. This piece is the map. Each risk links to the deeper analysis where I take it apart on its own.

Sensitive data leaving in prompts and uploads

The first risk is the one employees create every day. A financial analyst pastes a draft earnings table into a chat window. A support agent uploads a customer file to summarize it. Cloud Radix found that 77% of employees using unauthorized AI admit to pasting sensitive business data into unsanctioned models, and 78% use those tools at work at all. This maps to OWASP LLM06, sensitive information disclosure, on the inbound side.

This risk sits inside the boundary. The prompt and any attached file travel as an HTTP request body to the model endpoint, and a proxy on that path reads the decrypted payload, classifies it across PII, PHI, source code, and financial categories, and applies a block or redact decision before the request reaches the provider. I go through the mechanics of stopping data at the request layer in data exfiltration via LLM.

Prompt injection

Prompt injection is the instruction hidden in content the model reads, either typed directly by a user trying to break the system prompt or planted in a document, web page, or email the model later ingests. OWASP has ranked it the top LLM vulnerability across every edition of the list. The indirect form is the dangerous one for agents, because the malicious instruction rides in through data the agent was told to trust.

This risk sits partly inside the boundary, and honesty about the limit matters here. A gateway on the request path inspects the prompt content and applies pattern and classifier checks before forwarding, which raises the cost of an attack. Detection is probabilistic, so no request-path filter catches every crafted injection. The durable control is downstream: constrain what the model is allowed to do after it has been influenced, which is the agent-permission problem below. I cover the request-path detection tradeoffs in prompt injection protection.

Data exfiltration through model outputs

The response carries risk too. A model can return training-memorized secrets, another tenant's data surfaced through a shared vector store, or the contents of a system prompt an attacker coaxed out. This is OWASP LLM06 again, on the outbound side, together with LLM02 insecure output handling when the response feeds a downstream tool that executes it.

This risk sits inside the boundary. The model response returns through the same HTTP path as the request, so a proxy inspects and redacts the response body before it reaches the caller, and it validates tool-call outputs against a schema before any action runs. IBM's Cost of a Data Breach research put the detection time for shadow-AI-linked breaches at 247 days, which is the window an unread response channel stays open. Response-side handling gets its own treatment in LLM response redaction patterns.

Shadow AI: unsanctioned tools

Shadow AI is the set of models employees use without approval, and it is the risk with the worst visibility. IBM's research found that one in five breached organizations experienced a breach linked to shadow AI, and those breaches cost $670,000 more on average than standard ones. Cloud Radix put IT-leader blindness to these interactions at 86%. Netwrix reported that 97% of organizations with an AI-related breach lacked proper access controls for AI services.

This risk sits partly inside the boundary. Traffic that a workload routes through the gateway becomes identity-bound and logged, which converts unsanctioned model calls from invisible to attributable. A user hitting a consumer chat app from a personal laptop over the corporate network still needs a network-layer discovery control to be caught. The gateway governs the AI traffic it sees on the sanctioned path, and pairs with the discovery methods I lay out in shadow AI detection tools.

Over-broad agent permissions

An agent given a corporate API token, a database connection, and a filesystem tool will use every scope it holds, including under the influence of a successful prompt injection. OWASP calls this LLM08, excessive agency, and it is where an injected instruction turns from noise into damage. The blast radius equals the union of the agent's granted permissions.

This risk sits inside the boundary for the calls that flow over HTTP. Each tool invocation an agent makes is a request the gateway authorizes against the identity on whose behalf the agent acts, so a delete or a wire transfer gets checked against policy at the moment it is attempted rather than assumed safe because the agent already authenticated. Scoping the grant itself remains an application design decision. I break the enforcement pattern down in excessive agency and the grant design in AI agent tool permissions.

Unlogged model access

The quiet risk is the absence of a record. When an AI decision runs on a shared service credential and the application writes its own log, there is no independent, per-decision evidence of who asked what, what data was involved, and what policy governed the outcome. A regulator or an incident responder arrives to find a convenience artifact the application could have modified.

This risk sits inside the boundary, and it is the one a request-path control is built for. A proxy on the AI path writes a signed, per-decision audit record containing identity, role, data classification, policy version, and outcome, committed before the response returns to the application, so the system under audit cannot suppress its own evidence. I detail the record structure in LLM audit logging best practices.

The risks a policy gateway does not touch

Three real generative AI security risks sit outside the HTTP request path, and a policy gateway has nothing useful to say about them. Naming them honestly is part of scoping the rest.

Training-data poisoning corrupts the model during training or fine-tuning, well before any inference request exists. This is OWASP LLM03, and the controls are data-provenance checks, training-pipeline integrity, and evaluation, which I cover in AI model poisoning. A request-path proxy never sees the training run, so it cannot govern this.

Model-weight theft and infrastructure compromise are storage, network, and access-control problems around the model artifact and its hosting. Stolen weights, a breached inference server, or a compromised dependency in the serving stack (OWASP LLM05, supply-chain vulnerabilities) are handled by secrets management, network segmentation, and platform hardening. The broader catalog of these lives in LLM security vulnerabilities. A gateway that reads AI traffic is the wrong layer for any of them, and a vendor claiming otherwise is overreaching.

DeepInspect

This is the boundary DeepInspect works inside. DeepInspect is a stateless, identity-aware proxy on the AI request path. It terminates the AI request so it reads the decrypted HTTP payload rather than an encrypted tunnel, binds the call to the identity the application supplies, classifies the prompt and the response, and applies a pass, block, or modify decision before the request reaches any model or the response reaches the caller.

Against the six governable risks above, that gives you one place to enforce two controls: identity-aware policy on every inbound and outbound AI call, and a signed, per-decision audit record for each one. It does not train your models, guard your weights, or segment your network, and it should not claim to. For the risks that ride the request path, it is the control that sits where they travel.

If you are mapping generative AI risk to controls and want to see which of yours a request-path gateway would cover, book a demo today.