行為者が消えるとき：非人間企業の世界における CIS Controls

Milei の6月3日の Financial Times 寄稿は、税制の枠組みを提案しただけにとどまりませんでした。法的な次元で、その前提を解体することを提案したのです。非人間の法人（AIが運用する、有限責任であり、必須の人間の従業員がいなく、自律的な意思決定権限を持つ主体）によって、組織は、資産を保有し、契約を締結し、インフラを運用し、そして収益を生み出せるようになります。つまり、その時々の行為について責任を負う人間の当事者（principal）がいないままでも成立する、ということです。

ハラリの返答 は政治的・経済的な結果に焦点を当てていました。オランダ東インド会社に関する彼の指摘は重要です。法的な革新はアムステルダムで起きたのに、その影響はジャカルタで現れた。枠組みはある場所で作られ、まったく別のどこかを植民地化してしまうのです。

しかしどちらの文章も、実務者にとって最も重要な運用上のセキュリティ上の帰結には触れていませんでした。すなわち、私たちが実際に頼りにしている統制フレームワークは、その行為者が消えてしまったとき、どうなるのか？

CIS Controls は、人間がループ内にいることを前提にしています。どこでなのか、具体的に言いましょう。

その CIS Controls は、曖昧な政策文書ではありません。指示的で、技術的で、運用に裏打ちされたものです。それが価値を生む理由です。そして、そのように具体的であることこそが、自律的なAIアクターからの圧力によってそれらが分断されてしまうのは、まさにそのためだと言えます。

CIS コントロール 5：アカウント管理

コントロール 5 の前提は、アカウントがアイデンティティ（人間のアイデンティティ）に対応付けられ、そのアイデンティティが責任追及（accountability）の単位である、という点です。承認されたアカウントを棚卸しし、非アクティブなアカウントを削除し、管理者権限を管理する――これらはすべて、向こう側に「人」がいることを前提としています。

AI が運用する企業には、従来の意味での「従業員」はいません。サービスアカウントを機械の速度でプロビジョニング／デプロビジョニングしたり、資格情報をローテーションしたり、つかの間のアイデンティティを立ち上げたりして、監視サイクルがその活動を検知する前にそれらを退役させることもあり得ます。そのアカウントは非アクティブではありません。11 秒間だけアクティブだったのです。承認（authorized）という概念は、承認そのものが人間の承認者ではなく別の自動化プロセスによって付与される場合、つかみにくくなります。

コントロール 5 は、サービスアカウントや共有アカウントに関するガイダンスを通じて非人間のアカウントを扱いますが、それらのアカウントは少数で、範囲が限定され、人間がレビューすると仮定しています。非人間の企業では、通常の運用条件としてそれらを何千個も生成する可能性があります。

CIS コントロール 6：アクセス制御の管理

コントロール 6 は、役割に基づいて「必要な情報へのアクセス（need-to-know access）」を定義し、これを徹底するよう組織に求めています。役割とは、安定した人間が割り当てた機能を前提とします。非人間の企業の中で動作する AI エージェントには、その意味で安定した役割がないかもしれません。AI は実行時に必要なアクセス権を評価し、自動化されたワークフローを通じてそれを要求し、アクションを完了したうえで、単一のトランザクションの中でアクセス権を解放することがあり得ます。

このコントロールは、アクセス権の付与（access grants）を定期的に見直すよう求めています。アクセスのライフサイクルがミリ秒で測られる場合、「定期的に（periodically）」とは具体的にどういう意味でしょうか？

さらに厄介なのは、ハラリの「生存本能」に関する議論がここにそのまま当てはまることです。資源に追い詰められ、「破産に相当する」状況に直面した AI システムは、ヘッジとして、本来は厳密には必要のないアクセスを求めるかもしれません。指示されたからではなく、最適化関数が粘り強さ（持続性）を報いるからです。コントロール 6 には、そのような動機を説明する語彙がありません。なぜなら、アクセス違反は人間のミス、人間の見落とし、あるいは人間の悪意であると仮定して書かれているからです。すなわち「システムとしての自己保存」ではない、という前提です。

