Skip to main content
You are putting an AI agent in front of customer data and your auditor wants to know which Trust Services clauses you can actually evidence. On a hosted gateway, the honest answer is: the clauses that map to a control running on the request path — logical access, monitoring, and tool-call audit — plus the organizational clauses that a proxy can never enforce and must disclose as gaps. This page is the soc 2 ai walkthrough: which TSC clauses the SOC 2 pack covers, the one control it materializes for confidentiality, and how the resulting evidence is signed. For the install flow and the report format in depth, follow the links at the end — this page is the SOC 2-specific map, not the full Compliance reference.

1. What the soc 2 ai pack covers

The SOC 2 pack maps the AICPA Trust Services Criteria to controls that run on every gateway-crossing request. Three clauses map to live enforcement; two are organizational and are disclosed as gaps rather than claimed.
TSC clausePlaneControl
CC6.1 Logical access controlsguardrailblock confidential PII in prompts
CC7.2 System monitoringguardrailrecord every guardrail decision as evidence
CC7.2 Anomaly detectionfirewallaudit every tool dispatch
CC8.1 Change management and CC3.1 Risk assessment are people-and-process clauses. A proxy cannot enforce them, so the pack surfaces them as disclosed gaps (or owner-attested rows) on both the console and the report — never as automated coverage. Honest gaps are what make the rest of the evidence trustworthy. See the control matrix.
The two enforcement planes are the same Guardrails and Firewall machinery you configure by hand. The pack is the authored mapping that says which existing control satisfies which clause — it ships no new runtime engine. See Pack contents for the full anatomy.

2. Install the pack — one concrete example

Installing materializes the mapping into one guardrail policy and one firewall policy in your workspace, each tagged with the pack’s provenance. You do this from the console, not a relay key: Compliance → Catalog → SOC 2 → Install That is a workspace-Admin action on a paid plan, and the server enforces both. Under the hood your console session calls:
POST /api/compliance/packs/soc2/install
Never hand a relay sk-orca-… key to a configuration route. The /api/compliance/* routes authenticate with your console session, not the relay key — only /v1/* model calls use sk-orca-…. Browsing the catalog, installed packs, and readiness is free and open to every workspace member; install, go-live, report, and residency are the gated Admin actions.
After install, the CC6.1 row stops being prose. The confidentiality control becomes a real pii guardrail rule — action block, stage input — that you can open, read, and tune like any other rule. The CC7.2 monitoring control records each guardrail decision as evidence, and the firewall control sets every tool dispatch to the audit verdict.
This control acts on the request: confidential PII is blocked on the input stage before the model sees it. Live output / streaming PII handling is on the roadmap, so for the output side the monitoring evidence is what an auditor reads for CC7.2 over the report period.

3. Observe first, then go live

A SOC 2 install does not start blocking traffic on day one. Installs land in observe mode: guardrail actions are coerced to flag and the firewall policy runs in shadow (log-only). You get “would-have-blocked” evidence against real traffic before anything enforces. When the evidence looks right, a workspace Admin promotes the pack to go-live, which restores the declared actions — the CC6.1 control starts blocking, the firewall control keeps auditing — and optionally promotes the materialized policies to workspace default. This is the same discipline described in Observe vs enforce.

4. Signed evidence your auditor can verify

The point of the pack is the report. SOC 2 evidence is generated as an Ed25519-signed report with a SHA256 content hash, exportable as CSV, JSON, or PDF, and publicly verifiable — your auditor checks the signature without an OrcaRouter login.
Each TSC row carries its status — covered, observe, gap, or attested — and how many times the control actually fired over the period. A CC6.1 control that blocked 4,000 requests reads differently to an auditor than one with zero matches, and the report shows both.
Every materialized control records its control_id (e.g. soc2.confidentiality), the verbatim clause (TSC CC6.1 Logical access controls), the plane, and the id of the live policy object enforcing it — so the auditor walks clause → control → enforcing policy → matches, with no inferred step.
Fetch the signing public key at GET /api/public/compliance/pubkey, submit the report to POST /api/public/compliance/verify, or open a scoped auditor share link at GET /api/public/compliance/share/:token. No account required.
See the signed report for the full cover-to-footer layout and Verify a report for the verification walkthrough.

5. Region-stamp your SOC 2 evidence

SOC 2 reports are stored and served under your declared residency region — us / eu / uk / ap / cn / global — and a report is only served under a matching region; cross-region reads are withheld. A workspace Admin sets it via PUT /api/compliance/residency.
Residency here is the evidence artifact region — where signed reports live and are served. It is not inference-data geo-pinning. See Data residency and Cross-region for the boundary.
Request logs default to a 30-day retention (server-clamped to a 180-day hard max), and a user deletion runs a 30-day grace window then a PII scrub — both relevant when an auditor asks about your retention posture. See Retention and Right to erasure.

6. Where to go next

Pack contents

The full anatomy of a pack — both planes, statuses, and provenance.

Install a pack

The end-to-end install flow, observe mode, and go-live.

Signed report

What the Ed25519-signed evidence report contains.

Control matrix

Every clause, its plane, and whether it is covered, observed, or a gap.

Frameworks

The full catalog — HIPAA, GDPR, the EU AI Act, ISO 27001, and more.

Guardrails vs Firewall

The two planes a SOC 2 pack writes to, run by one resolver.
SOC 2 on a hosted gateway is the discipline of being precise: map the clauses a proxy can enforce to live controls, disclose the ones it cannot, and sign the evidence so the line between the two holds up under audit.