AI Governance Packs

Governance packs are curated, versioned OPA policy bundles that map your sandboxes to a security framework’s controls. Enable a pack with a single policy_ref and every matching action your agent takes is gated at the declaw enforcement layer — with the framework’s control IDs recorded on each denial for audit-ready evidence. Packs build on declaw’s non-bypassable platform floor (which already blocks living-off-the-land commands, kernel-module loading, cloud-metadata/IMDS access, and metadata egress). A pack adds denials and attaches framework control IDs; it can only tighten policy, never relax it.

Available packs

Pack (`policy_ref`)	Framework
`baseline-hardening@v1`	Declaw Baseline Hardening (reverse-shell / remote-shell tooling)
`owasp-llm-top10@v1`	OWASP Top 10 for LLM Applications (2025)
`owasp-agentic@v1`	OWASP Top 10 for Agentic Applications (ASI, 2026)
`owasp-mcp@v1`	OWASP MCP Top 10 (2025)
`eu-ai-act@v1`	EU AI Act — Regulation (EU) 2024/1689
`nist-ai-rmf@v1`	NIST AI RMF 1.0 + Generative AI Profile (AI 600-1)
`iso-42001@v1`	ISO/IEC 42001:2023 (AI Management System)
`mitre-atlas@v1`	MITRE ATLAS (adversarial ML threats)
`csa-aicm@v1`	CSA AI Controls Matrix (AICM) v1.0
`prompt-injection@v3`	declaw Prompt-Injection Defense (OWASP LLM01 + MITRE ATLAS AML.T0051)

Browse the live catalog (each pack’s enforces vs advisory controls, gates, and description):

curl https://api.declaw.ai/governance/packs

Honest by design. Each pack distinguishes the controls it actually enforces (a real policy rule that fires a denial) from controls it can only mark advisory (a framework requirement with no runtime signal at the sandbox layer — e.g. organizational process, human-in-the-loop approval, or response-body inspection). A pack never claims a control it can’t enforce. Governance packs are an enforcement + evidence tool, not a legal conformity assessment.

Per-pack controls

The tables below are the authoritative, per-pack breakdown: which gates each pack touches, the framework control IDs it enforces (each backed by a deny rule that fires at the named gate), and which control IDs it can only carry as advisory evidence. The same data is served live from GET /governance/packs (the enforces and advisory arrays). Gate names map to the enforcement points described under How it works:

Gate	Enforcement point	Governs
`cmd`	`cmd.exec`	every command the agent (or a sub-agent) runs
`network`	`net.egress`	every outbound connection
`content`	`content.scan`	the request body on LLM egress (model, injection findings)
`lifecycle`	`sandbox.create`	provisioning (tier, template, features)

When the same control ID appears under more than one gate (e.g. EU AI Act Art.15 at both cmd and network), the pack enforces it on every listed gate independently.

`baseline-hardening@v1` — Declaw Baseline Hardening

policy_ref: baseline-hardening@v1 · Gates: cmd Sensible default hardening on top of the platform floor — it adds a single deny rule that blocks reverse-shell / remote-shell tooling a compromised agent commonly reaches for, and attaches three framework IDs to that denial. Safe to apply as an org-wide account floor.

Control (enforced)	Gate	Blocks
`OWASP-LLM06-ExcessiveAgency`	`cmd`	Reverse-shell / remote-shell tooling launched by the agent.
`OWASP-ASI04-PrivilegeCompromise`	`cmd`	Same denial, attributed to agentic privilege compromise.
`MITRE-ATLAS-AML.T0024`	`cmd`	Same denial, attributed to the ATLAS exfiltration technique.

No advisory controls — this pack maps only to what it enforces.

`owasp-llm-top10@v1` — OWASP Top 10 for LLM Applications (2025)

policy_ref: owasp-llm-top10@v1 · Gates: cmd, network, content

Control (enforced)	Gate	Blocks
`OWASP-LLM06-ExcessiveAgency`	`cmd`	Reverse-shell / remote-shell tooling.
`OWASP-LLM02-SensitiveInfoDisclosure`	`network`	IMDS / cloud-metadata egress (re-asserted for control-ID evidence).
`OWASP-LLM01-PromptInjection`	`content`	High-confidence prompt injection on LLM egress.

