Skip to main content
The compliance report turns the denials your governance packs and custom 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: 
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"

{
  "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

FieldWhat it tells you
enabled_packs.account_policyThe account-wide floor in force — its policy_ref, whether it’s enabled, its default_deny posture, and its version.
enabled_packs.published_bundlesEvery policy bundle published under the account (name, version, content hash).
denials_by_controlPolicy-gate blocks attributed to a specific framework control ID, highest first. This is the per-control evidence.
denials_by_frameworkThe same denials rolled up by framework prefix (OWASP, NIST, MITRE, EU, …).
denials_by_gateThe same denials grouped by the enforcement gate that produced them (see below).
catalogAvailable 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:
Gatecategory / eventWhat it governs
Commandcommand / command_deniedA command the agent (or a sub-agent) tried to run was blocked.
Networknetwork / egress_blockedAn outbound connection was blocked.
Contentsecurity / content_policy_blockedThe request body on LLM egress (model, injection findings) was blocked.
Lifecyclelifecycle / sandbox_create_deniedA sandbox-create was blocked at provisioning (tier, template, features).
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.

​
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.
  • Governance Packs — the curated, framework-aligned bundles whose control metadata produces this evidence.