はじめに

Google Cloud Next Tokyo 26のDeveloper Stageセッション「Gemini Enterpriseを安全に活用するAgentic Defenseの土台」（D2-DEV-25）のセッションレポートをお届けします。

組織にAIを入れると、AIの回答を経由して社内情報を持ち出されるリスクがついてきます。ただ、対策として社内の全端末を管理下に置くのは負担が大きく、かといってAIの利用を止めるわけにもいきません。本セッションが示したのは、Gemini Enterpriseへの入り口を、管理されたブラウザかどうかという条件1つで制御する構成でした。

セッション概要

項目 内容
セッションID D2-DEV-25
会場・時間 1F Expo Developer Stage／17:10〜17:20
登壇者 関谷 友明 氏（株式会社電算システム）

Developer Stageの最終セッション枠で、Agentic Defenseのうち入り口の予防に絞って扱う、という前置きから本編に入りました。

gc-next-tokyo-26-agent-defense-session-title

1. AIが「持ち出し口」になる

課題設定は、AIは一度使うと手放せなくなる一方で、アクセス制御を後回しにするとその便利さがそのまま漏洩の経路になる、というものでした。

gc-next-tokyo-26-agent-defense-problem-data-exfiltration

非管理端末のブラウザからアクセスし、社内情報をAIで要約させ、その回答をコピペで持ち出す。しかもログに残らないので検知が難しい。AIが情報を集約してくれるため、持ち出す側から見れば効率のいい経路になってしまうという指摘でした。
ここで示された方針が、一番目の「非管理端末」をブラウザレベルの制御に置き換えるというものです。端末のOSを管理下に置くのではなく、管理されたChromeブラウザかどうかで判定することで、OS依存をなくすという構成になります。

2. 「境界」ではなく「ループ」で守る

答えは高い壁を1枚立てることではなく、予防・統制・検知・対応の4点を回すという整理でした。

gc-next-tokyo-26-agent-defense-loop

対応で得られたものを予防に戻すところまで含めてループにする。これをGoogle CloudではAgentic Defenseと呼んでいるそうです。
補足として、この言葉には「エージェントを守る」と「エージェントで守る」の両方の意味があり、今回扱うのは前者、自動化の前段にあたる部分だと整理されていました。

3. 最小構成は4つのピース

入り口の予防に絞ったときの最小構成として、4つの要素が挙げられました。

gc-next-tokyo-26-agent-defense-four-pieces

Chrome Enterprise Premiumがブラウザ層を担当し、管理対象のChromeブラウザだけを許可します。あわせてコピー・貼り付けの制御などDLPも効かせられます。Access Context Managerがアクセス条件を定義する役割で、CEL式1行でデバイス条件を書き、Endpoint Verificationのシグナルで条件を広げていけるとのことでした。VPC Service Controlsはdiscoveryengine.googleapis.comをPerimeterで封鎖する、API単位の制御です。そして守られる側がGemini Enterpriseになります。

4. 2つの実装アプローチ

止め方には2つの方式があり、それぞれ性格が違うという話が続きます。

gc-next-tokyo-26-agent-defense-two-approaches

VPC Service Controls方式はAPIレベルで封鎖するもので、Google CloudコンソールのGUIから設定します。すでにVPC SCを運用している場合や、API境界ごと守りたい場合に向いています。Restricted Client Applications方式はアプリ単位でバインドするもので、gcloudコマンドで展開が可能で、Web UIだけを素早く制御したい場合に向いています。

注意点として挙げられていたのが、前者はAPIを止めてしまうため管理者のアクセスまで止まりうる、という点でした。デッドロックの状態になって困ることがあるので、いきなり前者をやるのではなく、まず後者から試すことがおすすめ、と説明されていました。より強固にしたい場合は、後者を入れたうえで前者を重ねるのがベストプラクティスとのことです。

gc-next-tokyo-26-agent-defense-flow-diagram

フロー図で示された条件は、管理対象のChromeブラウザを使うユーザーAと、非管理対象のブラウザを使うユーザーBの違いだけです。異なるのはブラウザの管理状態1点で、それを分けるのがAccess Context Managerの条件式になります。拒否されたときの画面は方式によって変わり、VPC Service Controls方式ではアクセス権なしの403、Restricted Client Applications方式では「You don’t have access」になります。

5. デモ

デモは、管理対象ブラウザと非管理対象ブラウザをそれぞれ並べ、どちらもGemini Enterpriseにアクセスできる状態から始まりました。

gc-next-tokyo-26-agent-defense-demo-rca-binding_2

Restricted Client Applications方式では、Cloud Shellでアクセスレベルを作り、Gemini Enterpriseにバインドします。画面に映っていた条件式はdevice.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGEDの1行で、3章のCEL式1行がそのまま出てきた形でした。適用すると、非管理対象ブラウザからはアクセスできなくなりました。
なお、この設定方法はGoogleの公式マニュアルには掲載されないまま、ひっそりとGAされていた、という補足がありました。
続いてVPC Service Controls方式で、こちらはDiscovery Engine APIを止めることになるため影響範囲が広くなります。GUIで設定して少し待つと、非管理対象ブラウザに403が表示されました。

さいごに

Gemini Enterpriseへの入り口を、ブラウザの管理/非管理の条件1つで制御する構成を、説明からデモまで通す内容でした。基調講演で語られていたのがAIエージェントに何を委任できるかという話だったのに対し、こちらはその手前の、委任する相手をどこから使わせるかという話だったと思います。影響の小さいRestricted Client Applicationsから試して、必要ならVPC Service Controlsを重ねるという順番まで示されていたので、実運用に役立つ内容の印象でした。同じようにAI基盤のアクセス制御を検討している方の参考になれば幸いです。