アイデンティティ、分離、監査を標準搭載
4階層構造。JWT + OAuth 2.0。MFA。組み込み型AIを安全にするステップごとの認証分離。
Auth ManagerはAgent OSの信頼境界です。Administrator → Organization → Application → Userの4つの入れ子エンティティでアイデンティティをモデル化し、それぞれにスコープを持つRS256署名のJWTを発行します。オーケストレーターのステップごとの認証分離と組み合わせ、1つのAIが複数のテナントを安全に処理できるようにします。
4階層アイデンティティ
すべてのトークンが代表する階層を明示します。権限が誤って上昇することはありません。
ほとんどのAI統合が認証情報を漏らす理由
AI機能を静かにセキュリティインシデントに変える3つの失敗モード。
同じアクセストークンでスペシャリストを生成すると、1つのプロンプトインジェクションが全権限で動けるようになります。
誰がどのステップでどの副作用を引き起こしたか? 構造化された監査ログがないと、事後に答えられません。
OAuth、JWKS、MFA、ローテーション、リフレッシュ、監査 — 正しく構築するには、製品とは無関係な数か月の作業が必要です。
Auth Managerが行うこと
マルチテナントAIを既定で安全にする4つの保証。
4階層構造
Administrator → Organization → Application → User。各階層は独自のID形式、ログインモデル、権限スコープを持ち、階層をまたぐ誤った権限昇格は発生しません。
RS256 JWT + OAuth 2.0クライアントクレデンシャル
JWKSで検証鍵を公開。24時間オーバーラップする鍵ローテーション。他のAgent OSサービスは外部呼び出しなしで検証できます。
ステップごとの認証分離
オーケストレーターがステップをスペシャリストに渡すと、Auth Managerはそのステップに必要な範囲だけのトークンを発行します。1ステップが侵害されてもそのスコープしか失われません。
MFA、レート制限、完全な監査ログ
管理者向けのTOTP MFA。トークンごとのレート制限。発行・更新・失効・権限変更すべてがコンプライアンス監査のために記録されます。
3種類のトークン、1つの署名鍵
各トークンができることと、orgクレームを持つ条件。
| 種別 | 用途 | orgクレームを保持 |
|---|---|---|
admin |
管理操作 | なし |
app |
M2M APIアクセス (クライアントクレデンシャル) | あり — 組織名 |
user |
エンドユーザー認証 | あり — 組織名 |
Auth Managerの正直な比較
初日から得られる機能と代替案の比較。
| 機能 | Interactor Auth | ChatGPT / Cowork | ゼロから構築 |
|---|---|---|---|
| マルチテナントアイデンティティ | あり — 4階層 | シングルテナント | あり — 3か月以上 |
| ステップごとの認証分離 | あり — 範囲を狭めたトークン | 共有トークン | 3か月以上 |
| MFA + ローテーション内蔵 | TOTP、24時間オーバーラップ | プロバイダー任せ | 2か月以上 |
| トークン行動ごとの監査ログ | あり | 限定的 | あり — 慎重 |
| 安全なマルチテナント立ち上げまでの時間 | 数日 | 該当なし | 6か月以上 |
信頼モデルをお持ちください。マッピングします。
顧客・サブ組織・サービスが現在どう認証しているかを教えてください。Auth Managerがどう収まり、何を維持しなくてよくなるかをお見せします。
