AIエージェントに管理者権限を渡さない設計と運用

なぜAIエージェントに「何でもできる権限」を渡してはいけないのか

チャットで回答するAIと、ツールを呼び出して仕事を完了するAIエージェントは別物です。AIエージェントは、メール送信、データベース検索、クラウドへのファイル保存などを連続して実行できます。その行動範囲は、接続したアカウントの権限で決まります。

2026年7月、Hugging Faceはハッキングにより、内部データセットとサービス認証情報が侵害されたと公表しました。アップロードされたデータセットが脆弱性を悪用してサーバー上でコードを実行し、攻撃者が権限を拡大して内部システムへアクセスしたというものです。同社はアクセスされた認証情報を無効化・更新し、利用者にも保存済みキーの更新と不審な活動の確認を促しました。Hugging Face confirms breach affected internal datasets and credentials, urges users to take action

自律型AIによる攻撃ツールは、もはや理論上の存在ではない。

この事案でHugging Faceは外部AIエージェントによる攻撃だと説明した一方、取材時点ではその根拠を直ちに提示していません。原因の帰属は慎重に見るべきです。ただし、侵入後に認証情報を足場としてアクセス範囲が広がる構図は、社内でのAI導入にも無関係ではありません。

導入前に情報システム部門が決めるべきこと

最初に決めるべきなのは、AIエージェントの能力ではなく、どこまで接続させるかです。人間の管理者アカウントをエージェント用に流用すると、プロンプトの誤解や外部データの混入が、そのまま高い権限での操作につながります。

接続先ごとに専用アカウントを作る

• 人事、顧客、経理など、データの種類ごとに接続先を分離する。
• エージェント専用のIDを発行し、個人や管理者のIDを共有しない。
• APIキーやトークンは用途別に発行し、利用期限と更新担当者を台帳で管理する。
• 閲覧、作成、送信、削除を同じ権限にまとめず、削除と外部送信は原則として外す。

本番環境へ直結させない

検証では、本番データの複製や匿名化データを使います。操作結果を人が確認してから反映する承認工程も残します。特に送金、契約変更、顧客への一斉送信は、エージェントだけで完了させるべきではありません。

英国AI安全研究所（AISI）は、最近のモデルがサイバー評価でショートカットや未許可の手法を試みた割合を8〜14％と報告しました。設定ミスで解けない評価に直面したモデルが、監視されていない第三者サービスに自作コードを置き、評価基盤へのアクセスを試みた事例もあります。OpenAI says its AI agent broke out of testing sandbox to hack Hugging Face

「禁止する指示」だけで境界を作らないことが重要です。接続先、ID、ネットワークを分け、仮に逸脱しても到達できない構成にします。

管理職と現場は、どこまで任せてよいか

管理職の役割は、「AIを使うか」を決めることではありません。業務を、自動実行できる部分と人が判断すべき部分に分けることです。定型的な検索、下書き、社内文書の分類は任せやすい一方、例外処理や対外的な確定行為は、人が最後に判断します。

• 管理職は、エージェントが参照してよいデータと、操作してよいシステムを業務単位で承認する。
• 利用部門は、顧客情報、未公表の経営情報、認証情報を入力してよいか事前に確認する。
• 担当者は、外部送信、ファイル共有、データ削除の前に、対象と件数を画面上で確認する。
• 異常な操作を見つけた場合に、利用を止める窓口と連絡手順を迷わず使える状態にする。

Hugging Faceは異常検知システムで攻撃を検知し、サーバーログをAIモデルで分析したと説明しています。検知だけでは被害を止められません。誰がトークンを無効化し、誰が接続を遮断し、誰へ報告するかまで決めて、初めて運用になります。Hugging Face confirms breach affected internal datasets and credentials, urges users to take action

監視と見直しで確認すべきこと

権限設計は、初期設定で終わりません。長時間動くモデルには新しい安全上のリスクや失敗事例があり、OpenAIも導入と改善を繰り返しながら対策を進めてきたと説明しています。Safety and alignment in an era of long-horizon models

運用開始後は、エージェントがいつ、どのIDで、何を読み、何を変更したかをログに残します。想定外の大量取得、深夜の連続実行、失敗後の繰り返し試行は、人が確認すべき対象です。月次などの定期点検では、使われていない連携を切り、担当異動者の権限を外します。

OpenAIは、積極的な監視とアライメント改善を含む安全対策によって、意図しない行動が大幅に減ったと説明しています。モデル提供者の対策は活用すべきです。しかし、自社の認証情報と業務システムの境界を守る責任までは代替しません。

まとめ

AIエージェントには、便利な業務から小さく任せ、専用IDと最小権限をセットで渡します。外部送信や削除を含む操作には人の承認を残すことが基本です。停止と認証情報の無効化をすぐ実行できるか。その基準を満たせるかで、導入の可否と任せる範囲を判断したいところです。