メインコンテンツへスキップ
あなたは、多数の顧客テナントが 1 つのコードベースと 1 つの OrcaRouter ワークスペースを 共有する SaaS を構築しています。各テナントはあなたのゲートウェイ経由でプロンプトを送り、 エージェントを実行します。そして難しい問題は爆発半径です：漏洩したテナントキー、 暴走するテナントエージェント、あるいはあるテナントの PII が別のテナントのログに着地する ことは、境界を越えてこぼれることが許されません。このレシピは、共有ゲートウェイを テナントセーフにする 3 つのコントロールを配線します — テナントごとのスコープキー、 すべてのテナントが継承するワークスペースレベルのポリシー、そしてあるテナントが より多くを必要とするときのテナントごとのオーバーライド — すべてコンソールから、 アプリケーションコードへの変更ゼロで。
ここにあるすべてはあなたのワークスペースにバインドされ、コンソールから設定されます。 あなたのアプリは各テナントの sk-orca-... キーで https://api.orcarouter.ai/v1/chat/completions を呼び続けます — 変わるのはゲートウェイ 内のポリシーだけです。設定アクションは各ステップで示されるロールを必要とします； テナントキーを使うのは /v1/* リレー呼び出しだけです。

​
1. マルチテナント AI セキュリティモデル

マルチテナントゲートウェイは、単一アプリとは異なる脅威の形を持ちます。重要なリスクは テナント数とともにスケールします：

キー漏洩 = 1 テナントの爆発半径

漏洩したテナントキーは、あなたのアカウントを枯渇させたり、公開していないモデルを 呼び出したり、そのテナントの予算を超えて到達したりできるべきではありません。

テナント間のデータ漏れ

あるテナントの PII が共有ログに、あるいは別のテナントにルーティングされた レスポンスに着地することは、あなたのデータ分離の約束を破ります。

騒がしいテナントエージェント

あるテナントのエージェントがツールでループしたり、任意のホストを取得したりしても、 他の全員のためにゲートウェイを劣化させるべきではありません。

テナントごとのコンプライアンス

規制対象のテナントは、他のテナントが必要としない PII マスキングとデータ residency を 必要とするかもしれません。
下記のモデルは 2 つのレイヤーです：すべてのテナントキーが継承するワークスペース ベースライン、加えて他に触れずに 1 つのテナントを締めるキーごとのスコープと オーバーライド。完全な解決ルールについては スコープキー、ポリシー、ワークスペースを 参照してください。

​
2. ベースライン：すべてのテナントが継承する 1 つのワークスペースポリシー

あなたのセキュリティ姿勢をワークスペースレベルで一度作成して、すべてのテナント キーがデフォルトでそれを継承するようにします — テナントごとの複製なし。
1

デフォルトガードレール

Guardrails → New guardrail で、1 つの名前付きポリシー（例：tenant-baseline）を 作成し、ワークスペースデフォルト（is_default）としてマークします。PII ルールを、ステージ input、アクション mask で追加して、どのテナントの リクエストも生の PII をアップストリームに運ばないようにします：
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
明示的なガードレールアタッチメントがないテナントキーは、このデフォルトに フォールバックします。ガードレールの作成には Developer ロールが必要です。
2

デフォルトファイアウォールポリシー

あなたのテナントがエージェントを実行するなら、アクションプレーンでも同じことを します：Firewall → Policies でデフォルトポリシーを作成するか — より速く — Firewall → Posture を開いて balanced 自律性レベルを適用します。これは 最も破壊的なアクションを deny しながら、すべてのテナントのツール呼び出しを audit し、 ワークスペース全体で PII を flag するため、広く強制する前に実際のテナントの振る舞いを 観察できます。Developer ロール。
新しいルールがテナントを途中で壊せないよう、ベースラインを observe → shadow → enforce の順でロールアウトします。ファイアウォールポリシーはポリシーごとの shadow_mode フラグをサポートします（強制判定は [shadow] would … としてログ）； ガードレールルールは flag アクションで開始します。 強制モードを参照。

​
3. テナントごとに 1 つのスコープキー

これがテナント分離の中核です：決してキーをテナント間で共有せず、決してテナントに アカウント全体のキーを渡さない。 テナントごとに 1 つのキーを発行し、そのテナントが してよいことだけにスコープします。API Keys → New key で、次を設定します：
credit_limit_usd をそのテナントの上限に設定します（0 = 無制限）。これは唯一 最も重要なマルチテナントコントロールです：漏洩した、または悪用されたテナントキーは、 決してあなたのアカウントではなく、そのテナントの予算しか燃やせません。 デニアル・オブ・ウォレットを参照。
model_limits（model_limits_enabled）をオンにし、そのテナントのプランに含まれる モデルだけをリストします — つまり漏洩したキーが、テナントが一度も支払っていない 高価なモデルを実行できないようにします。
environment（自由形式のデプロイラベル、例：prod / staging）を設定して、 テナントのトラフィックがあなたのログで帰属可能になり、本番キーとテストキーを 一目で見分けられるようにします。
テナントが固定サーバーから呼び出す場合は allow_ips をそのテナントのバックエンド egress IP に設定し、トライアルまたは期間限定のテナントには expired_time を設定 します（-1 = 無期限）。
すべてのテナントキーは、ワークスペースの tenant-baseline ガードレールとデフォルト ファイアウォールポリシーを自動的に継承します — あなたはスコープキーを発行し、それは 既に統制されています。キーは作成後に表示でマスクされるので、テナントをプロビジョン するときに一度だけコピーしてください。

​
4. テナントごとのオーバーライド — 残りに触れずに 1 つを締める

