Skip to main content
A compliance pack is a framework — SOC 2, HIPAA, GDPR, ISO 27001, the OWASP LLM Top 10 — mapped to the gateway controls that satisfy it. When you install a compliance pack, OrcaRouter doesn’t just bookmark the framework: it materializes the pack’s controls into a real, editable Guardrail (the content plane) and a real Firewall policy (the tool-call plane), tagged with the pack’s provenance so every existing enforcement, attachment, and history path works unchanged. Installs land in observe mode — the guardrail flags instead of blocking, the firewall runs in shadow — so you collect “would-have-blocked” evidence before anything affects live traffic. You take it live later, deliberately, from the console.
Browsing the catalog and checking readiness are free for any workspace member. Installing a pack is a workspace Admin action and requires a paid plan — the gateway enforces both server-side, so a direct API call can’t bypass the gate.

​
1. What “install a compliance pack” actually does

One install call writes three things atomically into your workspace:
The pack’s content-plane controls merge into one named guardrail — <Pack> (Compliance) (e.g. SOC 2 (Compliance)). In observe mode every action (and every per-entity action) is coerced to flag, so it annotates matches without blocking or masking real traffic.
The pack’s tool-call controls merge into one named firewall policy — <Pack> (Compliance — tools) (e.g. SOC 2 (Compliance — tools)) — created with shadow_mode on, so it evaluates and logs every covered call as [shadow] would … but never denies.
A workspace compliance-pack row links the two materialized policies, pins the catalog version, records which controls you selected, and stamps who installed it — plus an audit-log entry.
Because the install produces standard guardrail and firewall objects, you can open them in the console afterward, read every rule, tune them, and attach the firewall policy to a key by firewall_policy_id — just like any policy you authored by hand.

​
2. Install a compliance pack from the console

Compliance configuration uses your console session (UserAuth), not a relay key. Do it in the console:
1

Open the compliance catalog

Go to Compliance in the workspace console. Browse the catalog and open the framework you need — for example SOC 2 (soc2) or the OWASP LLM Top-10 (owasp_llm). Each pack lists its controls, which plane each control lands on, and the official reference.
2

Pick controls (or take them all)

Install the whole framework, or select a subset of controls. An empty selection installs every control in the pack.
3

Install

As workspace Admin on a paid plan, click Install. The pack materializes in observe mode immediately. Re-installing an already-installed pack is idempotent — it returns the existing record, not a duplicate.
4

Watch the evidence, then go live

Let the shadow guardrail and firewall accumulate would-have-blocked matches. When the posture looks right, take the pack live to flip the declared actions on and (optionally) promote the policies to your workspace default. See Observe vs enforce.
Install the OWASP LLM Top-10 pack first if you’re not sure where to start — it maps directly onto the threats this docs section covers (injection, insecure output handling, sensitive-information disclosure, system-prompt leakage, and excessive agency) and gives you a concrete posture to observe.

​
3. The underlying call

The console drives one endpoint. It’s documented here so you can see the shape, audit it, or script an internal provisioning flow — but the gateway requires a workspace Admin session token and a paid plan to reach it: 
POST /api/compliance/packs/{key}/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ "controls": ["owasp.llm01_injection", "owasp.llm08_excessive_agency"] }
An empty body installs all controls in the pack: 
POST /api/compliance/packs/owasp_llm/install
The response is the install record — the pack key, the pinned version, mode: observe, and the ids of the materialized guardrail_id and firewall_policy_id so you can open them straight away.
A malformed (non-empty but unparseable) body is rejected, not silently treated as “install everything” — so a client serialization bug can never quietly broaden a partial install to the full framework. Send valid JSON, or send nothing at all.

​
4. After installing

ThenWhere
See what’s in the packPack contents
Take it liveObserve vs enforce
Generate signed evidenceSigned report
Installing is the cheap, reversible first move: it costs no live traffic, it’s idempotent, and uninstalling removes both materialized planes cleanly. The deliberate step is going live — that’s where the declared block/mask/deny actions switch on.
Why a paid plan to install and not just to enforce? Materializing a framework into live-editable policy is the value moment — the gateway gates it at install and again at go-live so the upgrade boundary is explicit, never a surprise 403 mid-rollout.

Plan gating

Exactly which compliance actions are free, and which need a paid plan.

Observe vs enforce

How observe mode collects evidence and what changes at go-live.

Control matrix

How each framework control maps onto gateway guardrails and firewall rules.

OWASP LLM Top 10

The pack that maps onto the agent-security threats in this section.

Guardrails reference

The content plane an install materializes — rules, PII, actions.

Agent Firewall reference

The tool-call plane an install materializes — verdicts and surfaces.
For the bigger picture of which side of the line you own versus the gateway, see Shared responsibility; for the frameworks catalog, see Frameworks.