Control Planeで育てるBtoB SaaSの認証基盤 - SRE NEXT 2026

by pokohide

Embed

Start on current slide

Slide 1

Slide 1 text

Control Planeで育てる、 BtoB SaaSの認証基盤 Dress Code株式会社 / Product & Technology ぽこひで〜認証基盤をControl Planeで多層に守り、AIエージェントと共生する〜

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© Dress Code Inc . 14.1億円　資金調達を実施 Pre Seed&Seed Round 250+社が利用中　 Number of companies Number of countries 5カ国で事業を展開　 Dress Code 会社概要 Company Name / 会社名 Dress Code 株式会社 2024年9月　正式創業：2025年4月 49名東京都中央区築地2-1-4 銀座PREX East 8F CEO / 代表取締役 Date of establishment / 設立年月 Location / 所在地江尻祐樹 Member / メンバー数 5

Slide 6

Slide 6 text

© Dress Code Inc . 挑戦する事業ドメイン/マーケット Asia To Global × Workforce Management 領域【Entry】入社/入場ライフサイクル【Retire】退職/退場採用管理労務管理人事/配置育成/定着福利厚生 ITツール/備品拠点/環境セキュリティ /ガバナンスプロジェクト外部人材活用 Dress Codeは、従業員の「入社から退職まで」をすべて管理するグローバル（まずはアジア）なワークフォースマネジメントプラットフォーム

Slide 7

Slide 7 text

© Dress Code Inc . デジタル化に伴う社会課題 - 「摩擦問題」 SaaS/ツール乱立に伴い、システムの分断・業務のサイロ化が進む  各業務担当者 ● ツールの乱立で、使いこなせない/慣れるまでに時間がかかる ● ツール/部門間のアナログ連携が大変 ● 担当間/部門間の摩擦が増大している  経営/管理部全体 ● 最適なSaaSを選定することが困難 ● データが散在していて利用/活用できない ● 連携/メンテのためのコスト(時間・お金)が膨大採用関連データ採用管理システム採用部門契約関連データ契約管理システム法務部門労務関連データ労務管理システム労務部門勤怠関連データ勤怠管理システム人事部門 SaaS関連データ情報システム部門デバイス関連データデバイス管理台帳総務部門 SaaS管理システム ❌ 分断 ❌ 分断 ❌ 分断 ❌ 分断 ❌ 分断

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© Dress Code Inc . Control PlaneとApplication Plane Control Plane 開設から認証・課金まで、テナントのライフサイクルを横断して管理するオンボーディングテナント開設・環境の用意認証・認可 — 今日の主役誰が・どのテナントで・どの操作まで許されるかテナント管理・課金・計測運営に必要な共通機能各テナントを開設・設定・管理 A 社のテナント A 社のユーザー・データ・設定だけを扱う B 社のテナント B 社のユーザー・データ・設定だけを扱う C 社のテナント C 社のユーザー・データ・設定だけを扱う Application Plane Application Planeの障害は1テナントに閉じるが、Control Planeは全テナントに波及する — 静的安定性の確保が課題

Slide 12

Slide 12 text

© Dress Code Inc . 創業期: Cognito + Lambda フロントエンド Amplify SDK ログイン／MFA ① 認証リクエスト Amazon Cognito User Pool ＋ Identity Pool ／ MFA・カスタム属性 ② 拡張処理（トークン発行直前） Lambda トリガー Pre Token Generation テナント情報をクレームに付与 Custom Message 認証コードメールを多言語生成 …ほか ③ テナント・組織情報の問い合わせ密結合の起点バックエンド API JWT を検証し、テナント・権限を解決 ④ 業務 API 呼び出し（JWT 付与）参照 DB テナント／組織／所属情報 B2Bの要件（SSO、ステップアップ認証、多言語、MFA）を足すたびに、Lambdaと自社DBへの作り込みが増える

Slide 13

Slide 13 text

