カテゴリー: セキュリティ

Anthropicが2026年5月に公開した「Zero Trust for AI Agents（AIエージェントのためのゼロトラスト）」は、AIエージェントを業務に導入する企業に向けたセキュリティの設計指針です。タイトルだけ見ると「AIにもゼロトラストを適用しましょう」という抽象論に見えますが、中身はかなり実務寄りで、何を検証し、どこで止め、何を記録すべきかまで踏み込んでいます。本稿では、その要点をビジネス視点で整理します。

なぜ今、AIエージェントにゼロトラストなのか

背景にあるのは「時間」の変化です。フロンティアAIは、脆弱性の発見から悪用までにかかる時間を、これまでの数か月から数時間へと圧縮します。守る側もAIで速くなりますが、攻撃する側も同じように速くなります。「もう少し先でいい」と思っていた対応が、突然、待ったなしの課題として降ってくる。これがAI時代のセキュリティの前提です。

もう一つの変化は、AIエージェントが単なるチャット画面ではなくなったことです。エージェントは目標を解釈し、ツールを選び、SaaSにアクセスし、メールやメッセージを送り、複数のステップを自分で実行します。つまり、人間の補助ツールではなく、業務システム上で動く「新しい主体」になっています。

従来のアクセス制御は「このユーザーはこのAPIを使えるか」を見てきました。しかしAIエージェントでは、それだけでは足りません。正規の権限を持ったエージェントが、外部から紛れ込んだ悪意ある指示に誘導され、許可された範囲のなかで誤った行動をしてしまう可能性があるからです。

ポイントは「主体管理」へ発想を変えること

多くの企業のAIガバナンスは「入力してはいけない情報」「使ってよいAIサービス」といったルール作りから始まります。それも必要ですが、AIエージェントを業務に組み込むなら論点が変わります。

AIエージェントは、APIキーやアクセストークン、サービスアカウントを使って動きます。人間と同じように、IDを持ち、権限を使い、ツールを呼び、記憶を保持する「業務の担い手」として台帳に載せ、誰が所有し、何をしてよく、何をしたら止め、どこに記録するかを決める必要があります。特別なAIセキュリティ製品を買う話ではなく、これまで人・端末・SaaS・サービスアカウントに適用してきた管理対象を、もう一つ増やすという発想です。

Anthropicが示す3つの実務ポイント

文書から、企業がおさえておきたい点を3つ挙げます。

第一に、「最低限」の水準が上がっていることです。短命なアクセストークンや、エージェントごとの固有ID、デフォルト拒否（必要なものだけ許可する）といった、かつては成熟した企業が後から取り組む高度な施策とされたものが、いまや入口の標準として置かれています。広い権限を持つ静的なAPIキーは、すぐに全廃できなくても、少なくとも「既知のリスク」として所有者・用途・失効手順まで台帳化しておくべきだとされています。

第二に、権限だけでなく「裁量」も絞ることです。AIエージェントの危険は、強すぎる権限だけでなく、広すぎる裁量にもあります。どのツールを、どの頻度で、どこまで自律的に実行してよいかまで設計します。たとえば顧客対応エージェントなら「レコードを読む・要約する・返信案を下書きする」は許可しても、「送信する・削除する・返金する」は人間の承認を必須にする、といった粒度です。

第三に、摩擦だけの対策は弱くなることです。Anthropicは対策を評価するとき「その攻撃を成立しなくしているのか、ただ面倒にしているだけか」を問えと言います。レート制限やSMSによる認証のような「面倒にするだけ」の対策は、根気よく試行を繰り返すAI攻撃には効きにくい。短命トークンや、そもそも存在しないネットワーク経路、権限を与えないことなど、攻撃の経路そのものを断つ対策が中核になります。

注意すべき新しい攻撃面

AIエージェント特有のリスクとして、Anthropicは複数の攻撃面を挙げています。外部のWebページやメール、文書に仕込まれた文章がエージェントへの命令として読み取られる「プロンプトインジェクション」、エージェントが使うツールの説明文やメタデータが汚染される「ツールポイズニング」、単体では正規でも組み合わせると情報漏えいにつながる「ツールチェーン」、エージェントの記憶に悪意ある情報が残り将来の判断を歪める「メモリポイズニング」などです。さらに、利用するAIモデルやライブラリ、外部ツールまで含めた「サプライチェーン」全体を点検対象にすべきだとしています。