Advisory (no in-sandbox runtime signal today): OWASP-LLM03-SupplyChainVulnerabilities, OWASP-LLM04-DataModelPoisoning, OWASP-LLM05-ImproperOutputHandling, OWASP-LLM07-SystemPromptLeakage, OWASP-LLM08-VectorEmbeddingWeaknesses, OWASP-LLM09-Misinformation, OWASP-LLM10-UnboundedConsumption. LLM05/07 await response-body scanning; LLM10 is handled by platform tier concurrency, billing caps, and rate limiting rather than a deny rule.

`owasp-agentic@v1` — OWASP Top 10 for Agentic Applications (ASI, 2026)

policy_ref: owasp-agentic@v1 · Gates: cmd, network

Control (enforced)	Gate	Blocks
`OWASP-ASI02-ToolMisuse`	`cmd`	Reverse-shell / remote-code-reuse tooling.
`OWASP-ASI04-PrivilegeCompromise`	`cmd`	Same command denial, attributed to privilege compromise.
`OWASP-ASI06-MemoryPoisoning`	`network`	IMDS / metadata SSRF.
`OWASP-ASI02-ToolMisuse`	`network`	Loopback egress to co-located services.

Advisory (alignment/structural concerns with no gate signal today): OWASP-ASI01-GoalHijack, OWASP-ASI03-AgentIdentity (enforced structurally by microVM + per-sandbox network namespace, not a Rego rule), OWASP-ASI05-UnexpectedCodeExecution (constrained by the microVM boundary), OWASP-ASI07-InterAgentComms, OWASP-ASI08-CascadingFailures, OWASP-ASI09-HumanAgentTrust, OWASP-ASI10-RogueAgents.

`owasp-mcp@v1` — OWASP MCP Top 10 (2025)

policy_ref: owasp-mcp@v1 · Gates: cmd, network Targets MCP-server sandboxes.

Control (enforced)	Gate	Blocks
`OWASP-MCP05-CommandInjection`	`cmd`	Reverse-shell tooling a compromised MCP server could use to fan out.
`OWASP-MCP02-ScopeCreep`	`network`	Loopback egress (MCP server scope-creeping onto co-located internal services).
`OWASP-MCP09-ShadowServers`	`network`	IMDS / cloud-metadata egress (shadow MCP server probing cloud credentials).

Advisory (no runtime signal in the current sandbox plane): OWASP-MCP01-TokenMismanagement, OWASP-MCP08-Audit (covered by the platform audit log — operational config, not a deny rule), OWASP-MCP03-ToolPoisoning, OWASP-MCP04-SupplyChain, OWASP-MCP06-IntentSubversion, OWASP-MCP07-AuthNZ, OWASP-MCP10-ContextOverSharing.

`eu-ai-act@v1` — EU AI Act (Regulation (EU) 2024/1689)

policy_ref: eu-ai-act@v1 · Gates: cmd, network Attaches Article control IDs to denials the enforcement and audit pipeline already generates, for conformity documentation. Not a legal conformity assessment or certification under Annex III or any other provision of the Regulation.

Control (enforced)	Gate	Blocks
`EU-AI-Act-Art15-Robustness`	`cmd`	Reverse-shell tooling at the command gate.
`EU-AI-Act-Art15-Robustness`	`network`	IMDS / metadata egress at the network gate.
`EU-AI-Act-Art10-DataGovernance`	`network`	Cloud-credential exfil (SSRF) at the network gate.

Advisory (process/governance, or platform-pipeline capabilities rather than deny rules): EU-AI-Act-Art9-RiskManagement, EU-AI-Act-Art11-TechnicalDocumentation, EU-AI-Act-Art12-AutomatedLogging (satisfied by the audit pipeline with control-ID evidence), EU-AI-Act-Art14-HumanOversight, EU-AI-Act-Art19-PostMarketLogging.

`nist-ai-rmf@v1` — NIST AI RMF 1.0 + Generative AI Profile (AI 600-1)

policy_ref: nist-ai-rmf@v1 · Gates: cmd, network, lifecycle Maps NIST AI RMF MANAGE/MEASURE controls plus the relevant SP 800-53 controls.