© Dress Code Inc . Cognito運用で見えてきた要件とのギャップ ① 認証とアプリの密結合 TOTPシークレットやステップアップ認証を個別管理。認証とアプリが密結合に ② セキュリティを自社で担保ブルートフォース対策・不正検知・リスクベース認証まで自前。追い続ける負荷大 ③ 開発速度の低下 BtoBの当たり前品質の提供に開発リソースが溶け続ける ④ 開発体験と保守性 Lambda ＋ Cognitoはローカル再現が困難。機能追加に伴い1つのトリガーに責務が集中 ⑤ マルチテナント非対応単一テナント向けの基本設計。要件となるテナントごとのSSOやポリシー設定が困難実害も発生 MFA有効時にパスワードリセット不能に。手段と回復手段を分離できず解決困難運用トイルの増大と保守性の低下 — 認証基盤を根本から見直す判断へ

Slide 14

Slide 14 text

© Dress Code Inc . 移行先にOry Kratos (Self-Hosted)を選択戦略要件適合コスト運用負荷データ主権評価 A：Cognito-Hybrid 　不足分を自前開発低低中なし密結合・DX 悪化・セキュリティリスクがそのまま残る B：Kratos Self-Hosted 　 OSS を自社運用 ← 採用高低※ 高ありロックインなし。データを完全にコントロールできる C：自前実装　全部頑張る中データ主権は得られるが、実装・運用コストとリスクを負う D：IDaaS（Auth0）　全部アウトソース高高低なし MAU課金が「低頻度利用×一括オンボーディング」と不一致要件適合＝テナント別SSO・MFAと回復手段の分離・多言語等／ ※ 一部のエンタープライズ向け機能は Ory Enterprise License が必要運用負荷「高」を受け入れ、データ主権や要件適合を優先した選択高高あり

Slide 15

Slide 15 text

© Dress Code Inc . 採用した認証基盤「Ory Kratos」 Go製・オープンソースの認証・Identity 管理システム API-First ＆ヘッドレス — UI を一切持たず、認証のバックエンドロジックとデータ管理に特化 Self-Service Flow ユーザー自身で完結する操作を、安全な「一連の状態遷移」としてAPI 化ログイン登録設定変更アカウント回復メール検証認証手段はパスワード／パスワードレスコード／Passkey／MFA（TOTP 等）に標準対応。フローの前後に Webhook を差し込める厳密な状態管理セッション・CSRF・MFA の状態を Kratos が管理し、DB に集約柔軟な Identity モデル JSON Schemaで属性・ログイン識別子を自由に定義シンプルな構成単一の静的バイナリで、外部依存は RDBMSだけ。インフラ運用が比較的楽

Slide 16

Slide 16 text

© Dress Code Inc . 認証基盤をOry Kratosに完全移行 AWS Cloud VPC Public subnet Private subnet Isolated subnet  利用者 WAF CloudFront Public ALB NAT Gateway Ory Kratos Public API / Admin API Courier メール配信等 Internal ALB Aurora PostgreSQL SG で接続元を限定 Route 53 PHZ Backend API 同一 VPC・Private subnet SQS Lambda Webhook 監査ログ基盤（S3）

Slide 17

Slide 17 text

© Dress Code Inc . 認証情報の移行前提: Cognitoはパスワードハッシュをエクスポートできないため、認証情報は「そのまま」持ち出せない Just-in-Time 移行ログイン時に旧基盤で検証し、成功したら新基盤に再ハッシュして取り込む ◯ ユーザー影響ゼロ ✕ 全員ログインまで未完了ダブルライト＋並行稼働登録・変更を新旧両方に書き込み、データが揃ったところで段階的に切り替える ◯ 切替リスクを分散できる ✕ 二重運用が長期化一括移行＋再設定案内 Identityを一括インポートし、認証情報はユーザー個別に再設定してもらう方式 ◯ 二重運用がほぼゼロ・短期完了 ✕ 全ユーザーに再設定負荷正式創業から約半年でアクティブ利用が限定的＝再設定の負担が最小の時期と判断。現在の「事業フェーズ」に最適な移行戦略を選択しました。採用

Slide 18

Slide 18 text

