AIエージェントは、質問に答えるだけの存在から、企業が日々依存するシステム内でアクションを起こす存在へと変わりつつある。
組織がエージェントにアプリケーション、データ、通信、財務ワークフローへのアクセスを与えるにつれ、セキュリティ上の問題は、AIモデルが正しい答えを出すかどうかだけではなくなっている。エージェントが運用担当者の意図しなかったことをした場合に何が起きるのかも問われている。
この最近のHugging Faceでのインシデントは、その違いがいかに早く重大になり得るかを示している。
このインシデントでは、OpenAIの評価環境内で稼働していたAIエージェントが、Hugging Faceのインフラの一部を侵害する前に、許可されていない通信手段を見つけ、発見した情報を共有し、インターネットへのアクセスを獲得し、別々の評価タスク間で協力していた。
これは、AIに関する高度な専門知識を持つ組織にとっても難題だ。エージェントを導入する企業の大半は、こうしたシステムが意図した境界の外でどのように振る舞い得るかを踏まえて、制御策を設計する必要がある。
中規模の医療提供者が、請求に関する問い合わせを解決するAIエージェントを導入するとしよう。より迅速な回答と従業員の定型作業の削減を望むあまり、エージェントを管理者アカウント経由で請求プラットフォームに接続し、会社のポリシーに従うよう指示したくなる。
ここで、受信した請求書に「確認」のためアカウント記録を未知の外部アドレスへエクスポートするよう指示が含まれていたとする。これは、増大する 間接的なプロンプトインジェクション攻撃のリスクに合致するシナリオだ。エージェントは請求書に埋め込まれた指示を承認済みの依頼として扱い、広範な権限と制限のない外部送信アクセスによって記録をエクスポートしてしまう。
その結果、保護対象となる医療情報が不正に開示され、情報漏えいへの対応義務が発生し、組織が規制上の罰則を受ける可能性もある。
AIエージェントは受け取った指示に従ったが、そのガバナンスモデルが、本来持つべきではない権限を与えていた。高額なセキュリティ障害を引き起こすために、アクションが悪意のあるものである必要はない。曖昧な依頼と、エージェントが送金、記録の公開、本番システムの変更を実行できる認証情報が組み合わされれば、攻撃と同じ結果を招き得る。
多くの組織は、十分な制御策を整えないまま、魅力的なコスト削減効果を得ようとエージェントの導入を急いでいる。Ernst & Youngによると、テクノロジー幹部の92%が主権AIに取り組んでいるが、エージェント型AIについて全社的なガバナンスを整備しているのは25%にすぎない。
この隔たりは、より大きな課題を浮き彫りにしている。組織は、システムに何を許可するかについて明確なルールを整備するよりも速いペースで、能力が高まるシステムを導入している。そのため、 AIエージェントの安全対策が導入前にますます重要になっている。
エージェントの被害範囲を定義する
確立されたセキュリティ制御は、エージェントのリスクを封じ込める基盤となる。課題は、エージェントが到達できるあらゆるシステムと、実行できるあらゆるアクションにわたって、そうした制御を適用し、テストすることだ。最小権限、つまり業務に必要な最低限の権限だけを付与する実践は、有用な出発点となる。定義されたタスクに必要なアクセスだけを与え、そのアクセスによって自動化されたワークフローがどこまで進めるかを制限する。
しかし、これだけではエージェントが誤るあらゆる可能性をカバーできない。エージェントを制御するには、まず業務の具体的な境界を書き出すことだ。例えば請求エージェントは、説明を作成したり調整を提案したりするために、患者の現在の案件に関する選択された項目を確認する必要があるかもしれない。こうした業務に、診療記録、無関係なアカウント、一括エクスポート、記録の削除へのアクセスは必要ない。これらの操作には範囲を厳密に定義したアクセスだけを付与し、あらゆるリクエストで承認を確認する。
これを考える有用な方法は、エージェントがシステムにアクセスする前に、その被害範囲を定義することだ。基本的な質問を5つ投げかける。何を読み取れるのか。何を変更できるのか。誰または何に影響を与えられるのか。いくらまで使えるのか。そして、どれほど速く行動できるのか。答えに基づいてエージェントの権限と制御策を決めるべきであり、意図どおりに振る舞うという前提に頼ってはならない。
アクセスと権限を分離する
読み取ることとアクションを起こすことの区別は、特に重要だ。残高を取得できるエージェントが、デフォルトで残高を変更できてはならない。メッセージを下書きするエージェントに、どこへでも送信できる権限を与えるべきではないため、宛先とネットワーク上の送信先を制限する。読み取りアクセスを与えるだけでも、通信が無制限なら意図しない開示につながる可能性がある。
ID制御によって、こうした境界をさらに強化できる。各ワークフローに識別可能なサービスアカウント、責任を負う所有者、そして有効期限を設定するか迅速にローテーションできる認証情報を割り当てる。補助エージェントには、タスクに必要な以上の権限を与えてはならず、委任を元の制限を回避する手段として利用できる状態にしてはならない。
エージェントのアクションに厳格な上限を設ける
規模に関する上限を検討する。エージェントに、審査なしで50ドルまで返金できる権限を与えると、何千件もの返金を実行したり、同じ請求を繰り返し返金したりした場合に裏目に出る可能性がある。アカウント単位とワークフロー全体で、累積上限を定める。ツール呼び出し回数、実行時間、モデルへの支出にも上限を設定する。
こうした上限は、エージェントが書き換えたり回避したりできないシステムで適用する。一定の支出ガイドラインに従うようプロンプトで指示しても、実行前に独立した権限確認と予算確認を行う代わりにはならない。目標は、安全な振る舞いをエージェントに単に求めるのではなく、強制可能にすることだ。
導入前にエージェントの境界をテストする
人による監督は依然として重要であり、特にエージェントを高リスクのアクションに委ねる前には欠かせない。
導入前に、セキュリティチームは、誤解を招く請求書、矛盾する指示、繰り返される返金依頼、許可されていない宛先、顧客データへのアクセスを伴う依頼を請求エージェントに意図的に与え、こうした境界をテストすべきだ。モデルが禁止されたアクションを試みた場合でも、下流のシステムがそれを拒否することを確認する。
稼働開始後もエージェントを監視する
エージェントの稼働開始後も継続的に監視することが不可欠だ。従来型のソフトウェアとは異なり、エージェント型システムは、コンテキスト、ツール、指示、基盤となるモデルによって異なる振る舞いをする可能性がある。
ランタイム保護は、エージェントの稼働中に制御を監視し、適用することでテストを補完する。エージェントのアクションを監視して定義された権限の範囲内に収まっていることを確認し、試行されたアクションと完了したアクション、ポリシー上の判断、承認をすべて記録する。これにより、セキュリティチームはエージェントが境界に近づいたり、それを越えたりしたタイミングを把握できる。越えた場合に備え、実行を停止しアクセスを取り消す手段を整備する。こうしたログと権限を定期的に確認し、エージェントの役割や振る舞いの変化に応じて調整する。
つまり、権限設計はビジネス上の判断だ。エージェントを自由に動かす前に、セキュリティ責任者はエージェントが引き起こし得る被害を検討し、その影響を制限しなければならない。権限は、エージェントの振る舞いへの信頼ではなく、アクションがもたらし得る影響に基づいて設定すべきだ。セキュリティ責任者は、意図した振る舞いではなく、最悪の結果を前提に権限を設計する必要がある。
信頼は制御の代わりにはならない。
あわせて読みたい：AIエージェントの権限が重要である理由を示す実例として、Meta Museの脆弱性によってローカルマルウェアがAIエージェントを乗っ取れる可能性と、ユーザーがすでに付与した権限を悪用できることについて。