2026年8月28日／株式会社東京ネット工務店 海老沢敦
① 事実
米国立標準技術研究所(NIST)が、AIを入れた会社の問題を5つ挙げました
2026年8月27日、米国立標準技術研究所（NIST＝米国政府が使う技術基準を決める機関。暗号や情報セキュリティの規格を出しています）のサイバーセキュリティ研究拠点が、公式ブログで提言を出しました。書いたのは Bill Fisher と Ryan Galluzzo の2氏。進めているプロジェクトの名前は「Software and AI Agent Identity and Authorization」——ソフトウェアとAIエージェントの、身元と権限。
冒頭の一文が、こうです。
初期のエージェント導入は、見慣れた型を繰り返している——機能の開発と目先の価値を、安全より先に置くという型を。
タグ＝セキュリティ
実際の導入現場で見つかった問題を、5つ挙げています。
- 認証情報の共有——人が、自分の認証情報（IDとパスワード、あるいはそれに相当する鍵）をエージェントに渡している。誰がやったのかを、後から追えなくなります。
- 期限の無い、静的な鍵——APIキー（システムに接続するための長い文字列の鍵）やベアラートークン（bearer＝持参人。持参人払いの小切手と同じで、持っている側が誰であれ、それだけで通ります）。なりすましができます。
- 広すぎる権限——役割ごとにまとめて与えるため、範囲が大きくなる。データの一括削除のような、意図しない被害が起きます。
- 手元のアカウントを、そのまま使わせている——エージェントに、その機械の利用者アカウントの資格をそのまま持たせる形。
- 人の承認への依存——最後は人が承認するから安全、という設計。NISTはこれをconsent fatigue（承認疲れ）と呼んでいます。
5番目に、こういう説明が付いています。MFA bombing（多要素認証の通知を、被害者が反射的に承認するまで浴びせ続ける攻撃）と同じ形になる、と。承認を求める回数が増えると、人は中身を見ずに押すようになります。 そうなった時点で、承認は安全装置として働きません。
ブログの題は「Back to the Future」です。 新しい仕組みを作れ、とは書いていません。対策として挙がっているのは、OAuth 2.0、SPIFFE、DPoP、ゼロトラスト（社内の内側だからと信用せず、接続のたびに身元と権限を確かめる考え方。NIST SP 800-207）——すべて、既にあるものです。
鍵を手渡した記憶がなくても、4つの場面で渡っています
1番目の「認証情報を渡している」は、鍵を手渡した記憶がなくても成立します。当てはまる場面を並べます。
- 自分のPCにAIエージェントを入れて動かした。 そのPCには、社内システムにログインしたままの状態、保存されたパスワード、クラウドの接続情報が入っています。あなたが開けるものは、AIも開けます（NISTの1番目と4番目）。
- AIツールの設定欄に、業務システムのAPIキーを貼り付けた（2番目）。
- 「このアプリからのアクセスを許可しますか」で、許可を押した。 メール、カレンダー、共有フォルダ。自分が見られるものが、そのまま範囲になります（3番目）。
- 確認の画面で「今後は確認しない」を選んだ（5番目）。
どれも、その時は業務を進めるための操作です。 鍵を渡すつもりでやった人は、ほとんどいません。
同じ日、Anthropicは鍵の種類を入れ替えました
同じ2026年8月27日、AnthropicがClaude APIのリリースノートを更新しました。
これまで主に使われてきたのは、ワークスペースAPIキー（作業場ごとに発行する鍵）です。ここに2種類が加わりました。個人キー（発行した本人として動く）と、サービスアカウントキー——サービスアカウントとは、人ではないもの、つまりプログラムやAIに与える、専用の利用者登録です。
リリースノートの一文が、こうです。
Workspace API keys remain supported as a legacy option.
（ワークスペースAPIキーは引き続き使えます。旧来の選択肢として。）
理由は、公式の認証ドキュメントの表に書かれています。 鍵の種類ごとに「Acts as」——その鍵は、誰として動くのか——という欄があります。
| 鍵の種類 | 誰として動くか | いつ止まるか |
|---|---|---|
| 個人キー | あなた自身（あなたの役割と権限のまま） | あなたが組織から外れたとき |
| サービスアカウントキー | そのサービスアカウント | そのアカウントが停止されたとき |
| ワークスペースキー（旧来） | No one（誰でもない） | 期限切れ・無効化・削除。作った人が辞めても、止まりません |
同じドキュメントに、こうあります。
keys won't accidentally outlive the people or workloads that own them
（鍵が、持ち主である人や処理より長生きしてしまうことがなくなります。）
共有された個人キーについては、こう書かれています。 「一人の人間として動くので、その人が辞めれば止まる」。止まることが、仕様として書かれています。
期限を付けると、入れ替える人が要ります
Anthropicはその4か月前、2026年5月4日に Workload Identity Federation（ワークロードID連携）を出しています。
AIやプログラムが、自社が既に運用しているアイデンティティプロバイダー（IdP＝社員や機械の身元を一元管理する仕組み。Microsoft Entra ID、Okta、Google Workspace など）から身元の証明を受け取り、それと引き換えに、期限付きの鍵を受け取ります。 身元の受け渡しには OIDC（OpenID Connect＝ログイン済みの身元を、別のサービスに証明として渡す共通の規格）を使います。
受け取る鍵の期限は、既定で1時間（3,600秒）。設定できる範囲は60秒から24時間まで。設定画面の初期値は10分です。期限が来る前に、プログラムが自動で取り直します。
公式ドキュメントの説明が、こうです。
There are no static secrets to mint, store in CI, rotate, or leak.
（発行して、保管して、定期的に入れ替えて、漏らす対象になる固定の秘密が、そもそも存在しません。）
APIキーにも、期限は設定できます。 Anthropicの管理画面では、3時間・1日・7日・30日、あるいは任意の期間を選べます。「無期限」も選べます。
期限を付けると、切れる前に入れ替える作業が生まれます。 誰かがその作業をやらないと、鍵が切れた時点でシステムが止まります。ワークロードID連携が置き換えているのは、その入れ替え作業のほうです。 プログラムが期限前に自動で取り直すので、人の手が要りません。
出典（一次）：
- NIST NCCoE「Back to the Future: Why Agentic AI Needs a Strong Identity Foundation」（2026年8月27日／Bill Fisher・Ryan Galluzzo）https://www.nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundation
- Claude Platform リリースノート（2026年8月27日＝個人キーとサービスアカウントキーの追加／2026年5月4日＝Workload Identity Federation）https://platform.claude.com/docs/en/release-notes/api
- Claude Platform「Authentication」（鍵の3種類と「Acts as」の表）https://platform.claude.com/docs/en/manage-claude/authentication
- Claude Platform「Workload Identity Federation」（トークンの期限・対応する提供元）https://platform.claude.com/docs/en/manage-claude/workload-identity-federation
- 引用の訳は当社によります。 原文は各URLにあります。
② 構造
鍵そのものか、鍵を持つ誰かか
AIに使わせる鍵には、2つの作りがあります。 Anthropicの公式ドキュメントに、一行の対比があります。
a workspace API key is a credential, while a service account has credentials
（ワークスペースAPIキーは、資格そのものである。サービスアカウントは、資格を持っている。）
この違いが、記録に出ます。
鍵そのものが権限を持っている場合、その鍵で何が行われても、記録に残るのは鍵の名前だけです。 誰が使ったのかは、記録の外にあります。だから公式の表は、その欄に「誰でもない」と書いています。
会社の中の権限は、人に割り当てる仕組みしかありません。 職務権限規程も、システムの利用者登録も、退職時のアカウント停止も、全部「人」を単位に作られています。AIには、その単位がありません。 だから人の権限を借ります。借りたまま動けば、記録に出るのは貸した人の名前です。
「営業データには使わない」と決めても、守られたかは確かめられません
AIの利用ルールは、上の階層の話です。 誰が使ってよいか、何に使ってよいか、どこまで任せるか。本紙のVol.22で、中小企業の6割が「個人の判断に任せている」と答えた調査を扱いました（方針を決めていない、という状態です）。
今回のNISTの指摘は、その下の階層にあります。 誰の権限で動いているか。
下が空白だと、上のルールは確かめられません。 「営業データには使わない」と決めても、誰がどのデータに触れたかの記録が人単位で残っていなければ、守られたかどうかを検証できません。 方針を決めた会社と、決めていない会社が、同じ場所に立つことになります。
プログラムの変更は全員分残ります。AIが何をしたかは、残りません
ソフトウェアの世界では、同じ問題を一度解いています。
Git（プログラムの変更履歴を管理する仕組み）は、誰が、いつ、どの行を変えたかを、全員分残します。 中小の開発現場でも、これは標準になりました。コードについては、記録の問題は片付いています。
片付いていないのは、実行の側です。 AIエージェントは、各自のPCで、各自の鍵で動いています。何をしたかの記録は、その人の機械の中にあります。会社には残りません。
NISTのブログの題「Back to the Future」は、そこを指しています。人間のアカウント管理では、同じ部署で一つのIDを共有するやり方を捨てて、個別のIDにしました。 誰がやったかを残すためです。AIエージェントの世代で、共有に戻っています。
コードの管理は集約された。エージェントは、この1年で各自の手元に分散した。集約への揺り戻しが、始まっています——鍵を人と機械に紐づけ、会社の身元管理に接続する方向です。8月27日の「legacy」の印は、その一歩です。
AI側は、先に動いています
この話を「AIが鍵を盗む」と読むと、外れます。
AI側は、すでに鍵を見ないように作られています。 設定ファイルに書かれた認証情報を避ける、読み込まない、表示しない。それでも読んでしまったときには、自己申告してきます——「認証情報を見てしまいました。ローテーション（鍵を新しいものに入れ替えること）をしてください」。
これは、AIエージェント側の自衛です。 追いついていないのは、鍵を渡す側の配線です。
自己申告には、受け皿が要ります。 「入れ替えてください」と言われて、その鍵を入れ替えられる人が、その場にいるかどうか。 ここで規模が効きます。
