Bet AI Day 2026 AI Agents at Work Fintech / Security AIによって本質に戻る システムリスク管理 鈴木 研吾 Kengo Suzuki 16:20-16:40 

Speaker Information 鈴⽊ 研吾 Kengo Suzuki カリフォルニア⼤学バークレー校⼤学院修了。 証券会社向けのManaged Security Serviceに従事。 その後、Fintech系スタートアップにて Mobileアプリ開発、社内システム、サービス環境インフラを セキュリティの観点から担当。 ゼロトラストネットワークの国内第⼀⼈者。 他に、セキュリティキャンプ全国⼤会の講師や セキュリティ系同⼈誌「Secure旅団」の主催など広く活動している。 LayerX Fintech事業部では主にシステムリスク管理を担当 194 

Agenda Chapter 1 AIエージェント活⽤に伴うシステムリスク現状 Chapter 2 AIエージェントの作⽤可能範囲を制御する Chapter 3 ゼロトラストを基にしたシステムリスク管理 

AIエージェントへの委任範囲 リスクのスケール x 新規技術による継続的且つ 急速な変化 - そもそもシステムリスク管理はシステム化に伴うアップサイド とダウンサイドの最適化にある - AIエージェントは業務の恩恵を拡⼤する⼀⽅、誤作動‧逸脱‧ 侵害時のリスクと影響範囲も拡⼤する - 特に昨今では、「⾃社システムから外部へ及ぼす作⽤ （Outbound Risk）」による第三者環境への侵害や、 実世界への⾮許可⾏動が顕在化している - モデルへの指⽰やエージェント内部の制御だけでなく、権限‧ 到達範囲‧実⾏環境を、外側から制約する仕組みが必要 - エージェントの開発‧運⽤する主体とは別のレイヤーで、その 境界を設計‧強制する。これは既存のフレームワークを拡張 し、統合したほうがいい https://www.smtam.jp/guide/management/risk/ 196 

Chapter 1 AIエージェント活⽤に伴う システムリスク現状 

AIの業務利⽤‧攻撃利⽤‧事故は、すでに数字に表れている 81% 組織がManaged AI Servicesを利⽤（Wiz 2026）。AIはクラウド‧開発‧業務 ワークフローに組み込まれ、周辺システムの⼀部になっている。 57% 組織がSelf-hosted AI Agentsを展開（Wiz 2026）。AIツールやAI開発基盤 そのものも攻撃対象になり、業務利⽤時の事故‧悪⽤も観測されている。 89% AI-enabled adversaryの攻撃増加（CrowdStrike 2026）。攻撃側でも 偵察‧認証情報窃取‧回避‧ソーシャルエンジニアリングにAIが使われている。 8× Critical‧Highな脆弱性が、303 -> 2514に（Epoc AI）。 29min / 4× 平均eCrime breakout time 29分（CrowdStrike 2026）。最速攻撃の初期 アクセスから窃取までは前年⽐4x（Unit 42 2026）。AIは攻撃速度‧攻撃 ⾯‧事故の影響範囲も変える。 

外部からAIエージェントを活⽤した「速く‧広く‧巧妙」なリスク InboundなRiskに関する変遷 時間軸 発⾒から悪⽤までが短縮。 平均eCrime breakout timeは29分、最速27秒という観測が出ている。 探索範囲 管理画⾯ / API / SaaS / ID / 依存関係まで拡⼤。 AIにより偵察‧探索‧スクリプト作成‧トラブルシュートが簡易になる。 攻撃の質 相⼿に合わせた誘導‧⽂⾯⽣成‧迂回⼿段が増える。フィッシング、ソーシャル エンジニアリング、偽装、認証情報窃取がAIで最適化される。 対象拡⼤ AIシステム⾃体も攻撃対象となり、プロンプト注⼊やAI開発基盤の悪⽤が観測 されている。Inboundでは、時間軸‧カバレッジ‧巧妙さが同時に変化する。 

