Mapping the OWASP LLM Top 10 to runtime controls
July 4, 2026 · 5 min read · Runline
The OWASP LLM Top 10 gives security teams shared vocabulary for AI risk, but most published mitigations concentrate on the prompt-and-model layer: input filtering, output validation, guardrail prompts. For agentic systems, where the model's output becomes a shell command or an MCP tool call, several risks are only fully addressable at tool execution time. This mapping covers that slice, in the language a security review or RFP expects.
The mapping
| OWASP LLM risk | Runtime control at the exec boundary |
|---|---|
| LLM01: Prompt injection | Injection succeeds upstream; the hijacked action still fails. Actor-aware deny on destructive CLI/MCP calls means the compromised agent's next tool call is evaluated against policy it cannot see or edit. |
| LLM02: Insecure output handling | Model output that becomes a command is parsed and evaluated before exec: the command shape, target, and actor decide the verdict, not the output's plausibility. |
| LLM06: Sensitive information disclosure | Credential-pattern runtime guards block agent reads of keychains, .env files, and cloud credential stores; audit events forward to the customer SIEM. |
| LLM08: Excessive agency | The scope of agency is set by policy, per actor class: AI-driven modify operations deny or route to human approval; human shells pass through untouched. |
| LLM09: Overreliance | Deterministic signed policy and a fail-closed managed fleet replace "trust the model's judgment": no supervising LLM whose own reliability must be trusted. |
| LLM10: Model theft | Out of scope: Runline hosts no models. Listed for completeness so reviewers can close the line item. |
How to use this in a review
- For each risk, ask where the mitigation executes: model layer, application layer, or endpoint exec boundary. Defense in depth wants more than one.
- For LLM01 and LLM08 specifically, ask what happens after a successful injection; a control that assumes injection is prevented upstream is not a control for it.
- Require evidence per decision (actor, rule, verdict, timestamp), not aggregate dashboards; auditors ask for the specific denied command.
- Ask for the failure mode: what happens when the enforcement daemon is unreachable? Fail-open turns every other answer theoretical.
The scenario gauntlet on our proof page shows these controls exercised against PocketOS-class attacks in CI, with results regenerated from the artifact on every run, alongside the limits we disclose in every POV scoping call. View the proof page →
See the enforcement layer in action
A 30-day POV deploys the agent to a pilot group, replays the scenario gauntlet against your policy, and proves coverage - dry-run first, enforce when ready.