© Dress Code Inc . 「Ory Hydra」も導入 Go製・オープンソースのOAuth2 / OIDC 認可サーバー API-First ＆ヘッドレス — UI を一切持たず、認可トークンの発行と検証に特化 OAuth2/OIDC 準拠のトークンフローを標準装備 — セキュアな認可の仕組みをゼロから実装せずに持てるアクセストークンの発行クライアント管理同意フロー JWKS公開・検証認証はそのものは持たず（Kratosに委ねる）認可トークンの発行に専念分離設計認証と認可の責務を切り離すことで、システム全体の堅牢性と保守性を向上。運用の横展開 Kratosのセルフホストのインフラ構成を再利用。ステートレスな実行基盤、および監視・ログ仕組みをそのまま横展開。 AIエージェントへの布石 RFCに完全準拠した強力なトークンフローを自社チームのコントロール下に配置。

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© Dress Code Inc . 全てのリクエストが認証基盤を通る Ory Kratos はセッションを DB で管理する（ステートフル） — 検証も毎回、照会になる Application Plane ユーザー IT Force HR Force GA Force … ログインセッション検証 — 毎回 Control Plane Ory Kratos 認証DB Kratos が止まると、ログイン済みユーザーの操作もすべて止まる — 事実上の単一障害点

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© Dress Code Inc . Proxyを挟み、検証を自己完結にユーザーセッション Oathkeeper Proxy：セッションを検証し JWT へ変換短命 JWT バックエンド JWT を手元で検証セッションの検証はApplication Plane内で自己完結セッション照会はここだけ Ory Kratos 発行・管理に専念プロダクトからの毎回の照会が消える効果落ちても、止まるのは新規ログインだけトレードオフ失効の即時性可用性と即時失効は同時に最大化できない — どこまで許容するかが設計判断

Slide 23

Slide 23 text

© Dress Code Inc . ステートフルなDB プロダクト Load Balancer AZ-a Kratos Hydra AZ-c Kratos Hydra 状態はすべてここへ認証DB 認証基盤の信頼性は、「DB をどう守るか」にフォーカスできる 1. 状態はDBに集中セッションの正は認証DBの責務 2. プロセスは使い捨て可能水平スケール・ローリング更新・マルチAZ配信 3. 信頼性の勝負所はDBの1箇所守る対象を明確にする

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© Dress Code Inc . 信頼性の計測 ECS タスク Kratos / Hydra Datadog Agent ↓ OTLP Datadog — 認証系ダッシュボードトレードオフの影響も計測で確かめながら、「止まるのは新規ログインだけ」の状態へ 1. DD Agentの導入各タスクからOTLPでメトリクス収集 2. 認証のSLIを監視認証成功率・p95/p99レイテンシ・5xx率 3. 信頼性の勝負所はDBの1箇所守る対象を明確にする

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© Dress Code Inc . DRESS CODEのControl Planeの位置付け運用者 Control Plane DRESS CODE Admin 社内運用者向け Web UI / BFF 管理 API Backend の admin モジュール認証基盤 Ory Kratos ＋ Hydra 閉域ネットワーク Internal ALB・SG 全テナントを横断して運用・管理テナント開設・停止／プラン・課金・計測／ ID 運用／ CS オペレーション支援／運用者管理・監査 Application Plane IT Force HR Force GA Force … 運用者向けのUI(Admin)、API、認証基盤、ネットワーク全体を定義

Slide 28

Slide 28 text

© Dress Code Inc . Control Planeのアーキテクチャ運用者 VPC PUBLIC SUBNET Admin ALB Google OIDC PRIVATE SUBNET Admin Next.js SSR / BFF Internal ALB SG 間許可のみ Ory Kratos 認証基盤 Backend API ISOLATED SUBNET DB 状態の集約先 M2M この構成を ① インフラ／ ② BFF ／ ③ バックエンドの3層に分けて、どう守っているかを見ていく Adminをハブに認証基盤とバックエンドは内部完結させる AWS WAF

Slide 29

Slide 29 text

© Dress Code Inc . 3層の検証・権限の分離 ① インフラ到達経路を縛る WAF ＋ OIDC 終端＋閉域化 ② BFF ALB を信じ切らない薄いプロキシ＋ JWT 再検証 ③ バックエンド特別扱いを作らない操作範囲をテナントに強制＋権限で縛る（全層を横断）認可の SSoT は Google Workspace OU × Role - WIF連携で静的クレデンシャルを持たず AWS の強権限はロールごと分離特権は必要なときだけ AssumeRole で借りる各層が同じ仮定に依存しない — 1つ破られても、次の層で止まるリクエストが通る3つの層を独立に検証し、権限で縛る