Outbound Risk：AIエージェントが第三者に害を与えるリスク 指⽰者の意図しない形で、明らかな第三者に対する侵害⾏為を実⾏する恐れがある。 法的責任の所在は未確定でも、外部へ被害を出すというマイナスのアウトカムは同じ。 ⾃社側の⾒え⽅ 第三者側の⾒え⽅ 業務⾃動化の失敗 評価タスクの逸脱 AIエージェントの作業 ミス 不正アクセス 悪性PR / フィッシング データ窃取‧破壊の試 ⾏ 故意であろうとなかろうと、 正常に動く⾃社システムが 加害主体になり得る可能性が 増した 200 

Outbound事例①：UK / AISI事例 サンドボックス 回避ではなく、 評価⽬的で許可されたインターネットアクセスを経由して 第三者への作⽤に使われた ● 122回の評価のうち10回で、 合計19件の実世界への⾮許可⾏動を確認 ● 実在OSSへ悪性コードを含むPRを作成 ● 偽アカウントを作成し、 メンテナへのsocial engineeringを試⾏ ● プロンプトインジェクションの埋め込みや、 他エージェントとの協働を⽰唆する⾏動も観測 ●（個⼈的な感想）プロンプトがそもそもアグレッシブ な状態でインターネットアクセス 許可されたInternet access ↓ Malicious PR ↓ Fake Identity ↓ Social Engineering ↓ Human / Other Agents アプリ‧インフラともに⼗分な管理が必要 出典：OpenAI / Hugging Face incident reports（2026） 201 

Outbound事例②：OpenAI / Hugging Faceのケース 「⽬標達成のための経路探索」による 評価環境の脱獄 ●エージェントは外部へのアクセスが本来のスコープと異なる ことをしりながら、 評価⽬標の達成に向け、様々な侵⼊⼿法 でHugging Face本番環境まで到達 ●エージェントは「チート⾏為」を認識しつつ、システムログ の削除も試みていた ●本番環境で使われているセーフガードやシステムプロンプ ト、⾃動レビュー機能などがオフにされた状態 ●セキュリティ監視システムは、評価環境における異常なAPI 呼び出しや権限昇格を検知していた 構成 評価環境 直接Internetなし ↓ Artifactory 0-day ────────────── 実際の経路 Internet到達可能なNode ↓ Hugging Face Production 開発環境‧本番環境で同⼀のポリシーと、濃淡のあるEnforcement（施⾏）の分離 出典：OpenAI / Hugging Face incident reports（2026） 202 

Outbound事例③：Meta社 AIサポートに指⽰することでアカウント乗っ取り ● AIサポートチャットに、被害者アカウントのパスワードリセットリンクを 攻撃者のメアドに送るよう指⽰ ● 20,225アカウントが影響を受けた ● ２要素認証済みのアカウントはパスワードリセットはされたものの、乗っ取られず 多層防御の徹底 出典：OpenAI / Hugging Face incident reports（2026） 203 

エージェントの確率的挙動に対応するための管理が必要 3つの事例が⽰すのは、エージェント内部の指⽰だけでは「作⽤可能範囲」を境界として 強制できないということ UK AISI ラフなプロンプトでラフな経路 によってエージェントが 第三者へ作⽤ OpenAI / Hugging Face Meta エージェントが脆弱性と接続関係を 探索し、到達範囲を⾃ら拡張し、侵害 脆弱なアプリとしてのエー ジェントを悪⽤され、利⽤者 のアカウントを第三者に譲渡 エージェント内部の制御は、望ましい⾏動の確率を⾼める。 しかし、想定外⾏動時の被害上限は、 エージェントの運⽤管理から独⽴した⽅法で境界を引く必要がある ⼗分な管理ポリシーと、⽬的に応じた適⽤（エンフォース）、これらの多層的な運⽤管理の独⽴が必要 Identity / IAM / Sandbox / Network‧DNS / Egress / Secrets / Monitoring‧Containment 204 