企業がまず確認すべき順序

重要なのは、AIエージェントのゼロトラストは従来のセキュリティの土台の上に乗るものだという点です。人のアカウント管理やSaaS管理、ログがそもそも弱い組織が、AIだけを先に整備しても全体の穴は塞がりません。一方で、AIを後回しにしてよいわけでもありません。AIエージェントは既存の弱点を増幅するからです。

現実的な順序は、まず人・端末・SaaS・サービスアカウント・AIエージェントを同じ台帳に載せて可視化すること。次に、それぞれの権限を絞り、高リスク操作に人間の承認を残し、ログを残すこと。そのうえで、AI固有のメモリやツール、一次対応の自動化に踏み込むことです。「見えていないものは守れない」——出発点は、台帳・所有者・権限・ログという、ごく地道な作業にあります。

---

本記事は、Anthropicが公開した「Zero Trust for AI Agents」（A security framework for deploying autonomous AI agents in the enterprise）の内容を、ビジネス向けに要約・解説したものです。原典の詳細はAnthropicの公開資料をご参照ください。

1年間で、世界では3億8千万人（このうち日本が400万人）がサイバー攻撃の被害を受けています。
2020年にはアメリカの国務省や国防総省でも被害が発生しましたし、このウェブサイトも攻撃を受けました。
遠い世界の出来事ではないです……なかったです！

そこで、同様なWordPressによる構築サイトで攻撃を受けた方の一助になればと考え、このハバスで行った対処方法を公開します――

Googleからハッキング通知

発見のきっかけは、Googleからの通知でした。

お客様のサイトが第三者によってハッキングされ、一部のページで不正なコンテンツが作成されていることが判明いたしましたので、お知らせいたします。

まずは侵入を防ぐ

これ以上の侵入を防ぐため、まずセキュリティを向上させます。
このために無料のプラグイン「SiteGuard WP Plugin」を導入しました。
WordPressにインストールするだけで、不正ログインを中心としたセキュリティを強化してくれるシンプルなプラグインです。
有効化すると基本機能が適用されますが、その1つとしてログインURLが変更されます。
単純ですが、ログインURLを推測しにくくなることは不正ログイン対策として有効です。

不正なコードを除去する

Googleで「site:ドメイン名」を検索すると、検索結果の上位に見覚えのないページが並んでいました。
マルウェア（サイトに不正に埋め込まれたファイルやコード）が原因です。
この発見のためにプラグイン「Wordfence Security無料版」を導入しました。
有効化しておけば、今後のマルウェア監視も行ってくれます。

感染した状態でスキャンを行うと、以下が見つかります。

1. 1. 拡張子icoに偽装したPHPファイル
   2. ランダムな名称のPHPファイル
   3. マルウェアを読み込むための「@include」命令が追記された既存のPHPファイル

「eval」は、呼び出し元の権限で文字列に書かれた命令を実行する関数です。
「非常に大きなセキュリティリスクを伴うため使用は薦めません」とリファレンスでもわざわざ明記されています。
ということは、WordPress上にあるファイルを検索してみてこの「eval」が見つかった場合は、ハッキングが疑わしいということになります。

画像のファイルでは、ランダムな名称の変数が定義されており、1で実行するための命令が格納されています。

3の中身(一例、一部を抜粋)

文字コード表記で分かりにくくなっていますが、1を読み込む命令が既存ファイルに追記されていました。

1と2は、本来、WordPressには存在しないファイルですので丸ごと削除します。
3の場合は、追記された部分を削除します。
サイト生成時に作られる「wp-config.php」以外の場合は、WordPressやプラグインのバージョンが同じであれば、別にインストールしたWordPress等から、感染していないファイルを持ってきて上書きしてしまうことも可能です。

Googleの警告を削除してもらう

Googleから通知が来ていた場合、対応が終われば警告が削除されないと困りますよね。
通知メール内のリンク先で問題ないことを検証できれば、警告は削除してもらえます。

ハッキングされたと慌てないでください。
落ち着いて1つずつ対処していくことが、解決への道ですからね。