> ## 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.

# Compliance Reporting

> Pull a per-account compliance report: enabled governance packs plus policy-denial counts attributed to framework control IDs (OWASP, NIST, MITRE, EU AI Act) over any time window — audit-ready evidence per framework.

The compliance report turns the denials your [governance packs](/security/governance-packs) and [custom policy bundles](/security/policy-bundles) produce into **audit-ready evidence**. Every time a policy gate blocks an action, the Rego rule that fired records the framework control IDs it satisfies onto the audit event. The report aggregates those denials over a window — grouped by control, by framework, and by gate — alongside which packs the account has enabled and the full catalog of available controls.

## Pull a report

`GET /admin/accounts/<account_id>/compliance` with an ISO-8601 `start` and `end`:

```bash theme={null}
curl "https://api.declaw.ai/admin/accounts/<account_id>/compliance?start=2026-06-01T00:00:00Z&end=2026-06-30T23:59:59Z" \
  -H "X-Admin-Secret: $ADMIN_SECRET"
```

```json theme={null}
{
  "owner_id": "<account_id>",
  "window": {
    "start": "2026-06-01T00:00:00Z",
    "end": "2026-06-30T23:59:59Z"
  },
  "enabled_packs": {
    "account_policy": {
      "policy_ref": "owasp-llm-top10@v1",
      "enabled": true,
      "default_deny": true,
      "version": 3
    },
    "published_bundles": [
      {
        "account_id": "<account_id>",
        "name": "acme-baseline",
        "version": "v3",
        "content_hash": "3b1f…e9a2",
        "created_at": "2026-05-12T09:30:00Z"
      }
    ]
  },
  "denials_by_control": [
    { "control": "OWASP-LLM06-ExcessiveAgency", "count": 42 },
    { "control": "NIST-SI-4", "count": 31 },
    { "control": "OWASP-LLM02-SensitiveInfoDisclosure", "count": 9 },
    { "control": "MITRE-ATLAS-AML.T0024", "count": 4 }
  ],
  "denials_by_framework": [
    { "framework": "OWASP", "count": 51 },
    { "framework": "NIST", "count": 31 },
    { "framework": "MITRE", "count": 4 }
  ],
  "denials_by_gate": [
    { "category": "command", "event": "command_denied", "count": 48 },
    { "category": "network", "event": "egress_blocked", "count": 22 },
    { "category": "security", "event": "content_policy_blocked", "count": 9 },
    { "category": "lifecycle", "event": "sandbox_create_denied", "count": 3 }
  ],
  "catalog": [
    {
      "name": "owasp-llm-top10",
      "version": "v1",
      "framework": "OWASP",
      "policy_ref": "owasp-llm-top10@v1",
      "enforced_controls": 7
    },
    {
      "name": "nist-ai-rmf",
      "version": "v1",
      "framework": "NIST",
      "policy_ref": "nist-ai-rmf@v1",
      "enforced_controls": 5
    }
  ]
}
```

## Reading the report

| Field                             | What it tells you                                                                                                          |
| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `enabled_packs.account_policy`    | The account-wide floor in force — its `policy_ref`, whether it's `enabled`, its `default_deny` posture, and its `version`. |
| `enabled_packs.published_bundles` | Every [policy bundle](/security/policy-bundles) published under the account (name, version, content hash).                 |
| `denials_by_control`              | Policy-gate blocks attributed to a specific framework control ID, highest first. This is the per-control evidence.         |
| `denials_by_framework`            | The same denials rolled up by framework prefix (`OWASP`, `NIST`, `MITRE`, `EU`, …).                                        |
| `denials_by_gate`                 | The same denials grouped by the enforcement gate that produced them (see below).                                           |
| `catalog`                         | Available packs and how many controls each actually **enforces** — coverage context to render next to live denials.        |

### What a denial count means

A denial count is a real **enforcement event** — a moment when a policy gate *blocked* an action your agent attempted inside the sandbox, not an advisory finding. Because the agent runs *inside* the declaw microVM, these gates are the only path its actions can take. Each blocked action is attributed to the framework control IDs carried in the firing Rego rule's metadata, so a single denial can count toward several controls at once (e.g. one blocked command satisfying both `OWASP-LLM06` and `NIST-SI-4`).

Use `denials_by_framework` as your top-line evidence per framework, and `denials_by_control` to show exactly which controls have live enforcement signal over the period.

### The four enforcement gates

`denials_by_gate` reports each denial's audit `category` and `event`:

| Gate      | `category` / `event`                  | What it governs                                                          |
| --------- | ------------------------------------- | ------------------------------------------------------------------------ |
| Command   | `command` / `command_denied`          | A command the agent (or a sub-agent) tried to run was blocked.           |
| Network   | `network` / `egress_blocked`          | An outbound connection was blocked.                                      |
| Content   | `security` / `content_policy_blocked` | The request body on LLM egress (model, injection findings) was blocked.  |
| Lifecycle | `lifecycle` / `sandbox_create_denied` | A sandbox-create was blocked at provisioning (tier, template, features). |

<Note>
  Only these four denial events are counted toward compliance evidence. Completed (allowed) actions and non-policy audit events are excluded — the report is strictly the record of what policy *blocked* in the window.
</Note>

## Interpreting it as evidence

The report is designed to be attached directly to a compliance package per framework:

* **Coverage** comes from `catalog` (`enforced_controls` per pack) plus `enabled_packs` (what's actually switched on for the account).
* **Effectiveness** comes from `denials_by_control` / `denials_by_framework` (controls that fired, and how often) over your stated window.

Pair the two: the catalog shows the controls you *can* enforce, and the denial counts show the controls that *did* fire — giving an auditor both the configured surface and the operational evidence for the period.

The same data renders in the console under **Admin → Compliance**, with the framework and control breakdowns shown as charts over a selectable window.

## Related

* [Governance Packs](/security/governance-packs) — the curated, framework-aligned bundles whose control metadata produces this evidence.