Skip to main content
If your security team asks “how does this hold up against the OWASP LLM Top 10?”, you want an answer that points at running controls, not a slide. OrcaRouter ships OWASP Top 10 for LLM Applications as a real installable compliance pack (owasp_llm) — not only a checklist view. Installing it materializes the guardrail rules and firewall policy that each risk maps to, on the same path every request to api.orcarouter.ai already crosses, and snapshots what was caught into a signed report you can hand to an auditor. This page maps each covered OWASP LLM risk to the OrcaRouter control that enforces it, shows how to install the pack, and links to the deep reference for each control. For the install-and-go-live arc across all frameworks, start at the Compliance overview.

​
1. owasp llm top 10 mapped to OrcaRouter controls

The owasp_llm pack is a control mapping that installs as real policy — each entry below is a control the gateway enforces, not a description of intent. The high-signal risks map to live guardrails and a firewall policy; one risk (LLM05) is an organizational control with no gateway enforcement surface.
A Guardrail on the request input. The pack combines the Prompt-Injection Basics safety preset (keyword flagging) with a jailbreak regex rule (DAN/STAN/AIM modes plus Unicode tag-byte hidden-text smuggling) to catch direct and obfuscated injection attempts. Pair it with an llm_judge rule for semantic injection intent. See Prompt injection and Jailbreaks.
A Guardrail on the output stage that blocks model responses containing classic SQL-injection payloads (UNION SELECT, OR 1=1, DROP TABLE) before they reach a downstream system that might auto-execute them. Review matches in the Guardrails match feed.
An organizational control — supply-chain assurance for your models, data, and dependencies is a process you own, not a request-time gateway check. The pack carries it as evidence in the report so your auditor sees it accounted for. For the runtime side of third-party tools, see Securing AI agents.
Two Guardrails: the Secrets & API-Key Blocker (rejects requests carrying AWS / OpenAI / GitHub credentials) and a strict PII Blocker (rejects requests carrying emails, phone numbers, SSNs, credit cards or IPs). Both hard-reject on the request before it reaches the provider. See the PII and secrets sections of Guardrails.
A Guardrail on the output stage that blocks model responses echoing chat-template control tokens (<|system|>, <|im_start|>) — clear evidence the system prompt is being leaked back. Tune the rule and review its hits in the match feed.
A Firewall policy rule that denies dangerous shell / exec-class tool calls — the action-plane control. This is where the firewall, not a content guardrail, does the work: it evaluates the tool calls your model emits. See Dangerous tool calls and Excessive agency.
The pack covers the high-signal subset of the OWASP list that has a concrete gateway enforcement surface — LLM01, LLM02, LLM06, LLM07, LLM08 as enforced controls, plus LLM05 as organizational evidence. Risks that live entirely in your own application code (model theft, training-data poisoning) are outside the gateway’s path and remain yours to address — see Shared responsibility.

​
2. Why guardrails and firewall, not one control

The OWASP LLM list spans two different planes, and OrcaRouter splits its controls along the same line:
PlaneCoversControl
ContentLLM01, LLM02, LLM06, LLM07Guardrails
ActionLLM08Firewall
Guardrails screen prompt and response text; the firewall evaluates tool calls and outbound actions. Excessive agency (LLM08) is an action problem, so it maps to a firewall rule — not a content filter. The split is the whole point: read Guardrails vs Firewall for why a single control can’t cover both.

​
3. Install the pack

Browsing the catalog and readiness is free for any workspace Member. Installing the pack materializes the guardrails and firewall policy, and is a workspace Admin action gated to a paid plan. Do it from the console — Compliance → Catalog → OWASP LLM Top-10 → Install.
Install on a non-production workspace first, or attach the materialized firewall policy in shadow_mode so enforcing verdicts log as [shadow] would … instead of denying. Watch the firewall events and the guardrail match feed for a week, then promote to enforcing once the matches look right.
Installation creates real, editable guardrail rules and a firewall policy in your workspace. They are yours to tune afterward — adjust the PII entity list, swap the LLM08 deny for an audit verdict while you learn your agents’ behavior, or add an llm_judge injection rule on top of the LLM01 keyword/regex base. Attach the guardrail to a key via guardrail_id and the firewall policy via firewall_policy_id, or set either as the workspace default.

​
4. Prove it with a signed report

Coverage you can’t show isn’t coverage. After the pack runs, generate a compliance report — it’s Ed25519-signed and SHA256-stamped, exportable as CSV / JSON / PDF, and publicly verifiable without an OrcaRouter account.

Generate a signed report

What the report snapshots and how it’s signed.

Verify a report

Hand an auditor the public verify endpoint — no account needed.
The report lists each OWASP LLM control, the rule that backs it, and the matches it caught in the reporting window — so the answer to “how does this hold up against the owasp llm top 10?” is a signed artifact, not a verbal assurance.

​
5. Where to go next

Compliance overview

The full install → enforce → report → go-live arc.

What's in a pack

How a pack’s controls become guardrails and firewall policy.

All frameworks

The other AI, security, and privacy packs in the catalog.

Securing AI agents

The baseline that hardens agents against these risks end to end.
OWASP LLM coverage on OrcaRouter is running policy, not a checklist: one install wires the guardrails and firewall rules each risk maps to, and one report proves they fired.