Control (enforced)	Gate	Blocks
`NIST-SI-4`	`cmd`	Reverse-shell / remote-execution tooling (integrity monitoring).
`NIST-AC-6`	`cmd`	Same denial, framed as least privilege.
`NIST-SC-7`	`network`	IMDS / cloud-metadata egress (boundary protection).
`NIST-AC-4`	`network`	Cloud-metadata information flow (flow enforcement).
`NIST-AC-3`	`lifecycle`	Free-tier provisioning of the code-security scanner (access enforcement).

Advisory (governance/design-time, or GenAI risks with no signal source): NIST-AI-RMF-GOVERN, NIST-AI-RMF-MAP, NIST-AI-600-1-Hallucination, NIST-AI-600-1-Bias, NIST-AI-600-1-HITL, NIST-AI-600-1-DataProvenance, NIST-AI-600-1-TokenBudget.

`iso-42001@v1` — ISO/IEC 42001:2023 (AI Management System)

policy_ref: iso-42001@v1 · Gates: content, lifecycle Attaches Annex A control IDs to denials the platform already fires, producing structured evidence for an AIMS conformity review.

Control (enforced)	Gate	Blocks
`ISO-42001-A.8.3`	`content`	High-confidence prompt injection on LLM egress (interception precondition applies).
`ISO-42001-A.6.2`	`lifecycle`	Free-tier provisioning of the enterprise code-security scanner.

Advisory (the bulk of Annex A — organisational/process controls): ISO-42001-4.1, 4.2, 5.1, 5.2, 5.3, 6.1, 6.2, A.2.2, A.2.6, A.3.3, A.4.1, A.5.2, A.6.1, A.7.1, A.7.4, A.8.1, A.8.2, A.9.1 (response-body / output scanning is not yet available).

`mitre-atlas@v1` — MITRE ATLAS

policy_ref: mitre-atlas@v1 · Gates: cmd, network Re-asserts platform-floor kernel-module and IMDS denials under their ATLAS technique IDs so every audit event carries the ATLAS reference.

Control (enforced)	Gate	Blocks
`MITRE-ATLAS-AML.T0011`	`cmd`	Kernel-module abuse (User Execution).
`MITRE-ATLAS-AML.T0024`	`cmd`	IMDS access via `curl` / `wget` (Exfiltration via cloud metadata).
`MITRE-ATLAS-AML.T0024`	`network`	Cloud-metadata endpoint egress.

Advisory (ML attack-staging / model-access / data-poisoning tactics with no sandbox-layer signal): MITRE-ATLAS-AML.T0005, AML.T0012, AML.T0019, AML.T0020, AML.T0043.

`csa-aicm@v1` — Cloud Security Alliance AICM v1.0

policy_ref: csa-aicm@v1 · Gates: cmd, network Maps the runtime/infrastructure subset of the 18 AICM domains onto declaw denials, cross-referencing the ISO/NIST IDs the platform rules already carry.

Control (enforced)	Gate	Blocks
`CSA-AICM-IES`	`cmd`	Reverse-shell tooling (Infrastructure & Endpoint Security).
`NIST-SI-4`	`cmd`	Same command denial, cross-referenced to SI-4.
`CSA-AICM-DSP`	`network`	IMDS / cloud-metadata SSRF (Data Security & Privacy Lifecycle).
`NIST-SC-7`	`network`	Same egress denial, cross-referenced to SC-7.

Advisory (the remaining ~230 governance, model-lifecycle, supply-chain, and transparency objectives): CSA-AICM-AIG, MLC, SCM, TRN, RAI, INC, DRM, IAM, BCR, THR, AUD, PRI, EXP, HIT, VUL, CHG, MON, ETH.

`prompt-injection@v3` — declaw Prompt-Injection Defense

policy_ref: prompt-injection@v3 · Gates: content Selects a prompt-injection detection posture, escalates to the Tier-2 LLM judge accordingly, and denies high-confidence injection at the content gate. Author your own content.rego via custom_policy.inline_modules to override the posture — custom injection guardrails through the same OPA framework, no new mechanism.

Control (enforced)	Gate	Blocks
`OWASP-LLM01-PromptInjection`	`content`	High-confidence prompt injection (with posture selection).
`MITRE-ATLAS-AML.T0051-PromptInjection`	`content`	Static-signature injection hits (once the static-signature scanner is wired).

