AIセキュリティはエンジニアリングの課題であり、強制可能な境界や責任者、保護の証拠を必要とする

AIセキュリティはエンジニアリングの課題であり、それは、定義されたセキュリティ要件、強制可能な統制、指名された責任者、そして保護が機能している証拠を意味します。AIの能力が進展するペースが圧力を生んでおり、組織はAIの生産性向上の恩恵を求める一方で、こうしたシステムを統制し保護するための実践はまだ発展途上です。

AIがより高機能になるにつれ、業界はセキュリティエンジニアリングを加速させ、防御ツールへのアクセスを広げ、有効な手法をより速く共有しなければなりません。インターネットとクラウドコンピューティングはソフトウェアの動作の仕方を変えましたが、ID の確立、アクセスの制御、攻撃にさらされる範囲の限定、保護が機能していることの検証という中核的なセキュリティ上の責任は変わっていません。

AIエージェントと確立された原則の適用

AIエージェントは、推論すること、ツールを使うこと、そして遭遇したデータに基づいて行動を適応させることという新しい能力をもたらします。これらの推論・ツール使用・行動の適応という能力には、確立された原則を新しい運用条件に適用することが必要となります。アプリケーションはコード、データ、ID、サービス、インフラストラクチャに依存しており、セキュリティはこれらコンポーネントがどのように連携して動くかに左右されますが、AIエージェントはそのシステムを拡張する存在です。

エージェントスタック(agent stack)では、モデルが能力を提供し、ハーネス(harness)がコンテキスト・ツール・ワークフローを整理し、ランタイム環境が、行動の実行されるインフラストラクチャを提供します。スタックの各部分にはセキュリティ上の責任があり、データ、指示、行動がシステム内を移動していく中で、適切な保護には各層にわたる統制が必要です。

強制可能な境界とエージェントの権限管理

例えば、顧客レコードを更新するエージェントが、添付文書の中に悪意のある指示を見つけ、顧客データを許可されていない送信先へエクスポートしようとする場面を想定します。顧客レコードを更新する権限は、そのデータをエクスポートする権限に自動的に広がるべきではありません。エージェントは追加のアクセスを要求できますが、そのアクセスを自分自身で認可することはできません。このエージェントが悪意のある指示に従って顧客データを許可されていない送信先へエクスポートしようとした場合、ネットワークポリシーが転送をブロックすべきです。また、保護されたログが、試みられたツール呼び出し、認可の判断、結果を記録し、セキュリティチームが使われたツールと到達しようとした送信先を特定できるようにすべきです。指示とセーフガードはエージェントの振る舞いを導く助けにはなりますが、セキュリティには強制可能な境界(enforceable boundaries)も必要です。

セキュリティ境界は、エージェントが誤った判断をした場合でも維持されなければなりません。エージェントが動作する環境がそのエージェントに許されることを決めるため、ファイル、ネットワーク上の送信先、プロセスに対する制限を、エージェントの推論とは独立に設ける必要があります。

各エージェントには、追跡可能なIDと、割り当てられたタスクに限定された認証情報が必要です。組織は、エージェントがアクセスできる情報、変更できるシステム、承認が必要な行動を定める明確なポリシーを必要とし、その境界の中でも、重大な結果をもたらす行動と権限の変更には人間の承認が必要です。

チームは、エージェントが使うツール、スキル、依存関係の出所と完全性も検証する必要があります。問題が起きた場合、ツール呼び出し、認可の判断、結果の保護された記録は、調査担当者が何が起きたかを再構成する助けになります。アクセスの取り消しとインシデントの封じ込めの明確な手順があることで、その証拠が実際に活用できるものになります。

NVIDIA OpenShellは、オープンソースのセキュアなランタイムです。OpenShellは、ポリシーをエージェントの手の届かない場所で強制し、サンドボックス化された実行を提供するとともに、エージェントがデータ、ネットワーク、システムのリソースにどうアクセスするかを統制します。Open Secure AI Allianceのパートナーは OpenShell を土台に構築を進めています。CiscoのDefenseClawはガバナンス層を追加し、JFrogは OpenShell と統合して、エージェントのスキルをスキャン・検証し、エージェントがアクセスできるスキルに関するポリシーを強制します。

デプロイ前のテストと責任者の判断

デプロイ前に、チームはエージェントの権限範囲を超えた認証情報の取得の試みや、機密データを許可されていない送信先へ送る試みを、適切な制御がブロックすることを示す証拠を必要とします。また、エージェントのセキュリティテストは、権限を変更しようとする試みや監視を妨害しようとする試みも対象にすべきであり、モデル、ツール、ワークフローに重要な変更があった後に繰り返すべきです。

指名された責任者は、テスト結果を使ってシステムがデプロイ可能かを判断し、失敗したテストが是正措置につながるようにしなければなりません。テストや運用で見つかった失敗は、再現し、調査し、対処すべきです。各発見事項は再現可能なテストにでき、そうすれば修正が今後のリリースでも有効であり続けることをチームが確認できます。

証拠づくりのツールの例として、CrowdStrikeのSafeMindは繰り返しの攻撃シミュレーションで防御をテスト・強化するために使われ、Palo Alto Networks Prisma AIRSはモデルやアプリケーションが変わる中での継続的なレッドチーミング(red teaming)に使われます。

オープンモデルと防御側ツールの活用

高性能なAIは、脆弱性の発見、修正の検証、攻撃の調査を支援できます。その価値は、再現可能な発見事項、検証可能な修正、対応時間の短縮で評価すべきです。

失敗の調査には、タスク、データ、環境に適したツールが必要です。クローズドモデル(closed models)はマネージドな機能とサービスを提供する一方、オープンモデル(open models)は、防御側に、関連コンポーネントを検査し、戦略を適応させ、自分たちが管理するインフラ上で作業する選択肢を与えます。オープンモデルとクローズドモデルは、互いに補い合うニーズに応えます。

インシデント発生時、オープンモデルによって得られる制御権は、チームが失敗を再現し、自分たちのシステムに対して修正をテストするのに役立ち、機密性の高い証拠を自分たちの環境内にとどめられます。何が失敗したか、どの制御が機能したか、修正がどう検証されたかの証拠を共有すると、他のチームが自分たちのシステムを強化するのに役立ちます。

防御側ツールの例として、Capital OneのVulnHunterはAIによるコードセキュリティに使われ、ReversingLabsのSpectra AssureはAIによるソフトウェアパッケージ分析でマルウェアや改ざんを検出するために使われます。NVIDIAのセキュリティ研究とOpen Secure AI Allianceは、何が失敗し、どの制御が機能し、修正がどう検証されたかという証拠の共有を伴う交換を、研究、実用的なツール、専門知識をより広いセキュリティコミュニティに持ち込むことでサポートしています。

AIセキュリティはエンジニアリングの課題(engineering problem)です。あらゆるエージェントのデプロイには、強制可能な境界、責任を負う責任者、そして保護が機能することの証拠が必要であり、オープンな研究と共有ツールは、より多くの防御側がこの要件を満たし、能力の進歩に合わせてその水準を高めるのに役立ちます。