メインコンテンツへスキップ
監査人が、あなたの AI ゲートウェイがどのように Trust Services Criterion を強制するかを 尋ねるとき、ダッシュボードのスクリーンショットでは通用しません。このレシピは、あなたが OrcaRouter で既に実行しているコントロールを、監査人が独立して検証できる SOC 2 エビデンスに変えます:SOC 2 パックをインストールし、observe モードで監視し、enforce に 切り替え、それから暗号的に署名されたレディネスレポートをエクスポートして読み取り専用の リンクを共有します。以下はすべてコンソール内のワークスペース設定です — あなたのアプリは /v1/chat/completions を変更なしに呼び続けます。
カタログのブラウジングとレディネスの読み取りは任意の Member に開放され、無料 です。パックのインストール、レポートの生成、go-live、residency の設定はワークスペース Admin のアクションであり、有料プランを必要とします — ゲートウェイは両方を サーバー側で強制します。/api/compliance/* 下のコンプライアンス管理ルートは、リレー キーではなくあなたのコンソールセッションを使います。

1. 4 つの動きで SOC 2 エビデンスワークフロー

OrcaRouter での SOC 2 エビデンス証跡は、一度実行する 4 ステップであり、その後監査人が 新しいスナップショットを望むたびにレポートを再実行します:

パックをインストールする

soc2 パックは、Trust Services Criteria にマッピングされたガードレールと ファイアウォールポリシーを具現化します — まず observe モードでインストール。

observe してから enforce する

observe は爆発半径ゼロで「ブロックされていたはず」のエビデンスを集めます; go-live が同じコントロールを強制に切り替えます。

署名済みレポートを生成する

Ed25519 署名済み、SHA-256 ハッシュ化されたレディネスレポートを PDF、JSON、 または CSV としてエクスポートします。

監査人と共有する

読み取り専用の共有リンクを渡します;監査人は OrcaRouter の公開鍵に対して署名を 検証します — アカウント不要。
このページの残りは、1 つの具体的な SOC 2 の例で 4 つすべてを歩みます。

2. SOC 2 パックをインストールする

コンソールで Compliance を開き、カタログをブラウズします (GET /api/compliance/catalog、Member)。soc2 パックは AICPA SOC 2 Trust Services Criteria にマッピングされます。そのゲートウェイ強制コントロールは、機密データの取り扱い (TSC CC6.1)、システム監視(TSC CC7.2)、そしてツール呼び出しの監査証跡(TSC CC7.2)です。 それをインストールします(ワークスペース Admin、有料プラン):
POST /api/compliance/packs/soc2/install
インストールは、ひとつのアトミックなトランザクションで2 つの強制オブジェクトを 具現化します
  • 1 つのワークスペースガードレール — コンテンツポリシープレーン(PII、secrets、 そしてリクエスト/レスポンステキストをスクリーニングする残りの criteria)、そして
  • 1 つのワークスペースファイアウォールポリシー — アクションプレーン(アクセスと 変更管理の criteria にマッピングされるツール呼び出し、MCP ディスパッチ、egress)。
パックはデフォルトで observe モードに着地します。observe では、ガードレールアクション は flag に強制され、ファイアウォールポリシーは shadow で実行されます — すべての コントロールが、1 つのライブリクエストにも触れずに、何をしていたはずかを記録します。 それがあなたの最初のエビデンスのバッチです。
一部の Trust Services 条項は組織的です — 従業員トレーニング、ベンダー契約 — ゲートウェイはそれらを強制できません。レポートはそれらを、生み出せないカバレッジを 主張するのではなく、ギャップとして正直に開示します。observe、shadow、enforce がどう 異なるかは強制モードを参照してください。

3. ライブのレディネスを読む

パックをインストールしたら、Compliance → ReadinessGET /api/compliance/readiness、Member)が、フレームワークごとのあなたの姿勢を 示します:いくつのコントロールが enforcing か、いくつがまだ observe か、いくつが gaps のままか。各条項は、それを満たすガードレールまたはファイアウォールコントロールに マッピングされ、ドリルダウンできるカバレッジ状態を持ちます。
強制する前に observe で 1 週間実行します。レディネスビューに加えてガードレールの Matches フィードとファイアウォールの Events フィードが、何がブロックされていたはずかを正確に 教えてくれます — つまり、実リクエストが統制される前に誤検出をチューニングします。

4. observe から enforce へ切り替える

「ブロックされていたはず」のエビデンスがクリーンに見えたら、パックをライブにします (Admin):
POST /api/compliance/packs/soc2/golive
go-live は、ガードレールの宣言されたアクションを復元し(flag は設計どおり block/mask に なります)、ファイアウォールポリシーをシャドウモードから外すため、同じコントロールが いまやリレーパスで強制されます。オプションで、同じ呼び出しでパックのガードレールを ワークスペースデフォルトにプロモートして、すべてのキーが継承するようにできます。
enforce は実際の姿勢変更です:ブロックされたプロンプトはいまや HTTP 400 guardrail_blocked を返し、拒否されたツール呼び出しは HTTP 400 firewall_blocked を返します。ブロックはクォータを消費しません — 入力ブロックはメータリング前で、 出力ブロックは返金されます — しかし、コントロールに違反するトラフィックは止めます。 それが要点です;ただし、まず observe エビデンスを確認してください。

5. 署名済みレポートを生成する

これが監査人に渡すアーティファクトです。それを生成します(Admin):
POST /api/compliance/reports
{
  "framework": "soc2",
  "format": "pdf"
}
formatpdfjsoncsv のいずれかです。すべてのレポートは正規のエビデンス ハッシュ上で Ed25519 で署名され、SHA-256 コンテンツハッシュを運ぶため、改ざん 検出可能かつ独立して検証可能です — 監査人はあなたのスクリーンショットを信頼する必要は なく、署名を検証します。
各インストール済みフレームワークのカバレッジマトリクス:条項 → コントロール → 状態(enforcing / observe / gap)、加えて observe 中にキャプチャされた「ブロック されていたはず」のエビデンス。組織的条項は、サイレントに削除されるのではなく、 開示されたギャップとしてリストされます。
署名は、レポートのエビデンスハッシュを OrcaRouter の署名鍵にバインドします。 誰でも — OrcaRouter アカウントを持たない監査人を含めて — 公開鍵に対してチェックする ことで、レポートが生成後に改変されていないことを確認できます。

6. 監査人と共有する

レポートの読み取り専用共有リンクを作成します(Admin):
POST /api/compliance/reports/:id/share
監査人は公開共有エンドポイントを開きます — ログイン不要:
GET /api/public/compliance/share/:token
それから彼らは、OrcaRouter の公開された鍵に対して自分で署名を検証します:
エンドポイント目的
GET /api/public/compliance/pubkeyEd25519 公開鍵を取得。
POST /api/public/compliance/verifyレポートの署名 + ハッシュを確認。
共有リンクは取り消し可能です。監査エンゲージメントごとに 1 つ発行し、エンゲージメントが 終了したら取り消します(DELETE /api/compliance/share/:shareId、Admin) — レポート 自体はあなたのワークスペース履歴に残ります。

7. レポートが存在する場所を固定する

監査人と規制当局は、しばしばエビデンスがどこに保存されるかを気にします。 PUT /api/compliance/residencyAdmin)経由で、あなたのコンプライアンスレポート アーティファクトが固定される地域(useuukapcnglobal)を設定 します。レポートの地域横断的な読み取りは差し止められます。
residency はレポートアーティファクトの地域のみを固定します — 推論データのジオ固定 ではありません。それはあなたの署名済みエビデンスが存在する場所を制御するのであり、 リクエストがルーティングされる場所ではありません。

8. 監査前に検証する

誰かがレビューする前に、証跡が本物であることを証明します:
1

カバレッジを確認する

Readiness を開き、あなたが期待する SOC 2 コントロールが observe ではなく enforcing を、予期しないギャップなしに示していることを確認します。
2

署名をラウンドトリップする

レポートを生成し、それから公開鍵に対して POST /api/public/compliance/verify を 実行します — 共有前に検証されることを確認します。
3

ログアウト状態で共有リンクを開く

クリーンなブラウザセッションで GET /api/public/compliance/share/:token に当たり、 監査人が見るものを正確に確認します。

関連

ガードレールリファレンス

SOC 2 パックが具現化するコンテンツポリシープレーン。

ファイアウォールリファレンス

パックのアクセスと変更コントロールの背後にあるアクションプレーン。

強制モード

observe、shadow、enforce がどう異なるか — そしてなぜ observe ファーストか。

HIPAA デプロイ

ヘルスケアフレームワークのための同じパックとレポートのワークフロー。

PII セーフなロギング

あなたのエビデンスが引き出すログから生の PII を締め出します。

Go-live チェックリスト

コントロールを強制に切り替える前にゼロトラストをオンにします。