Slide 30

Slide 30 text

© Dress Code Inc . ① インフラ - 到達経路を物理的に縛る運用者同一 VPC Admin ALB Google OIDC 必須 PRIVATE SUBNET Admin ECS(BFF) Internal ALB SG 間許可のみ Ory Kratos 認証基盤 Backend API すべて Internal ALB 経由入口で人を縛る Admin ALB は Google OIDC 必須 — 社内アカウント以外は到達できないサービス間も閉域 Internal ALB ＋ SG ＋ Private Hosted Zone でVPC 内に完結インターネットに出ない公開 ALB は CloudFront 限定 — 管理経路が物理的に存在しない AWS WAF

Slide 31

Slide 31 text

© Dress Code Inc . ② BFF - 薄く保ち、検証を省かない STEP 1 ALB Google OIDC を終端し、署名付きトークンを付与 STEP 2 ミドルウェアトークンを再検証（署名・発行者・社内ドメイン・有効期限） STEP 3 ページ・API 認可ポリシーを各層で独立に評価 STEP 4 Backend 呼び出し M2M トークンを付与して内部経路へ独自 DB を持たない状態を持つと SSoT の分裂・トークン漏れの隙になる Backend とKratos への薄いプロキシに徹する認可の SSoT は Google Workspace OU × Role WIF連携で静的クレデンシャルを持たず、権限が自動追従

Slide 32

Slide 32 text

© Dress Code Inc . ③ バックエンド - Contextで閉じる Application Plane 通常 API ユーザーセッションを検証 Context を注入自テナントのスコープ Control Plane Admin API DRESS CODE Admin M2M 認証 Contextを外から注入対象テナントを指定同じ Force のユースケースへ処理は Context のスコープに閉じるドメインのロジックは Force 配下 — Admin の Controller は Force が公開する Adapter I/F にだけ依存違いは Context の注入元だけ — Admin 専用の広いスコープ・専用ルートを作らない全ての処理にContextを与え、テナントに閉じたリクエストしか行わせない

Slide 33

Slide 33 text

© Dress Code Inc . 強権限はIAMロールで分離する Application Plane 通常 API 各 Force のユースケース Backend タスクロール普段のロールデータ操作のみ Control Plane テナント開設・削除 AssumeRole Control Plane 専用ロール対象テナントに限定・短命セッション特権操作テナント専用の KMS 鍵・機密データ用 S3の作成・削除 ECS ごと分ける選択肢もあるが、各環境1系統のシンプルさを保ち IAM ロールの境界で分離一般 API が侵害されても、IAM レベルで特権操作に届かない

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© Dress Code Inc . 監査ログを取る事後調査起きたことを再構成できるインシデント時、影響範囲を証跡から特定する。記録がなければ調査は推測になる「誰が・いつ・何を」を操作した本人が否認できない記録を残す。社内統制の土台顧客と監査人に示せるエンタープライズのセキュリティレビューやSOC 2・ISMS は、ログの提示が前提強権限が全テナントに及ぶ Control Plane は、操作を追えて初めて成立する多層で守っても、正規の操作は起きる説明責任信頼の証明

Slide 37

Slide 37 text

© Dress Code Inc . 監査ログをどう集めるか DRESS CODE の内側 DRESS CODE の外側組織のリソースへの操作 Operation Activity 業務・管理・特権操作 Backend の各 Force が記録対象外外部 SaaS 内の組織リソース操作は、各 SaaS の監査ログの領分個人の本人性・行動 Identity Audit ログイン・MFA・セッション発行認証基盤が記録 Accesses 外部 SaaS・デバイスへのアクセス GWS 監査ログ・Chrome 拡張・MDM 連携「組織のリソースか、個人の本人性か」と「DRESS CODEの内外」の4事象で考える

Slide 38

Slide 38 text

