> ## Documentation Index
> Fetch the complete documentation index at: https://docs.declaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# AI Governance Packs

> Enable curated, framework-aligned OPA policy packs (OWASP, NIST, EU AI Act, ISO 42001, MITRE ATLAS, CSA AICM) on your sandboxes with one reference — with per-denial compliance evidence.

Governance packs are curated, versioned [OPA](https://www.openpolicyagent.org/) 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):

```bash theme={null}
curl https://api.declaw.ai/governance/packs
```

<Note>
  **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.
</Note>

## 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](#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`:

<CodeGroup>
  ```python Python theme={null}
  from declaw import Sandbox, SecurityPolicy, CustomPolicyConfig

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

  ```typescript TypeScript theme={null}
  import { Sandbox } from "declaw";

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

  ```go Go theme={null}
  sb, err := declaw.CreateSandbox(declaw.SandboxConfig{
      Security: &declaw.SecurityPolicy{
          CustomPolicy: &declaw.CustomPolicyConfig{
              Enabled:   true,
              PolicyRef: "owasp-llm-top10@v1",
          },
      },
  })
  ```
</CodeGroup>

### Account-wide floor (admin)

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

```bash theme={null}
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:

```python theme={null}
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:

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

```json theme={null}
{
  "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](/security/network-policies) and the [security overview](/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.                                                                                                       |

<Note>
  **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.
</Note>