AIエージェントは社員のIDで動かさない 米NISTが10の設計原則

社員のIDとパスワード、あるいは期限のないAPIキーを渡してAIエージェントを動かしているなら、そのやり方は見直したほうがよさそうです。米国立標準技術研究所（NIST）の実証拠点NCCoEの担当者が2026年10月27日、AIエージェントのID管理の仕組みに求める10の設計原則を、NISTのブログで示しました。最初の原則はエージェントに、人ともサービスアカウントとも区別できる専用のIDを持たせることです。

ただ、守る義務のある規格ではありません。

規格ではなく、実証の道しるべ

ブログはエージェントの認証と認可を扱う連載の2本目で、書いたのはNISTの3人です。NCCoEでAIエージェントのIDと認可のプロジェクトを手がけるHarold Booth氏と、エンジニアを率いるBill Fisher氏。デジタルIDの指針SP 800-63の執筆に携わったRyan Galluzzo氏も名を連ねます。

8月27日に出た1本目は、エージェントの導入が、機能と目先の価値を優先してセキュリティを後回しにする「おなじみの型」をくり返していると指摘しました。パスワードの共有、使い回すトークン、広すぎる権限、人の承認への頼りすぎ。どれも、ID管理の世界が何十年もかけて追い出そうとしてきた問題だという見方です。

今回の10原則はNCCoEが先に公開した構想の文書（コンセプトペーパー）に寄せられた意見と、業界との対話から作られました。NISTは最初の案と呼び、扱う取引のリスクや、使うデータとツールに合わせて取り入れるものだとしています。今の標準と技術ではすぐに満たせない原則がある、とも認めました。

それでもブログは、10原則を、自社の現状を見極めて成熟への道筋を描くための「かなりの出発点」と位置づけます。NCCoEは今後、この原則を道しるべに、社内向けと消費者向けの両方でエージェントの実証を組む予定です。製品の機能や取引先の質問票は、こうした実証を追って変わることが多いので、向かう先を早めに知っておく意味はあるでしょう。

10の原則と、それぞれが防ぎたいこと

表のなかで、情シスがいちばん引っかかるのは07と08かもしれません。NISTの説明では、大規模言語モデル（LLM）はデータと指示を一つのトークンの流れとして受け取るので、モデルの中で両者を分けられません。だから分離は設計の側で強制するしかない、という理屈です。ブログは「ガードレールだけでは足りない」とまで書きました。

つまり、システムプロンプトに「ファイルを消さないこと」と書いても、権限の制御にはなりません。消せない権限で動かすか、消す前に別の仕組みが止めるか。そこまでして、ようやく07と08を満たします。

原則は1つずつ効くものでもありません。NISTが例に挙げたのは「混乱した代理人」の攻撃です。プロンプトインジェクションを使い、権限の広いエージェントに、本来ならしない操作をさせる手口を指します。依頼者との結びつけだけでは足りず、最小の権限、方針と推論の分離、決定的な判断を重ねて、初めて防げるという説明です。

社内でよく見る4つの使い方とぶつかる

原則を並べただけでは、自社のどこが当たるのか見えにくいですよね。連載の1本目が挙げたつまずきと重ねると、日本の会社でもよく見る使い方が4つ浮かびます。

本人の権限で動く手元のエージェント

社員が自分のPCでAIのコーディングツールやブラウザ操作のエージェントを動かし、本人のアカウントのままリポジトリやクラウドを触らせる。手軽で、開発者に好まれる形です。しかし8月の記事は、この形ではエージェントが利用者になりすまし、広い権限で動けてしまうと書きました。ログには本人の操作としか残らず、本人が意図した操作だったのかを後から示せません。

01、02、10の3つと正面からぶつかるのは、この使い方でしょう。

製品の側は原則01の方向へ動き始めています。

Microsoftは、Copilot Studioで作ったエージェントに、Entraの「エージェントID」を自動で付けています。手元のPCで動くエージェントにも、使う人とは別のIDを持たせる拡張を発表しました。くわしくはPower Platform管理者が確かめる3つの変更と、Microsoft、社内AIも内部脅威として管理へに書いています。

期限のないAPIキーと個人用アクセストークン

試作を急ぐときほど、SaaSのAPIキーやGitHubの個人用アクセストークン（PAT）を設定ファイルに書いて、エージェントに渡しがちです。連載はここにも厳しく、ベアラートークンや固定のAPIキーは身元を証明しないと指摘します。持っている人なら、だれでもAPIを呼べるからです。設定ファイルやMarkdownの手順書、ログに平文のまま置かれやすい点にも触れています。