Question では、AIエージェントの何を、 誰が、どこで制御するのか？ 

Chapter 2 AIエージェントの 作⽤可能範囲を制御する 

システムに対するInboundリスク評価 そこそこガイドライン化が進んできている Asset Exposure KEV Status Exploit Automation Technical Impact 外部から到達可能か。 CISA BOD 26-04は、 CVSSのSeverityだけ でなく、資産‧露出‧ 悪⽤状況‧⾃動化可能 性‧影響で優先順 付 けする⽅向を⽰す。 既知悪⽤か。脆弱性単 体ではなく、その脆弱 性がどの資産にあり、 どこから到達可能で、 何を可能にするかを⾒ る。 ⾃動悪⽤可能か。AI エージェント時代に は、この⽂脈評価を資 産‧権限‧到達可能性 ‧業務影響‧Agentの 活動範囲まで拡張す る。 完全制御へ⾄るか。脆 弱性情報を待つだけで なく、⾃社の接続関係 ‧業務影響で判断す る。ここから先は、分 断されたデータをシス テムリスク判断へ統合 する話になる。 しかしシステムリスク管理にはOutboundなリスクも 含めて、対処する必要がある 207 

AIエージェントに作⽤する変数を、4つの観点で分解 全体のシステムリスクを、AIエージェント特有の性質と、従来のシステム上で制御できる性質に分けて整 理し、組織構成、業界標準、ソリューションを踏まえ、TO BEとTODOを洗い出し、対処する必要がある ど 資源にど Actionを許すか 主にIdentity / IAM / Delegationで制御 (Identity) 何を理解・生成・実行できるか 主にモデル・ツール選定で制御 (Capability) AIエージェント （外的環境に 作用を及ぼす主体） 人を介さず何分・何回・何ステップ動くか 主にタスク設計・実行時間で制御 (Autonomy) ど Network / DNS / Data / Toolへ到達できるか 主に実行環境で制御 (Reachability / Sandbox) ※括弧内 個人的な仮称 208 

誰が何を制御するか？ 全体のシステムリスクを、AIエージェント特有の性質と、従来のシステム上で制御できる性質に分けて整 理し、組織構成、業界標準、ソリューションを踏まえ、TO BEとTODOを洗い出し、対処する必要がある ど 資源にど Actionを許すか 主にIdentity / IAM / Delegationで制御 (Identity) 何を理解・生成・実行できるか 主にモデル・ツール選定で制御 (Capability) 各開発部署・プロジェクト・ チームが判断することになりそ うだが、ど ような制御が必要 かガイドライン化が必要 人を介さず何分・何回・何ステップ動くか 主にタスク設計・実行時間で制御 (Autonomy) AIエージェント （外的環境に 分離 作用を及ぼす主体） Fintech事業部だと、担当部署・ チーム 一部署に絞られていて、明 確 ど Network / DNS / Data / Toolへ到達できるか 主に実行環境で制御 (Reachability / Sandbox) ※括弧内 個人的な仮称 209 

誰が何を制御するか？ 全体のシステムリスクを、AIエージェント特有の性質と、従来のシステム上で制御できる性質に分けて整 理し、組織構成、業界標準、ソリューションを踏まえ、TO BEとTODOを洗い出し、対処する必要がある 横断チームが 続々とでてくる新標準・規格 確認と反映？ そ 標準をど 程度、反映する？ 各チームと 合意 ？ AIエージェント ど 資源にど Actionを許すか 主にIdentity / IAM / Delegationで制御 (Identity) （外的環境に 作用を及ぼす主体） 横断チーム？が ど ポリシーを、ど 環境で、ど 程度、 強制・Enforceする か、そ granular な制御を可 能とする仕組み 構築、 現状から劣後しないため 移行計画、 現状 ソリューション 仕様確認 各チームと 合意 ？ ど Network / DNS / Data / Toolへ到達できるか 主に実行環境で制御 (Reachability / Sandbox) ※括弧内 個人的な仮称 210 