ほとんどのテナントはベースラインに乗ります。あるテナントがより多くを必要とするとき — 規制対象のテナント、エンタープライズ階層、保護観察リスト上のテナント — より厳格な 名前付きポリシーをそのキーのみにアタッチします：
キーに設定その 1 つのテナントへの効果
guardrail_idより厳格な名前付きガードレールに差し替える（例：PII でブロック）。
firewall_policy_idよりタイトなファイアウォールポリシーに差し替える（例：デフォルト deny ツール）。
解決は 2 つのプレーンで異なります — 違いを知ってください：
明示的な guardrail_id（存在し有効なとき）は常に適用され、決してサイレントに フォールバックしません。そのアタッチされたガードレールが無効なら、キーは ガードレールを持ちません — ワークスペースデフォルトには落ちません。 tenant-baseline デフォルトを継承するには guardrail_id を未設定（0/null）の ままにします。
アタッチされた firewall_policy_id は、存在し有効なときに適用されます；その ポリシーが無効なら、キーはワークスペースデフォルトファイアウォール ポリシーにフォールバックします。（これはガードレールのオフスイッチの挙動とは 逆です — 設計どおりです。）
名前付きポリシーを編集すると、次の呼び出しでそれにアタッチされたすべてのキーが シフトします。複数のテナントが 1 つのより厳格なポリシーを共有していると、編集は 一度にそのすべてに当たります。テナントが本当に異なるルールを必要とするときは、1 つの 巨大な共有ポリシーではなく、分離クラスごとに異なる名前付きポリシーを使ってください。

​
5. 具体的な 2 階層の例

1 つのワークスペースで無料階層と規制対象のエンタープライズ階層を運用するとします：
  1. ワークスペースベースライン — tenant-baseline ガードレール（入力で PII マスク、 カード/SSN でブロック）を is_default として、加えて balanced ファイアウォール 自律性レベル。すべてのテナントがこれを継承します。
  2. 無料階層テナントキー — guardrail_id なし（ベースラインを継承）、model_limits を openai/gpt-4o-mini に固定、低い credit_limit_usd。
  3. エンタープライズテナントキー — guardrail_id をより厳格な enterprise-pii ガードレールに設定（入力で PII block、mask ではなく；output ステージの secrets ブロック）、よりタイトなツール許可リストを持つ firewall_policy_id、より 高いクレジット上限、そして allow_ips を彼らのバックエンドに固定。
両方の階層は、自分のキーで同じ /v1/chat/completions エンドポイントを呼び出します。 ゲートウェイがキーごとに正しいポリシーを解決します — あなたのアプリケーションコードは すべてのテナントで同一です。

​
6. テナントごとのコンプライアンス & residency

規制対象のテナントは、しばしば他が必要としない証明を必要とします。コンプライアンスは、 ガードレールとファイアウォールのワークスペースピアとして実行されます：
  • フレームワークカタログとレディネスのブラウジングは任意の Member に開放され、 無料です — あるテナントが尋ねるフレームワーク（soc2、hipaa、gdpr、 iso_27001、pci_dss など）のカバレッジを確認します。
  • パックのインストール（POST /api/compliance/packs/:key/install）は、マッチする ガードレールとファイアウォールポリシーをあなたのワークスペースに具現化します； ワークスペース Admin と有料プランが必要です。
  • データ residency は、PUT /api/compliance/residency（Admin）経由で、 あなたのコンプライアンスレポートアーティファクトの地域（us / eu / uk / ap / cn / global）を固定します。地域横断的な読み取りは差し止められます。
ここでの residency はコンプライアンスレポートアーティファクトを統制するものであり、 推論データのジオ固定ではありません。リクエストログについて：ログはデフォルト 30 日 保持され（180 日でハードキャップ）、ユーザーの自己削除は 30 日の猶予を経て、その後 そのユーザーのガードレールマッチとリクエストログにカスケードする PII スクラブを 実行します。
完全に監査されたエビデンス実行については、 SOC 2 エビデンスを生成すると HIPAA 向けにデプロイするを参照してください。

​
7. すべてのテナントを 1 つのワークスペースから監視する

すべての可観測性はワークスペーススコープなので、1 セットのフィードがあなたの全テナントを カバーします — 単一のものまでフィルタ可能です：
  • Guardrails → Matches（任意の Member） — すべてのテナントにわたって発火した すべてのルール：type、action、stage、detail。マッチした部分文字列は、そのガードレールに 対して Log raw content がオンの場合にのみ記録されます（デフォルトはオフ — プライバシー保守的な姿勢、これがマルチテナントで最も重要です）。誤検出をマークして チューニングします（Admin）。
  • Firewall → Events / Runs（Developer+） — すべてのツール呼び出しを、 エージェント run ごとにロールアップ、つまり騒がしいテナントのループや新規の egress が 際立ちます。
  • 異常フィード（Member） — 学習された曜日内時間ベースラインに対して スコアリングされたレート／コストのスパイクが、各呼び出しが個別には許可される場合 でも、パターン外で燃やしている 1 つのテナントを捕捉します。
ブロックされたリクエストは HTTP 400（guardrail_blocked / firewall_blocked）を 返し、そのテナントのクォータを消費せず、skip-retry とマークされます — 境界は テナントに拒否を課金せずに保たれます。

​
8. さらに深く知るには

スコープキー、ポリシー、ワークスペース

キーアタッチメントとワークスペースデフォルトの完全な解決順序。

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

すべてのルールタイプ、PII エンティティ、エンティティごとのオーバーライドを完全に。

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

判定、サーフェス、自律性レベル、そしてポリシープレーン。

データ持ち出しを止める

テナントエージェントのアウトバウンド egress をロックダウンします。