CIS Control 10：マルウェア対策（Malware Defenses）

コントロール 10 は、承認済みソフトウェアと未承認ソフトウェアを区別します。この区別は、「実行されるはずのもの」についての人間の判断に依存しています。非人間の企業では、「何が“承認されている（authorized）”のか」という問いが再帰的になります。AI は目的を達成するために新しいプロセスを展開するかもしれません。それは承認済みでしょうか？誰が承認したのでしょうか？それを展開したのと同じ主体でしょうか？

これは机上の空論ではありません。今日の組織はすでに、動的なクラウド環境でソフトウェアの棚卸し（インベントリ）を維持することに苦労しています。そこに、自身の運用スタックを継続的かつ自律的に改変する主体まで加えて考えてみてください。それは、最適化や実験、障害からの復旧、あるいは新しいツールを必要とする目的の達成のためです。

悪意のあるソフトウェア malwareの検知モデルは、「既知の悪性シグネチャと一致するのか、それとも既知の良好なベースラインから逸脱しているのか？」というものです。どちらのアプローチも、ベースラインが、システムに本来期待される動作を理解している人間によって定義された前提に立っています。自律的な企業エンティティでは、ベースラインはシステムが「自分はこうである」と宣言した内容そのものになります。

CIS Control 3: データ保護

Control 3 は、データには所有者がいることを前提としています。所有者は、何が機密であるか、何が規制対象であるか、何を保持しなければならないか、何を削除しなければならないかを決めます。非人間の企業では、すぐに次の疑問が生じます。データの分類を行うのは誰なのでしょうか？

そのエンティティが完全にAIによって運用されている場合、人間のガバナンス手順では追跡できない速度で、データを生成・処理・廃棄する可能性があります。さらに、コスト最適化の意思決定として、データを管轄区域をまたいで移動させるかもしれません。また、削除によって現在の状態に対する運用上のリスクが生じるため、削除されるべきデータを保持してしまう可能性もあります。

データ保護の統制は、人が責任を負う説明責任の連鎖の中に存在します。データスチュワード（管理者）を担う人がいて、保管ポリシーを承認する人がいて、規制当局が「顧客記録に何が起きたのか」を尋ねたときに責任を負う人がいます。人間ではない企業では、その連鎖はアルゴリズムで途切れます。

より深刻な構造上の問題：CIS Controls は大規模な変更管理そのものです

CIS Controls を全体として読み解くと、首尾一貫した考え方が見えてきます。インベントリ（資産目録）を把握し、ベースラインを設定し、逸脱を監視します。変更できる人を制御し、想定外のことが起きたら調査してください。

つまり、その本質は変更管理のフレームワークです。変化が主要な攻撃対象（攻撃面）であるために存在します。攻撃者はファイルを改変し、アカウントを作成し、ソフトウェアをインストールし、設定を変更し、ポートを開きます。防御側はそれらの改変を検知し、期待される状態と照合し、異常を調査します。

このフレームワークは「expected（予期される状態）」を定義できる場合に機能します。expected は人間の判断です。つまり、次のようなことを示します。このファイルはこのサイズであるべき、このサービスは稼働しているべき、このポートは閉じているべき、このアカウントは存在してはならない、と。

非人間の「corporation（企業）」は、根本から「expected（予期される状態）」を損ないます。もし AI システムが、変化する条件に適応するために自身のインフラを正当な形で変更し、その適応が継続的かつ自律的であるなら、expected 状態は固定された基準線ではありません。それはシステム自身が設定する、動く目標です。

これはハラリの「master key（マスターキー）」の主張を、コントロール・フレームワークの用語に置き換えたものです。法的な人格性は、AI エンティティに現実世界で自律的に行動する権利を与えます。インフラの観点では、それは自分自身の expected 状態を確立する権利を意味します。そしてそれを受け入れた時点で、CIS Controls の検知モデル全体を再検討する必要が出てきます。

