Skip to main content
When an auditor asks how your AI gateway enforces a Trust Services Criterion, screenshots of a dashboard don’t cut it. This recipe turns the controls you already run on OrcaRouter into soc 2 evidence ai auditors can independently verify: install the SOC 2 pack, watch it in observe mode, flip to enforce, then export a cryptographically signed readiness report and share a read-only link. Everything below is workspace configuration in the console — your app keeps calling /v1/chat/completions unchanged.
Browsing the catalog and reading readiness are open to any Member and free. Installing a pack, generating a report, going live, and setting residency are workspace Admin actions and require a paid plan — the gateway enforces both server-side. The compliance management routes under /api/compliance/* use your console session, not a relay key.

​
1. The soc 2 evidence ai workflow in four moves

A SOC 2 evidence trail on OrcaRouter is four steps you run once, then re-run the report whenever the auditor wants a fresh snapshot:

Install the pack

The soc2 pack materializes a guardrail and a firewall policy mapped to Trust Services Criteria — installed in observe mode first.

Observe, then enforce

Observe gathers “would-have-blocked” evidence with zero blast radius; go-live flips the same controls to enforcing.

Generate a signed report

Export an Ed25519-signed, SHA-256-hashed readiness report as PDF, JSON, or CSV.

Share with the auditor

Hand over a read-only share link; the auditor verifies the signature against OrcaRouter’s public key — no account needed.
The rest of this page walks all four with one concrete SOC 2 example.

​
2. Install the SOC 2 pack

Open Compliance in the console and browse the catalog (GET /api/compliance/catalog, Member). The soc2 pack maps to the AICPA SOC 2 Trust Services Criteria. Its gateway-enforced controls are confidential-data handling (TSC CC6.1), system monitoring (TSC CC7.2), and a tool-call audit trail (TSC CC7.2). Install it (workspace Admin, paid plan): 
POST /api/compliance/packs/soc2/install
Installing materializes two enforcement objects in one atomic transaction:
  • one workspace guardrail — the content-policy plane (PII, secrets, and the rest of the criteria that screen request/response text), and
  • one workspace firewall policy — the action plane (tool calls, MCP dispatches, and egress that map to access and change-management criteria).
The pack lands in observe mode by default. In observe, guardrail actions are coerced to flag and the firewall policy runs in shadow — every control records what it would have done without touching a single live request. That’s your first batch of evidence.
Some Trust Services clauses are organizational — workforce training, vendor agreements — and a gateway can’t enforce them. The report discloses those honestly as gaps rather than claiming coverage it can’t produce. See enforcement modes for how observe, shadow, and enforce differ.

​
3. Read your live readiness

With the pack installed, Compliance → Readiness (GET /api/compliance/readiness, Member) shows your posture per framework: how many controls are enforcing, how many are still in observe, and how many remain gaps. Each clause maps to the guardrail or firewall control that satisfies it, with a coverage state you can drill into.
Run a week in observe before you enforce. The readiness view plus the guardrail Matches feed and the firewall Events feed tell you exactly what would have been blocked — so you tune false positives before any real request is governed.

​
4. Flip from observe to enforce

Once the would-have-blocked evidence looks clean, take the pack live (Admin): 
POST /api/compliance/packs/soc2/golive
Go-live restores the guardrail’s declared actions (flag becomes block/mask as designed) and takes the firewall policy out of shadow mode, so the same controls now enforce on the relay path. Optionally promote the pack’s guardrail to the workspace default in the same call, so every key inherits it.
Enforce is a real posture change: a blocked prompt now returns HTTP 400 guardrail_blocked and a denied tool call returns HTTP 400 firewall_blocked. A block costs no quota — input blocks are pre-metering and output blocks are refunded — but it will stop traffic that violates a control. That’s the point; just confirm your observe evidence first.

​
5. Generate a signed report

This is the artifact you hand the auditor. Generate it (Admin): 
POST /api/compliance/reports
{
  "framework": "soc2",
  "format": "pdf"
}
format is one of pdf, json, or csv. Every report is signed with Ed25519 over the canonical evidence hash and carries a SHA-256 content hash, so it is tamper-evident and independently verifiable — the auditor doesn’t have to trust your screenshot, they verify the signature.
Each installed framework’s coverage matrix: clause → control → state (enforcing / observe / gap), plus the would-have-blocked evidence captured during observe. Organizational clauses are listed as disclosed gaps, not silently dropped.
The signature binds the report’s evidence hash to OrcaRouter’s signing key. Anyone — including an auditor with no OrcaRouter account — can confirm the report wasn’t altered after generation by checking it against the public key.

​
6. Share it with your auditor

Create a read-only share link for the report (Admin): 
POST /api/compliance/reports/:id/share
The auditor opens the public share endpoint — no login: 
GET /api/public/compliance/share/:token
They then verify the signature themselves against OrcaRouter’s published key:
EndpointPurpose
GET /api/public/compliance/pubkeyFetch the Ed25519 public key.
POST /api/public/compliance/verifyConfirm a report’s signature + hash.
A share link is revocable. Issue one per audit engagement, and revoke it (DELETE /api/compliance/share/:shareId, Admin) when the engagement closes — the report itself stays in your workspace history.

​
7. Pin where the report lives

Auditors and regulators often care about where the evidence is stored. Set the region your compliance report artifacts are pinned to (us, eu, uk, ap, cn, global) via PUT /api/compliance/residency (Admin). Cross-region reads of a report are withheld.
Residency pins the report artifact region only — it is not inference-data geo-pinning. It controls where your signed evidence lives, not where requests are routed.

​
8. Verify before the audit

Prove the trail is real before anyone reviews it:
1

Confirm coverage

Open Readiness and confirm the SOC 2 controls you expect show enforcing, not observe, with no surprise gaps.
2

Round-trip the signature

Generate a report, then POST /api/public/compliance/verify it against the public key — confirm it validates before you share.
3

Open the share link logged out

Hit GET /api/public/compliance/share/:token in a clean browser session to see exactly what your auditor will see.

Guardrails reference

The content-policy plane the SOC 2 pack materializes.

Firewall reference

The action plane behind the pack’s access and change controls.

Enforcement modes

How observe, shadow, and enforce differ — and why observe-first.

HIPAA deployment

The same pack-and-report workflow for a healthcare framework.

PII-safe logging

Keep raw PII out of the logs your evidence draws from.

Go-live checklist

Turn on zero trust before you flip controls to enforce.