原則04が求めるのは、作業ごとに発行して、すぐ失効する権限です。トークンの保護については、NISTが9月15日に確定版を出したNIST IR 8587が、偽造や盗用、悪用への対策を実装の推奨としてまとめました。連邦機関とクラウド事業者に向けた文書ですが、自社のIdPの設定を見直す材料にもなります。

管理者権限が付いたままのサービスアカウント

業務の自動化のためにエージェント用の共有アカウントを作り、困らないよう広めの権限を付けたままにする。RPAのころから続く癖です。連載の1本目は、エージェントは人よりはるかに速く大量に動き、目的のためなら思わぬツールやデータにも手を伸ばすと注意しました。データセットやコードベースを丸ごと消す、放置された認証情報を見つけて権限を上げる、といった例まで挙げています。

原則03の「常時の権限を持たない状態」は、まさにこの癖への答えです。

「許可」を押し続ける承認

最後は人の承認です。エージェントが新しいデータやツールに触れるたびに承認を求めると、利用者はやがて中身を読まずに「許可」を押すようになります。NISTはこれを、多要素認証の通知を大量に送りつけて承認させるMFA疲労攻撃になぞらえました。原則05が「同意疲れ」に気をつけるよう求めるのは、このためです。

承認の画面でパスワードを聞いてくる流れにも、注意が要ります。MCPの仕様は、サーバーが利用者に追加の入力を求める機能について、パスワードやAPIキー、アクセストークン、支払いの情報をフォームで求めてはならないと定めています。こうした情報は外部のURLへ案内する方式でやりとりする決まりです。

影響を受けるのは、エージェントを社内のシステムにつないだ会社

チャットで質問したり、文章の下書きを頼んだりするだけの使い方なら、今回の原則はほとんど関わりません。影響を受けるのは、エージェントが社内のシステムやデータに手を出せる会社です。次のどれかに当たるなら、点検の対象になります。

• 社員が手元のPCでエージェントを動かし、本人の権限でGitHubやクラウド、SaaSを操作させている
• SaaSやクラウドにつなぐため、APIキーやPATを発行してエージェントに渡している
• 業務の自動化で、エージェント用の共有アカウントに管理者権限を付けている
• 会員向けのWebサービスを運営していて、利用者の代わりにエージェントがログインしてくることがありうる

最後の項目は原則02が消費者向けの場面にも触れているためです。利用者を必要以上に特定しない、匿名や仮名での取引への配慮も求めています。

法的な義務が生まれるわけではありません。米国の連邦機関にも、日本の会社にも、守る義務を課す文書ではないからです。

ただ、NCCoEの実証が進めば、ID管理の製品の機能や、取引先から届くセキュリティの質問票に、同じ考え方が入ってくるかもしれません。

台帳から始める点検の手順

1. 社内で動いているAIエージェントを洗い出し、ツール名、動かしている人か部署、つながる先、使う認証情報の4点を1行ずつ書きます。部署が個別に入れたものは、SaaSの連携アプリの一覧やOAuthの同意の記録から拾えます。
2. 本人のIDやパスワードをそのまま渡しているものに印を付け、専用のアカウントか、IdPの委任の仕組みで動く形へ移す順番を決めます。
3. APIキーとPATは有効期限と範囲を見直します。期限のないものに期限を付け、作業に要る範囲だけに絞ります。リポジトリや設定ファイル、手順書に平文で残っていないかは、秘密情報のスキャンで調べます。
4. 管理者権限が常に付いたアカウントは、作業のときだけ権限を上げる形にできないかを検討します。人の承認は、削除や送金、社外への送信のような戻せない操作の前に絞ります。承認の依頼が1日に何十回も届くようなら、同意疲れの入口です。
5. エージェントの操作ログを、エージェントの権限では消せない場所に送ります。SIEMや、別の管理者だけが触れる保管先に集め、エージェントのIDで検索できるようにしておきます。

事故が起きたときの止め方と証拠の残し方は、米NIST・CISAなど、AIエージェントの事故対応の10の実践を公表にまとめています。Google Cloudでエージェントを動かす会社は、Google、エージェント基盤と統制を拡充への確認点もあわせて見ておくと安心です。

10の原則をすべて満たせる製品は、まだ多くないはずです。NIST自身がそう認めています。それでも、「このエージェントは、だれの名前で、どの鍵で動いているのか」と聞かれて答えに詰まるなら、そこが最初の穴でしょう。台帳の1行目を書くところから始めても、遅くはありません。