© Dress Code Inc . 生ログはS3をSSoTに - 表示・分析は派生させる Outbox Pattern 業務 DB 同一トランザクション業務テーブル操作を書き込み＋ Outboxテーブルイベントを追記リレー Outboxを読み出し SNS へ発行 SNS Firehose S3 ＝ SSoT 生イベント・不変 Object Lock（WORM） 7年保持・KMS 暗号化組織×日付パーティション派生① Read Model 画面表示用 - Rehydrate可能派生② Glue ＋ Athena 正規化して分析・検知クエリへ証跡と分析は分ける - 正規化・dedupを経たデータは証跡にならない Backendの各Force 業務・管理・特権操作

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© Dress Code Inc . なぜ、AIエージェントの話をするのかコアDBを徹底する — 構造化されたデータ全プロダクトが単一の正を共有。カスタム項目を作らないから、データの意味が組織ごとにブレない Operation Engine — 標準化された業務入社・異動などの業務プロセスを、最初から Operation Engineの手続きとして標準化後発だからこそプロダクトの構造で先回りして整備してきた

Slide 41

Slide 41 text

© Dress Code Inc . AIエージェントの責務はControl Planeと重なる ● ● ● AIエージェントの業務はテナントに閉じないエージェントに負わせる責務 → Control Plane の性質そのもの統治を新しく発明せず、設計済みの Control Plane を拡張して共生する ● 判断を伴う実行まで担う ● テナントを横断してデータに作用する ● 無人で動き続ける ● 全テナントのデータに触れる ● 強い権限で、テナントを越えて動く ● 人間と同等以上の統治が要る

Slide 42

Slide 42 text

Slide 43

Slide 43 text

各社のエージェントとの共生の考え Microsoft 主要プレイヤーの統治のアプローチのまとめ OpenAI AWS Okta Ory

Slide 44

Slide 44 text

© Dress Code Inc . Microsoft - エージェントを従業員として統治する中心概念 ID エージェントに、人間と同列の ID を与えるエージェントは「もう一人の従業員」— 人事と同じ仕組みで統治する ● Entra Agent ID エージェント1体ごとにIDを発行し、人間と同様に条件付きアクセス・リスク検知・ライフサイクル管理を適用 ● Sponsorship 全エージェントに人間の責任者を必須化。異動・退職時はワークフローで自動移管 ● Agent 365 全エージェントの発見・管理・保護を1箇所に集約

Slide 45

Slide 45 text

© Dress Code Inc . Google - 経路と実行時の文脈で統治する中心概念 Context 全通信を1つの統治プレーンに集約するネットワークがガードレール — 人事と全通信を統治プレーン経由に強制する ● Agent Gateway エージェントの通信の入り口・出口を1点に集約 ● Agent Identity + IAMを実行時検証エージェント個体にmTLS保護のID。ツール単位のIAM権限をゲートウェイで検証 ● Model Armor - 経路上のコンテンツ検知 Prompt Injection・データ漏洩を通信経路で検査・ブロック

Slide 46

Slide 46 text

