あなたのために働くAIエージェントは、おそらくあなた自身よりも多くのアクセス権を持っています

AIは担当者の仕事をそのまま行っているわけではありません。AIは、担当者が使うツールです。ですが、そのツールは、あなたのために働いている相手の人間よりも、システムに対する到達範囲（アクセス範囲）が大きくなってしまいます。このギャップ――範囲が限定されたアクセス権を持つ人間が non-human identity より広いアクセス権を持つ存在を使う状況――は、企業におけるAI導入の“通常の形”になりつつあり、ほとんど誰も、人の権限を確認するときのようにそれを見直していません。

Netwrix の 2026 Data & Identity Security Report は、セキュリティおよび IT リーダー 2,317 名を対象とした調査に基づき、この傾向を裏付ける数値を示しています。72% の組織が、アイデンティティ（Identity）関連データの露出リスクが増加したと回答しています。58% が、以前よりも多くのアイデンティティが現在ではエンタープライズ データへのアクセス権を持つようになったと述べています。41% はすでに本番環境で agentic AI を運用しており、これらのエージェントは、敏感なデータに対して人間の代わりに行動しています。non-human identities は将来の問題ではありません。多くの環境で、すでに主要なステークホルダーの大半を占めています。

アクセスレビューに表示されない部分

多くの identity governance プログラムは、joiner-mover-leaver（入社・異動・退職）のリズムに基づいて設計されてきました。誰かが入ってくると、そのアクセス権が増えたり変化したりし、そして最終的に退職すれば、アクセス権は取り消されます。 Service accounts、API キー、証明書、オートメーション・トークンは、そのパターンに従いません。導入（deployment）時に作成され、立ち上げが最も早かったテンプレートから引き継がれ、その後はフォローアップの責任を持つ人がいないため、放置されがちです。

このレポートはそれを裏付けています。非人間のアイデンティティ（non-human identities）を完全にガバナンスしていると回答したのは、組織のわずか 19% です。76% は、本来必要がなくなった時点で、常時（standing）のアクセス権をすぐに取り消せません。64% には、重要データに対して少なくとも一部、過剰に（overprovisioned）付与されたアクセス権があります。これらをまとめると、人間の労働力規模よりも大きい数の認証情報（credentials）が存在し、追跡しにくく、ほとんど見直されない状態になります。

この問題には、特に注意して挙げるべき「特定のバージョン」があります。証明書ベースの認証（certificate-based authentication）は、AI エージェントや自動化における主要な信頼メカニズムになりつつありますが、ほとんどの組織はその根底にある証明書インフラ（certificate infrastructure）をほとんど把握できていません。誤設定されたテンプレート、過度に許可的な登録権限（enrollment rights）、および Active Directory Certificate Services における継承された信頼関係（inherited trust relationships）によって、攻撃者はパスワードに一切触れることなく、特権（privileged）アイデンティティになりすませてしまう可能性があります。

これは「アイデンティティ」だけの問題ではなく、変更管理（change management）の問題である理由

見落とされがちなポイントがあります。サービスアカウントの権限、証明書の信頼チェーン（trust chain）、API キーのスコープ（scope）――これらは一切、単独でアイデンティティ・プラットフォームの中だけに存在しているわけではありません。実際には、そのアカウントが動作する対象システム上の設定ファイル、レジストリキー、証明書ストア、そしてスケジュールされたタスクの中に存在します。規制上の義務が変わった場合（新しい PCI DSS の要件、更新された NIST のコントロール、あるいは NERC CIP の改訂など）には、アクセスレビューと失効（revocation）の手順が一緒に行われるべきです。しかし実際には、アイデンティティ側に注目が集まり、設定側はバックグラウンドで静かにズレていきます。

そのドリフト（drift）こそが、未承認の変更（unauthorized change）が隠れる場所です。必要以上に広い登録権限（enrollment rights）をサービスアカウントに与えてしまうレジストリキー。退役（decommissioned）済みの統合（integration）をまだ指している設定ファイル。6か月前に編集されたのに、誰もレビュー対象としてフラグを立てなかった証明書テンプレート。これらは、アクセス認証（access certification）のスプレッドシートには一切出てきません。実際にシステム上で何が変わったのかを見たときに初めて明らかになります。

名簿を見るだけでなく、システムを監視する

こここそが file integrity monitoring とセキュリティ設定管理が会話における席を得る場所です。 Netwrix Change Tracker はアイデンティティを管理しませんが、アイデンティティや資格情報が実際に存在するシステムは監視します。設定ファイル、レジストリキー、システム設定をベースライン化し、そのベースラインから逸脱する変更をリアルタイムで検知します。Planned Change のルールがある場合、パッチウィンドウに紐づいているか、承認済みの ServiceNow リクエストに紐づいているかにかかわらず、該当する変更は自動的にフィルタリングされます。残るのは計画されていない活動です。誰も承認していないレジストリの編集、対応する変更リクエストがない設定変更、そして本来は監査やインシデントによって誰かが調べに行くまで見過ごされてしまうドリフト——それらが対象になります。

このクローズドループ（closed-loop）モデルでは、ServiceNow、BMC Remedy、Cherwell のような ITSM 統合を通じて、観測された変更を承認済みの変更と照合します。これにより、アクセスレビューだけでは得られないものがセキュリティ／コンプライアンスチームに提供されます。つまり、実際に何が起きたのか、いつ起きたのか、そしてそれが想定されたものだったのかをシステムレベルで記録した根拠です。さらに、PCI DSS、NIST、HIPAA、DISA STIG などのフレームワークに対応した 250+ の既成コンプライアンスレポートと組み合わせることで、「コントロールが機能していると考えています」を、監査人が実際に確認できる証拠へと変えます。

結局、責任は担当者（レップ）に押し付けられる

その Salesforce の連携が侵害されたり、アシスタントが意図した範囲を静かに超えてデータを取得したりした場合、インシデントレポートには AI ベンダー名は載りません。認証に使われたアカウント名と、それに紐づけられている人の名前が記載されます。Identity governance は、そのアカウントが触れてよいものに関するポリシーを設定できます。しかし、それだけでは「先週の火曜日にシステム上で実際に何が変わったのか」を自分で教えてくれるわけではありません。それは別の問いであり、誰かがその答えを見つけられるように監視し続ける必要があります。