OWASP LLM Top 10 — Policy Pack

Two c16 surfaces sit on either side of the same risk model but never touch:

• Policy & Enforcement decides what agents are allowed to do (capability/action; the Audit → Assist → Enforce ladder; tool allow-lists, approval gates, spend ceilings, kill switch).
• Compliance & Frameworks reports what the fleet's behavior means against external standards (OWASP LLM Top 10, MITRE ATLAS, NIST AI RMF…), auto-mapping each finding to the control it touches.

The missing connective tissue is an org opinion on a standard. OWASP LLM Top 10 is purely descriptive — 10 risk categories, no stance on how strict you should be. To act on it you assign, per control, a posture (Accept / Audit / Assist / Enforce) and wire it to the rules that enforce that posture. That object — a policy pack — closes the loop: applying it populates Policy & Enforcement, and the same control tags light up Compliance with stated posture vs. observed reality.

A single hi-fi mockup of the OWASP LLM Top 10 pack that demonstrates:

1. The 10 controls, each with runtime-reach (Strong / Partial / Not instrumented), the shared rules that satisfy it, live findings mapped to it, and an interactive posture selector.
2. The shared-rules panel — one rule, many controls (the many-to-many made visible).
3. The stated-vs-actual gap — the hero number: controls where you set Assist/Enforce but, because the live system mode is Audit, the mapped findings were only observed.
4. Apply-pack affordance that cross-links to the real c16 Policy & Enforcement and Compliance surfaces.

In

• app/pages/c17/mockups/m1/owasp-policy-pack-v1/pack.vue — the pack mockup.
• Cycle index + registry entry; reuse c16 design language and fixture.

Out

• Changes to the real qcontrol app or to c16.
• A real pack data model / persistence (postures are local reactive state).

A pack is not a monolithic policy that owns its own rules. Control↔rule is many-to-many (LLM06 needs tool-allow-list + approval-gate + kill-switch; egress-allow-list serves both LLM02 and LLM03), and frameworks overlap (OWASP / NIST / ATLAS all touch excessive agency). So:

• Rules are atomic and reusable — tool-allow-list, approval-gate, dlp-deny, egress-allow-list, spend-ceiling, … own their enforcement logic once.
• A pack references rules and maps them to controls + a posture — never duplicates them.

This keeps rules reusable across every future framework pack (SOC 2, NIST AI RMF…) and avoids two packs fighting to enforce the same lever.

Reuses app/data/c16-fleet.ts (qcontrol /api shape) — findings (framework strings carry LLM02 / LLM06 / LLM10), agents. The pack model itself lives inline in the page as a prototype (no new fixture).

• Pack mockup m1 — pack.vue (interactive posture per control, shared-rules reuse panel, stated-vs-actual gap, apply-pack cross-links to c16 Policy & Compliance)
• Refactor onto the locked governance model (policy-controls-v1 / governance.vue) — supersedes the pack pass. The model: a Policy owns a disjoint set of Controls + one response (alert / human-approval / block); a Control is the atomic enforceable check (owned by exactly one policy) and is satisfied by many Frameworks (read-only views, coverage % = active ÷ referenced); a Control violation fires its owning policy's response. Two linked views (Policies | Frameworks) over one shared reactive activation set — toggling a control recomputes framework coverage live. Model in app/data/c17-governance.ts; violations derived from c16-fleet findings.

Model (locked)

Policy    --owns-->        Control   (1-to-many, disjoint — sets the response)
Framework --satisfied by-> Control   (many-to-many, read-only — coverage %)
Control   --violated-->    its owning policy's response fires

A control is owned by one policy, satisfies many frameworks. Activation drives coverage; a control set once (no policy overlap); framework coverage is coverage, not conformance.