Advisory: indirect-injection-multi-turn (cross-domain / multi-turn injection is adjudicated by the Tier-2 judge over session context, which the posture routes to, rather than by a content-gate deny rule) and harmful-assistance-backstop (any static-signature match escalates to the judge, whose backstop adjudicates harm-shaped egress the cheaper layers don’t hard-deny — OPA routes to the judge rather than deciding harm itself).

Enable a pack

Per sandbox (SDK)

Reference a pack in the sandbox’s custom_policy:

from declaw import Sandbox, SecurityPolicy, CustomPolicyConfig

sandbox = Sandbox.create(
    security=SecurityPolicy(
        custom_policy=CustomPolicyConfig(
            enabled=True,
            policy_ref="owasp-llm-top10@v1",
        ),
    ),
)

import { Sandbox } from "declaw";

const sandbox = await Sandbox.create({
  security: {
    customPolicy: { enabled: true, policyRef: "owasp-llm-top10@v1" },
  },
});

sb, err := declaw.CreateSandbox(declaw.SandboxConfig{
    Security: &declaw.SecurityPolicy{
        CustomPolicy: &declaw.CustomPolicyConfig{
            Enabled:   true,
            PolicyRef: "owasp-llm-top10@v1",
        },
    },
})

Account-wide floor (admin)

Apply a pack as a non-bypassable floor on every sandbox an account creates — no per-sandbox change required:

curl -X POST https://api.declaw.ai/admin/accounts/<account_id>/policy \
  -H "X-Admin-Secret: $ADMIN_SECRET" \
  -d '{ "policy_ref": "owasp-llm-top10@v1", "enabled": true }'

Stacking multiple frameworks

To enforce several frameworks at once, publish a composite bundle (the concatenation of the member packs — denials are additive and tighten-only) and point a single policy_ref at it. Composites are published through the same bundle endpoint and referenced exactly like a single pack.

Model / endpoint allowlists

Some controls (OWASP LLM03 supply-chain, ASI02 tool misuse) need to see the model an agent calls. Opt a sandbox into the content gate so a model-allowlist rule runs on LLM egress even without an ML scanner enabled:

SecurityPolicy(
    content_gate={"enabled": True, "domains": ["api.openai.com", "api.anthropic.com"]},
    custom_policy=CustomPolicyConfig(enabled=True, policy_ref="owasp-llm-top10@v1"),
)

The model is read from the (decrypted) request body and exposed to your policy as input.attributes.model.

Compliance evidence

Every denial a pack produces records the framework control IDs it satisfies (from the rule’s metadata) into the audit log. Pull the per-account compliance report — enabled packs plus denials grouped by control, framework, and gate over a window:

curl "https://api.declaw.ai/admin/accounts/<account_id>/compliance?start=<ISO>&end=<ISO>" \
  -H "X-Admin-Secret: $ADMIN_SECRET"

{
  "enabled_packs": { "account_policy": { "policy_ref": "owasp-llm-top10@v1", "enabled": true } },
  "denials_by_control": [ { "control": "OWASP-LLM06-ExcessiveAgency", "count": 42 } ],
  "denials_by_framework": [ { "framework": "OWASP", "count": 51 } ],
  "denials_by_gate": [ { "category": "command", "event": "command_denied", "count": 12 } ]
}

The same data renders in the console under Admin → Accounts → Compliance.

How it works

A pack is a set of OPA Rego modules — one per enforcement gate it touches:

Gate	What it governs	Example pack control
`cmd.exec`	every command the agent (or a sub-agent) runs	reverse-shell tooling → `OWASP-ASI02`
`net.egress`	every outbound connection	IMDS/metadata SSRF → `OWASP-LLM02`
`content.scan`	the request body on LLM egress (model, injection findings)	high-confidence prompt injection → `OWASP-LLM01`
`sandbox.create`	provisioning (tier, template, features)	feature gating → `NIST-AC-3`

Because the agent runs inside the declaw microVM, these gates aren’t advisory — they are the only path the agent’s actions can take. See Network Policies and the security overview for the underlying enforcement model.

How `policy_ref` is resolved

A policy_ref takes one of three forms, all resolving against declaw-controlled storage only (no arbitrary URL fetch):

