Skip to main content
When an auditor asks “prove these controls were actually enforced,” a screenshot of your console won’t survive scrutiny — it’s unsigned, it’s yours, and it’s editable. OrcaRouter generates a signed compliance report: a self-contained evidence pack snapshotted from your live gateway controls, hashed with SHA256, and signed with Ed25519 so anyone holding the report can verify it was produced by OrcaRouter and has not been altered since. This page walks the use case end to end — generate the report, hand it over, and let the auditor verify it independently. For the framework catalog and what each pack maps to, see Frameworks and Pack contents.

​
1. What the signed ai compliance report contains

A report is generated per framework over a time window you choose, and snapshots eight evidence sections at generation time so the artifact stays valid even after the underlying logs age out under your retention policy.
Every report covers the same ordered sections so two reports are comparable:
  • Coverage — which framework controls your installed packs map to, each tagged covered / observe / gap / attested.
  • Enforcement — the guardrail matches and firewall verdicts (allowed / blocked / audited) actually recorded in the window.
  • Consent — recorded consent state for the period, classified valid / stale / revoked / none.
  • Change log — guardrail history and workspace audit rows over the window.
  • Admin access — who held admin and what privileged actions ran.
  • Gaps — controls not covered, including organizational (people/process) clauses that can never be gateway-automated. The report discloses these as honest gaps rather than implying 100% automated compliance.
  • AI supply chain — the upstream providers (subprocessors) and models reachable by the workspace, to evidence against your DPAs.
  • Access reviews — the workspace’s API keys and privileged member roster for key-rotation hygiene.
The canonical evidence JSON is hashed with SHA256 (lowercase hex). That content hash is signed with Ed25519, and the signature plus a short key id (e.g. orca-…) are embedded in the artifact. Change one byte of evidence and the hash no longer matches; forge the hash and the signature no longer verifies against OrcaRouter’s public key.
  • PDF — the human-readable auditor handoff, with the signature and key id printed on it.
  • JSON — the machine-readable evidence export. (The signature is computed over a canonical form of the evidence, not the raw file bytes, so verify it through the public verify endpoint rather than re-hashing the artifact yourself — see Verify a report.)
  • CSV — flat tabular export for spreadsheets and GRC tooling.
By default, member and actor emails are masked in every export. Opt into unredacted PII explicitly per report when your auditor needs it.
Reports are region-stamped. Each artifact is stored and served under your workspace’s declared data-residency region (us / eu / uk / ap / cn / global); a report produced for one region is not served under another. Set residency before you generate if it matters for your obligations.

​
2. Who can generate one

Browsing the framework catalog, installed packs, and readiness is open to every workspace member and is free. Generating a report requires workspace Admin, and the export is plan-gated:
  • The free plan includes one PDF report, so you can demo the artifact.
  • CSV / JSON export and additional reports require a paid plan.
Both rules are enforced server-side — there’s no client-only bypass.
Generate from the console: open Compliance → Reports, pick the framework and time window, choose a format, and click generate. Generation is asynchronous — the report row appears as pending, walks to generating, and lands at ready (or failed, with no partial artifact). All of this runs against the /api/compliance/* routes under your console session — no relay (sk-orca-…) key is involved.

​
3. One concrete walkthrough

A SOC 2 auditor wants enforcement evidence for Q1. The workflow:
1

Install the framework (once)

As an Admin on a paid plan, install the SOC 2 pack from Compliance → Frameworks. Installing materializes the guardrails and firewall policies that map to the framework’s controls. See Install a pack.
2

Generate the report

In Compliance → Reports, select soc2, set the period to your Q1 window, choose PDF, and generate. Wait for the row to reach ready, then download.
3

Hand it to the auditor

Send them the PDF (or mint a read-only auditor share link so they can pull it themselves). The signature and key id are printed on the report.
4

They verify it independently

The auditor never has to trust your console. They re-hash the evidence, fetch OrcaRouter’s public key, and check the signature — all against public, unauthenticated endpoints (next section).

​
4. How an auditor verifies it

Verification needs no account and no relay key — it runs against two public endpoints on api.orcarouter.ai. First, fetch the active public key: 
curl https://api.orcarouter.ai/api/public/compliance/pubkey
# => { "algo": "ed25519", "key_id": "orca-…", "public_key": "<base64>" }
Then submit the report’s content hash, signature, and key id: 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "<sha256-hex from the report>",
    "signature":    "<base64 Ed25519 signature>",
    "sig_key_id":   "orca-…"
  }'
# => { "valid": true, "key_id": "orca-…" }
A valid: true means the evidence hash was signed by OrcaRouter and has not changed since. An auditor who’d rather not call our endpoint at all can take the published Ed25519 public key and verify the signature over the hash with any standard crypto library — the report is verifiable offline.
Prefer not to send the PDF as an attachment? Mint a read-only auditor share link instead — a tokenized URL that serves the report (and its signature) directly, with no login. See Export evidence.

​
5. Where this fits

The signed report is the artifact at the end of the compliance flow. The pieces around it:

Frameworks

The full catalog — SOC 2, HIPAA, GDPR, EU AI Act, ISO 27001/42001, NIST AI RMF, PCI DSS, OWASP LLM Top 10, and the regional set.

Install a pack

Materialize a framework’s guardrails and firewall policies before you report on it.

Data residency

Stamp and pin the region your signed report is stored and served under.

Verify a report

The verification flow in depth — public key, hash, and offline checks.
The evidence inside the report comes from the controls you’ve configured. To strengthen what gets reported, tune your Guardrails and Firewall, and review the boundary of what the gateway can and can’t attest in Shared responsibility.