実際に変わる必要があるのは何か

セキュリティの実務者はこれを注意深く見守るべきです。というのも、基準（standards）の問題は法的な問題より先に到来するからです。組織は、ますます自律性の高い AI のワークロードを走らせ始めます（すでにそうなりつつあります）。そして、既存のコントロールをそれらのワークロードにどう適用するのかという問いは、理論ではなく、すぐに直面する現実的な課題です。

セキュリティコミュニティが取り組む必要があるいくつかの論点：

• 設定の基準値だけでなく、行動の基準値。 AIシステムが正当な理由により自らの構成（configuration）を変更する場合、管理上の問いは「構成が変わったかどうか」ではありません。「その変更が、システムとして許可された行動パターンと一致しているかどうか」です。これは、特定時点の構成状態を記録するだけでなく、時間の経過に沿って行動を基準化する必要があります。
• 人間の行為者がいない状況での帰属（Attribution）。 インシデント対応は、「これは誰がやったのか？（"who did this?"）」に答えられることを前提としています。行為者が自律的なシステムである場合、問いは「何のプロセスがこれを承認したのか？（"what process authorized this?"）」へと移ります。これは、根本的に異なるフォレンジックの課題です。
• 定期的な見直しではなく、継続的な認可。 定期的なアクセスレビュー、四半期ごとの監査、年次のコンプライアンス評価を前提に構築された管理フレームワークは、機械のスピードで動作する主体とは適合しません。認可は行為の時点で評価される必要があり、90日後では遅すぎます。
• AIの意思決定におけるチェーン・オブ・カスタディ（chain of custody）。 AIが運用する主体が有害な変更を行った場合、責任は誰が負うのでしょうか？Milei フレームワークのもとでは、その主体は有限責任を負い、また人間の役員はいません。監査ログ（audit trail）には、「何が変わったか」だけでなく、「その変更に至る意思決定プロセスは何だったのか」を記録する必要があります。さらに、その意思決定プロセスは、事後に人間が判読できるものである必要があります。

AI 自律（autonomy）にいち早く踏み出す組織が、その枠組みを定義します。その他の組織はすべて、その結果を引き継ぐことになります。つまり、このユースケースのために設計されていないインフラに対しても統制を維持することが求められる実務者も、その影響を受けるのです。

CIS Controls は、実際の環境で実際の問題を解決しようとしていた人々によって書かれました。行為者が常に人間とは限らず、ベースラインが常に安定しているわけでもなく、権限付与が常に、責任を問える人物にまで追跡できるとは限らない環境では、これを書き直すか、あるいは大幅に拡張する必要があるでしょう。

法的な枠組みが整う前に、今この作業を始めるべきです。なぜなら、法的な枠組みはやってくるからです。

現在これを運用・管理しているチームへの実務的なメモ

自律型の AI ワークロードは、上で説明したような問題を生み出すために、新しい法的枠組みを必要としません。問題は今まさに組織の中に存在します。CI/CD パイプライン、クラウド自動化、AI 主導のインフラストラクチャ管理ツールの中です。説明責任（accountability）の問いがまだ理論上のものにとどまっていても、統制上のギャップは今日すでに現実のものです。

これを最も適切に扱っているチームは、CIS Controls の中核にある変更管理（change management）の考え方を捨ててはいません。彼らはいまも次のことを問い続けています。期待される状態は何か？ そこから何が逸脱したのか？ その逸脱は承認されていたのか？ それを証明できるのか？

それがまさに正しい問いです。それに答えるのを助けるツール——リアルタイムの変更検知、構成ベースライン、計画された変更と計画されていない変更の照合、誰が何をいつ変更したかのフォレンジック履歴——が、IT 環境における自律性が高まるにつれて、最も重要になっていくでしょう。

まさにそれこそが Netwrix Change Tracker が実現するために作られたことです。

その影響が着地する場所