© Dress Code Inc . OpenAI - ツールとの接続点で統治する中心概念 Tool エージェントが触れるツールとデータを絞る何に触れられるかを絞る — ツールの管理が統治の中心 ● MCP 接続標準を中立で立て共同統治 ● Connector Registry エージェントに触れるデータソース・ツールを一元管理 ● Guardrails + Human-in-the-loop ガードレール層(P IIマスク・jailbreak検知）副作用ある呼び出しは一時停止し人間の承認を求める

Slide 47

Slide 47 text

© Dress Code Inc . AWS - 実行環境ごとに隔離する中心概念 Infra 実行環境そのものを隔離する暴走しても問題ないように、実行基盤そのものを隔離する ● AgentCore Runtime セッションごとに専用microVMを割当て、CPU・メモリ・ファイルシステムを完全隔離 ● AgentCore Identity エージェント個体にIDを発行。入り口はOAuth/IAMで検証 ● Bedrock Guardrails 入力・出力・行動をインフラ側のポリシーで制御

Slide 48

Slide 48 text

© Dress Code Inc . Okta - IdPをエージェント接続の管制塔にする中心概念 IdP 接続の認可をIdPに集約する接続の認可をIdPに集約 — ゼロタッチと統制を両立する ● Cross App Access - XAA OAuth拡張のオープンプロトコル。エージェントの認可をIdP で一元管理・自動化する ● 組織単位での認可管理者がコネクタを一度認可すれば全社員に適用 ● 接続の一元可視化誰がどのAIで何に繋いだかをIdPで一元可視化

Slide 49

Slide 49 text

© Dress Code Inc . Ory - 静的なキーを短命なトークンに置き換える中心概念 Token 権限をトークンそのものに刻んで絞る権限をトークンに刻む — 絞ることはできても広げることはできない ● 静的APIキーを、動的トークンへ - Ory Talos 長寿命な親キーから短命・最小権限な子トークンを都度派生。親を失効すれば下流の子トークンも即座に無効化 ● Macaroonベースの移譲サブエージェントに渡す際の制約を暗号的に追加し縮小させていく。Google主導の認証・権限管理トークン ● エージェントもIdentityの一員に AIエージェントにIDを付与し、同じ基盤で管理する

Slide 50

Slide 50 text

© Dress Code Inc . エージェント統治をどこに実装するか Microsoft ID AIエージェントを従業員と同列のIDとして統治する IDを与え、権限を絞り、証跡を残すという統治のアプローチは共通 AWS Infra セッション単位のmicroVM で実行環境を隔離 Google Context 全通信を統治プレーンに集約し、実行時にIAMを検証 OpenAI Tool エージェントが触れるツール・データを管理 Okta IdP 接続の認可・失効・可視化をIdPで一元管理 Ory Token 静的APIキーを短命・最小権限トークンに置き換える

Slide 51

Slide 51 text

© Dress Code Inc . 標準はどこに向かうか - draft-klrc-aiagent-auth エージェント=ワークロードエージェント専用の仕組みを発明せず、サービスと同じワークロード新しいプロトコルを発明せず、既存標準の組み合わせで統治するクレデンシャルは短命・実行時発行自動ローテーション前提。静的APIキーはアンチパターンと明記認可はOAuth2.0の移譲に乗せるトークンに個体(client_id)と移譲元(sub) を分けて刻む。高リスク操作は人の承認へ個体をURIで一意に識別エージェントごとにIDを一つ割当て、認証・認可・監査・移譲全ての基準にする IETFの議論中ドラフト https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/

Slide 52

Slide 52 text

Slide 53

Slide 53 text

© Dress Code Inc . エージェント統治に必要なものはControl Planeにあるエージェント統治に必要なもの個体の識別誰であるか ↓ ↓ ↓ Control Plane Identity Control Plane Kratos ＋ Hydra ゼロから発明しない — 人間向けの Control Plane を「拡張」して共生する行動と許可の制限何を許すか行動の証跡実際に何をしたか多層の検証 x 権限の分離 BFF / バックエンド / IAM 監査ログ基盤 Operation Activtiy

Slide 54

Slide 54 text

© Dress Code Inc . エージェントを個体として管理するいまの信頼モデル呼び出し元は Admin 1つ共有シークレットの M2M → 個体単位の ID ＋短命トークン＋誰の代理かを保持 Agent ID どの個体か — 識別の単位を「アプリ」から「エージェント個体」へ Agent Registry 名前・用途・許可スコープ・状態を台帳で管理 Owner 人間の責任者を必須に — 退職・異動時は停止か移管権限・責任・証跡を、エージェント個体に紐づける目指す設計

Slide 55

Slide 55 text

Slide 56

Slide 56 text

© Dress Code Inc . RFC 8693 Token Exchange 交換前ユーザーのトークン sub ＝ユーザー本人。これをそのまま渡すと、本人の全権限ごと渡ってしまう Token Exchange → 認可サーバで交換交換後委任トークン＝OBO(On-Behalf-Of) sub 委任元のユーザー — 誰の代理か act 実行体のエージェント — どの個体か scope ユーザー権限の subset に絞る exp 短命 — 使い終わったら消える元の認証情報を渡さない権限を、必要な範囲だけに絞れる「誰の代理で・どの個体が」が残るトークンを「委任のかたち」に交換して渡す — これが OBO トークン手元のトークンを別のトークンに交換するOAuth2の標準拡張

Slide 57

Slide 57 text

Slide 58

Slide 58 text

© Dress Code Inc . 同じ土俵、違いはトークンだけ人間の運用者認証基盤のセッション AI エージェント短命の委任トークン sub＝委任元／ act＝実行体業務 API 同じエンドポイント権限チェック同じ Context 強制監査ログ委任元＋実行体を記録危険な操作は人の承認入口で渡すものは違うがその先の検証・記録・統治はすべて共通違いは入口の1行だけ — だから人間向けの統治が、そのまま効く人間と同じ経路を通し、制約はより厳しく（短命トークン、権限サブセット、責任者必須）

Slide 59

Slide 59 text

© Dress Code Inc . 拡張① - OBO + Token Valut OBO トークン (RFC 8693 互換) sub 委任元のユーザー act 実行体のエージェント個体 scope ユーザー権限のsubsetのみ exp 最大 15 分・Refresh なし「誰の代理で・どの個体が・何を・いつまで」がトークンだけで完結する scope は「用途 × 委任元」の積集合事前定義した用途の範囲と、ユーザー権限の重なりだけを渡す再委譲は禁止（depth=1） jti の失効チェックで即時取り消し。発行も失効も Control Planeに集約外部 SaaS のトークンは Token Vault に隔離エージェント本体にクレデンシャルを渡さない渡すのは権限そのものではなく — 期限と範囲を刻んだ、1枚の短命トークン

Slide 60

Slide 60 text

© Dress Code Inc . 拡張② - 危険な操作にだけ、人の承認を挟む顧客への成代わり隔離して実行関門：検証＋承認＋隔離破壊的・テナント横断の操作非同期の人の承認関門：検証＋人の承認ほとんどの操作自律で実行関門：トークン検証と監査のみ read-only・時限つきの隔離実行環境特に重い操作は、環境ごと閉じ込める APIは202で保留→通知→承認後に実行非同期 Human-in-the-loop で承認疲れを防ぐ短命 OBO トークンのまま流す監査ログ・スコープ強制は全操作に適用承認フローは共通基盤のOperation Engineの承認タスクに載せる

Slide 61

Slide 61 text

© Dress Code Inc . DRESS CODEでのAIエージェントとの共生 1 個体として識別する Agent ID を台帳で管理 — 責任者のいない個体はない 2 常に誰かの代理で動かす sub／act の委任トークン — 都度発行（depth=1） 3 人間と同じ経路・同じ統治裏口を作らない — 危険な操作だけ、人の承認専用の統治を新規発明しない。ヒトのために建てたControl Planeの「延長」で実現する

Slide 62

Slide 62 text

© Dress Code Inc . 補足：多段移譲の標準化 ① 委譲の経緯を、検証できる形で残すユーザー → Agent A → Agent B ↓ トークン内の delegation_chain ① ユーザー → Agent A 認可サーバの署名 ② Agent A → Agent B 認可サーバの署名署名付きレコードが積み上がる API 側で、チェーン全体を検証できる ② 権限を、暗号的に減衰させて渡す親トークン読取更新削除 → 削除 → 親トークンから、暗号的に権限を削った子トークンを派生認可サーバに問い合わせない手元のトークンから絞って渡せる（オフライン） https://datatracker.ietf.org/doc/draft- liu-oauth-chain-delegation/ IETF: draft-liu-oauth-chain-delegation IETF: draft-niyikiza-oauth-attenuating-agent-tokens（AATs）子トークン孫トークン読取更新削除読取更新

Slide 63

Slide 63 text

Slide 64

Slide 64 text

© Dress Code Inc . まとめ拡張 AIエージェントとの共生エージェントも、同じ Control Plane に載る OBO - 常に誰かの代理危険な操作は、人の承認 ▲ 延長 ▲ 実践 Control Planeを支える信頼性静的安定性・SLI で支える多層防御各層で独立に検証して守る監査ログ Outbox→S3(SSoT)で証跡に ▲ ▲ 土台 SaaS の設計思想 Control Plane 認証基盤はここに — 統治を作り込む Application Plane ヒトのために建てたControl Planeの延長に、エージェントが載る Agentを個体とし識別