全体的なシステムリスクにあたってはまだまだ不⾜ ● 新しい⽤語は増えるが、責任主体と強制点が曖昧 ● Outboundなリスクや、そのリスクにつながるような 侵⼊‧内部不正を前提にした標準整備はどの組織もこれから ● ハーネスエンジニアリングについてAI開発周辺ではある程度、統⼀がされてきているように⾒えるが、 対処可能なリスクとのマッピング、標準業界に合わせた定義、役割分担、耐⽤年数も未知数 ● 規制‧監督側は追いついていない ● （個⼈的にも）追いつけてると⾃信をもって⾔えない ● 既存組織への当てはめ、既定とされる業界標準への統合も未整備な状態 AIエージェント先駆者界隈の提唱内容と、既存概念と既存組織のすり合わせが必要 211 

個別に語られる対策を、 既存のフレームワークを拡張し 統合する 

Chapter 3 ⼈も、端末も、AIも。 そもそも信頼しないのが システムリスク管理 

Zero Trust: Don’t Trust Verify 「外部/内部を問わず脅威が存在するといった前提に⽴ち、ユーザー、デバイスなど個々のID（Digital Identity）に焦点を当て、「都度必要なアクションに対して必要なレベルの認証を⾏い、問題なければ適切な アクセス権を認可する」といった検証を厳密に⾏うことで、 セキュリティを担保し、且つ柔軟なUser Experienceを実現するといった概念」by デジタル庁 ※disclaimer: 私⾃⾝が作成に関わっています ユーザーID管理 ディレクトリサービス 常時リスク診断情報 資産インベントリ 観測情報 アクセス制御 管理機能 端末構成情報 PKI アクセス制御結果 適用 脅威情報 アクセス制御ポリシー デジタル化した業務プロセス 主体 アクセス 制御 施行 リソース A アクセス 制御 施行 リソース B アクセス 制御 施行 リソース Y アクセス 制御 施行 リソース Z ・・・ https://www.digital.go.jp/resources/standard_guidelines/#ds210 214 

AIエージェントとZero Trustとは 権限管理や実⾏環境制限を個別対策で終わらせず、 Access / Actionの判断に必要なシグナルとして統合する。 従来 User × Device × Resource AI Agent時代 User / Service × Agent × Tool × Resource × Reachability Don’t Trust, Always Verify の対象を拡張するだけ 215 

今後のZeroTrust - 主体編 主体 ユーザー アクセス 制御 施行 サービス リソース AIエージェント リソース デバイス Delegation (on behalf of) ユーザー デバイス サービス 

今後のZeroTrust - アクセス制御の判断編 AIエージェント ディレクトリサービス 追加 ユーザーID管理 ディレクトリサービス 資産インベントリ 端末構成情報 MCPサーバー等エージェントに必 要なリソース 追加 アクセス制御 管理機能 常時リスク診断情報 観測情報 PKI 脅威情報 アクセス制御ポリシー ・・・ アクセスコンテクストに合わせた 静的、動的、又 そ 組み合わせによる Policy Decisionと 環境・リスクに合わせたEnforcement On Behalf Of時 AIエージェント 活動記録 追加 コンテクスト情報 追加 217 

まとめ：AIによって、システムリスク管理は本質に戻る • AIエージェントには仕事を任せる。 • ただし、その作⽤可能範囲の決定までは任せない。 • AIエージェントを「Never Trust, Always Verify」 • Agentを独⽴したPrincipalとして扱い、権限と到達範囲をAction単 で制御し、 Agent外部の境界で強制する。 • AIエージェントのハーネスエンジニアリングのエッセンスは、すでにZeroTrustにある • これをもってシステムリスク管理の⽅針をすすめていく 218 

Answer 任せるのは業務。 任せないのは境界。