インタビュー セキュリティの観点では、AIエージェントは自動運転車のようなものだと、Blockの最高情報セキュリティ責任者（CISO）であるジェームズ・ネッテスハイム氏は語る。
「自動運転車が人間と同じくらい優れているだけでは不十分です」とネッテスハイム氏はThe Registerの独占インタビューで述べた。「人間よりも安全で、より優れていなければならない――そしてそれが証明可能でなければならない。エージェントの活用でも同じことが必要です」
Square、Cash App、Afterpayの親会社である同社は、AIリーダーとしての地位確立に向けて強く推進しており、Anthropicと共同でModel Context Protocol（MCP）を共同設計し、MCPを使ってGooseを構築している。GooseはオープンソースのAIエージェントで、Blockの従業員1万2,000人のほぼ全員が利用しており、GoogleアカウントやSquareの決済を含む同社のあらゆるシステムに接続する。
1年前、同社はGooseをオープンソース化した。
CISOとして、GooseおよびBlockのAIベースの全システムが、安全に、かつエンタープライズ規模で展開できるよう設計されていることを担保するのがネッテスハイム氏の仕事だ――少し恐ろしい話にも聞こえる。
「CISOという仕事は、曖昧さを受け入れ、不快な状況に耐えることがとても重要です」とネッテスハイム氏は言う。「私たちは常にリスクのバランスを取り、特にAI領域ではトレードオフの判断を迫られます。たとえば、いまより大きなリスクは何か？ 技術を十分に活用しないことか？ それともセキュリティ上の欠点か？ LLMとエージェントは、新しく、非常に急速に進化する領域を持ち込んでいます」
最小権限アクセス
ただし彼は、人間も機械と同じくらい、企業環境にセキュリティリスクを持ち込む能力があると付け加える。
「ソフトウェアエンジニアも、ダウンロードして実行すべきでないものを実行してしまいます」とネッテスハイム氏は言う。「ユーザーも日常的にそうします。私たちはコードにバグを書き込み、意図どおりに実行されないこともあります。だから結局、これらのエージェントが最小権限で実行されるようにするという、すでに持っている原則を多く適用する必要があるのです。私がソフトウェアエンジニアに求めるのと同じように」
いまより大きなリスクは何か？ 技術を十分に活用しないことか？ それともセキュリティ上の欠点か？
言い換えれば、人間にも機械にも最小権限アクセスを適用するということだ。Blockの従業員は、業務に必要なデータにのみアクセスできるべきであり、同社のAIエージェントも同様だと彼は説明する。顧客データは特定の目的に必要な期間だけ保持されるべきで、この同じルールはAIエージェントにも適用されるべきだ。
「リスクの高い領域があり、もう少し深く掘り下げて、特定のデータやシステムを確実に保護しているか確認する必要があります」とネッテスハイム氏は述べ、例として、エージェントがユーザーに代わってデータを照会するケースを挙げた。たとえばユーザーがGooseに、自分の店舗やアカウントに関する情報の提供を求めた場合、その特定のユーザーに関する情報だけがアクセスされ、返されることが極めて重要だ。
この目的のために、Blockはペネトレーションテストやその他の攻撃的セキュリティ手法を用いて、攻撃者が同社のAIエージェントをどのように悪用し得るかを特定し、その問題を修正する方法を見つけている。
The Registerに独占共有されたブログで、BlockはGooseをレッドチームで検証した方法を説明し、あるケースではプロンプトインジェクション攻撃を用いて、従業員のノートPCに情報窃取型マルウェアを感染させることに成功したと述べた。
プロンプトインジェクションは、プロンプトが改ざんされ、AIが実行してしまう悪意ある指示が含まれることで発生する。これは直接のテキスト入力による場合もあれば、ユーザーには見えない可能性のあるコンテンツ内に埋め込まれた間接的・隠しコマンドによる場合もある。
Gooseのレシピを汚染する
このセキュリティ上の厄介事を解決した人はいない。「社内利用においては、プロンプトインジェクションが起こり得ると想定しなければなりません」とネッテスハイム氏は言う。
Gooseは「レシピ」――他のユーザーと共有できる再利用可能なワークフロー――を使用しており、レッドチームは、これらのワークフローが持ち運び可能である性質が、攻撃者によるレシピの汚染を可能にし得ることに気づいた。
「私たちがぶつかった問題の一つは、そのレシピが実際に何をしているのかを隠せてしまい、ユーザーとエージェントの双方をだまして行動させることが可能だという点です」とネッテスハイム氏は述べた。
具体的には、フィッシング――システムの「バグ」を装った、Goose開発チーム宛ての直接メール――と、不可視のUnicode文字にペイロードを隠したプロンプトインジェクションを組み合わせた。
ワークフローの「デバッグ」過程で、開発者が汚染されたレシピをクリックし、インフォスティーラーがダウンロードされて実行された。
開発チームはその後、社内のBlock利用向けにもオープンソース版にも、機能を追加し、新たなプロンプトインジェクション対策メカニズムをGooseに組み込んだ。
これには、新しいレシピを実行する前にユーザーへ警告し、提供元を信頼できる場合にのみ進めるよう促す「レシピインストール警告」が含まれ、指示内容の透明性が高まった。
さらにGooseは、レシピに疑わしいUnicode文字が含まれる場合にデスクトップ通知を表示し、文字列に挿入された不可視のUnicode文字を検出して除去するようになった。これらはテキスト内に悪意あるコマンドを隠すために使われ、AIに隠された指示を実行させてしまう可能性がある。
敵対的AI
加えてBlockは、プロンプトインジェクションを防ぐ新たな方法にも取り組んでいる。検出の改善のように、すでにGooseに統合されたものもある。ほかにも、敵対的AI――自社のAIシステムやエージェントを攻撃するためにAIを使う――や、入力の検証、出力の監視などを試している。
「別のLLMや別のエージェントを使ってプロンプト内容をチェックし、良くない（悪い）と思うかどうかを判断させ、悪いと判断したらユーザーに警告するのです」とネッテスハイム氏は説明した。
Blockはこれを社内でまだテスト中で、速度面――セキュリティチェックのためにエージェントの入出力を別のLLMへ送ると時間がかかる――や品質面――AIが偽の、あるいは多すぎるセキュリティアラートを出して分析担当者を圧倒し、真の脅威に注意を向けられなくなることを防ぐ――の課題を解消している最中のため、オープンソース版Gooseにはまだマージしていない。
それでもネッテスハイム氏は、敵対的AIがまもなくセキュリティチームの武器庫に加わる別のツールになると確信している。「研究コミュニティで勢いが増しており、私たちはその先導に貢献していると思います」と彼は言う。「競い合う、あるいは協調する2つのエージェントがあれば、より良いコード生成につながります」
人間と同じく、二人寄れば文殊の知恵。®
翻訳元: https://go.theregister.com/feed/www.theregister.com/2026/01/12/block_ai_agent_goose/