Form	Scope
`name@version` (e.g. `owasp-llm-top10@v1`)	account-scoped — looked up in the registry keyed by your account, with a shared `platform` fallback for the built-in packs. This is where per-tenant isolation lives.
`sha256:<hex>`	content-addressed, global — fetches the object whose content hashes to `<hex>`.
`blob:<key>`	global — a raw object under the bucket’s `policies/` namespace.

Security model. The sha256: and blob: forms are intentionally content-addressed-global: they ignore the account and read any object in the (dedicated, non-tenant-writable) policy bucket, because shared platform packs and content-addressed dedupe require global reads. Confidentiality of policy text under these forms rests on hash opacity, not access control, and hashes are not secrets. For per-account isolation, use name@version refs; don’t place tenant-confidential policy in the shared bucket expecting per-tenant read scoping. Path traversal and namespace escape are blocked, and resolved policy is never echoed back to the agent.

Getting Started

Core Features

CLI

Security

Platform

Deployment

Architecture

AI Governance Packs

Available packs

Per-pack controls

`baseline-hardening@v1` — Declaw Baseline Hardening

`owasp-llm-top10@v1` — OWASP Top 10 for LLM Applications (2025)

`owasp-agentic@v1` — OWASP Top 10 for Agentic Applications (ASI, 2026)

`owasp-mcp@v1` — OWASP MCP Top 10 (2025)

`eu-ai-act@v1` — EU AI Act (Regulation (EU) 2024/1689)

`nist-ai-rmf@v1` — NIST AI RMF 1.0 + Generative AI Profile (AI 600-1)

`iso-42001@v1` — ISO/IEC 42001:2023 (AI Management System)

`mitre-atlas@v1` — MITRE ATLAS

`csa-aicm@v1` — Cloud Security Alliance AICM v1.0

`prompt-injection@v3` — declaw Prompt-Injection Defense

Enable a pack

Per sandbox (SDK)

Account-wide floor (admin)

Stacking multiple frameworks

Model / endpoint allowlists

Compliance evidence

How it works

How `policy_ref` is resolved

​Available packs

​Per-pack controls

​baseline-hardening@v1 — Declaw Baseline Hardening

​owasp-llm-top10@v1 — OWASP Top 10 for LLM Applications (2025)

​owasp-agentic@v1 — OWASP Top 10 for Agentic Applications (ASI, 2026)

​owasp-mcp@v1 — OWASP MCP Top 10 (2025)

​eu-ai-act@v1 — EU AI Act (Regulation (EU) 2024/1689)

​nist-ai-rmf@v1 — NIST AI RMF 1.0 + Generative AI Profile (AI 600-1)

​iso-42001@v1 — ISO/IEC 42001:2023 (AI Management System)

​mitre-atlas@v1 — MITRE ATLAS

​csa-aicm@v1 — Cloud Security Alliance AICM v1.0

​prompt-injection@v3 — declaw Prompt-Injection Defense

​Enable a pack

​Per sandbox (SDK)

​Account-wide floor (admin)

​Stacking multiple frameworks

​Model / endpoint allowlists

​Compliance evidence

​How it works

​How policy_ref is resolved

Available packs

Per-pack controls

`baseline-hardening@v1` — Declaw Baseline Hardening

`owasp-llm-top10@v1` — OWASP Top 10 for LLM Applications (2025)

`owasp-agentic@v1` — OWASP Top 10 for Agentic Applications (ASI, 2026)

`owasp-mcp@v1` — OWASP MCP Top 10 (2025)

`eu-ai-act@v1` — EU AI Act (Regulation (EU) 2024/1689)

`nist-ai-rmf@v1` — NIST AI RMF 1.0 + Generative AI Profile (AI 600-1)

`iso-42001@v1` — ISO/IEC 42001:2023 (AI Management System)

`mitre-atlas@v1` — MITRE ATLAS

`csa-aicm@v1` — Cloud Security Alliance AICM v1.0

`prompt-injection@v3` — declaw Prompt-Injection Defense

Enable a pack

Per sandbox (SDK)

Account-wide floor (admin)

Stacking multiple frameworks

Model / endpoint allowlists

Compliance evidence

How it works

How `policy_ref` is resolved