AIエージェントが企業インフラに入り込みつつあります。信頼境界を移動させる必要があり、それを支えられるのがプラットフォームなのです。
セキュリティリーダーたちはこの10年間、人とコードを中心にコントロールを構築してきました。シフトレフトの取り組みは開発サイクルの早い段階で脆弱性を発見し、ゼロトラストは横方向への被害拡大を抑え、開発者向けツールはIDEにガードレールを追加してきました。この設計思想は、人間がコードを書き人間がアプリケーションを運用する企業にとっては理にかなったものでした。
しかし、そのような企業はもはや存在しません。
AIエージェントは、多くのセキュリティ組織が想定していたペースをはるかに超えて、研究プロジェクトから本番ワークロードへと移行しつつあります。エージェントは自律的に動作し、トークンやAPIを直接消費し、人間によるチェックポイントを経ずに意思決定を行い、誰かがあらかじめ要件として定めていない限り監査証跡すら残しません。
デプロイ前に開発者が問題を発見する責任を負うシフトレフトモデルでは、ライブの推論ストリーム内、モデルレジストリの内部、あるいはエージェントが実行時に下す判断の中で起きていることを捉えることはできません。
攻撃対象領域は新しく、ツール群はまだそれに追いついていません。そして「開発者側のコントロールをもう一つ追加する」という従来型の対応では、このギャップは埋まらないのです。
現行のツールが見落としているもの
AIを活用する企業において、既存のセキュリティツールが見落としている点を正直に棚卸ししてみましょう。
プロンプトインジェクションは、悪意ある指示をライブの推論ストリームに紛れ込ませます。SASTやDASTのツールはいずれもこれを検知できません。これらは静的なコードのために作られたものであり、動的なモデルとのやり取りやAIワークロードを想定していないからです。
モデルポイズニングは、署名や来歴の検証を行わずにレジストリからモデルを取得した際に発生します。多くの企業がすでにコード成果物に適用しているソフトウェア署名ワークフローに相当する管理策は、モデルには存在しません。
推論データの漏えいは、監査証跡も組み込みのコントロールも伴わないままモデルの応答を通じてPIIや知的財産を露出させます。これはネットワーク層やエンドポイント層に配置されたDLPツールにとって不可視の領域です。
シャドーAIの拡散とは、開発者やチームがデータガバナンスやDLPコントロールを完全に迂回する形で、承認されていないモデルを利用している状態を指します。
これらはいずれも仮説の話ではありません。セキュリティアーキテクチャを更新しないままAIワークロードの展開を始めた企業では、すべてが実際に進行中の問題なのです。
プラットフォームこそ最も包括的な信頼境界
この課題への対応は、手続き上のものではなくアーキテクチャ上のものであるべきです。プロンプトインジェクションはトレーニングだけでは防げませんし、モデルポイズニングは四半期ごとの監査だけでは防げません。これらの脅威に対処できるだけの範囲・深さ・強制力を備えたコントロールサーフェスは、プラットフォームそのものだけなのです。
プラットフォームエンジニアリング2.0では、プラットフォームレベルのAIセキュリティとデータプライバシーを運用可能にする4つのコントロールサーフェスが定義されています。
モデルガバナンス:来歴追跡、承認ゲート、ドリフト監視を備えたバージョン管理型のモデルレジストリです。本番環境にあるすべてのモデルには来歴の連鎖が存在し、署名チェックを経ないモデルはデプロイされません。
プロンプトセキュリティ:プラットフォームレベルでの入力サニタイズと出力フィルタリングです。インジェクション攻撃が推論パイプライン全体に広がるのを防ぐコンテキスト境界の強制を、アプリケーション層ではなくインフラ層で行います。
データの分離とプライバシー:保存時・転送時の暗号化を伴うテナントレベルのデータ境界に加え、PII検出やリアルタイムマスキングを含むDLPポリシーを推論パイプラインに直接組み込みます。データ取り扱いのためのパイプラインとガードレール、そしてプライバシーに関連するコントロールも欠かせません。
推論監査:説明可能性の出力とコンプライアンスレポートを伴う、あらゆるAI推論の完全な監査証跡です。ある時点のスナップショットではなく、人間とエージェント双方の行動をカバーする継続的かつリアルタイムの記録である必要があります。
これら4つを組み合わせることで、プラットフォームはAIにとっての信頼境界となります。セキュリティはインフラの奥深くに組み込まれ、デフォルトで不可視かつ不変な存在となります。設定は、開発者による個別設定を必要とすることなく、最小権限、mTLS、マイクロセグメンテーション、自動化されたシークレットローテーションを強制します。コンプライアンスは定期的なものから継続的なものへと変わります。
エージェントは新たなID問題である
エージェント型AIは、セキュリティチームが正面から向き合わざるを得ない課題、すなわち企業内で動作する新しい種類の非人間IDをもたらします。AIエージェントはインターフェースではなくAPIを消費します。エージェントには、範囲を限定した権限、非人間ID用の認証情報、予算管理、そしてアウトバウンド制御が必要です。ガバナンス上の主要な要素としては、エージェント発見のためのMCP互換API、エージェントの行動を事前承認されたパターンに制限するポリシーガードレール、意思決定の全過程を記録する監査ログ、そして不確実な判断を人間のレビュアーに回すエスカレーションの仕組みが挙げられます。
もし貴社のIDおよびアクセス管理戦略がエージェントIDをまだ考慮に入れていないのであれば、そこにはギャップが存在します。そしてそのギャップは、エージェント型の展開が拡大するにつれてさらに広がっていくでしょう。
これがCSOにとって意味すること
セキュリティは、開発者層だけでは構造的に対応しきれないものになりつつあります。システム内の唯一の主体が人間だった時代に機能していたコントロールは、エージェントが意思決定を下し、リソースを消費し、多くの場合人間の介在なしに最も機微なデータパイプラインとやり取りする環境では、もはや不十分です。
企業のAI展開におけるセキュリティ態勢は、大部分がプラットフォームエンジニアリング機能の成熟度によって決まることになります。これは、孤立して動くプラットフォームチームに委任してよい技術的判断ではありません。CSOの議題に載せるべきセキュリティアーキテクチャ上の判断なのです。
求められているのは具体的な行動です。プラットフォームエンジニアリングのリーダーシップと関わり、AIワークロードがどのようにガバナンスされているか、エージェントIDがどのように管理されているか、そしてモデルガバナンス・プロンプトセキュリティ・データ分離・推論監査という4つのAIセキュリティコントロールサーフェスがプラットフォームに組み込まれているのか、それとも各チーム任せになっているのかを可視化するよう求めるべきです。
もし答えが後者であるなら、それこそが貴社にとって最も急を要するセキュリティ上のギャップだと言えるでしょう。
AI時代のプラットフォームにセキュリティを組み込むための包括的なフレームワークについては、以下のホワイトペーターをご覧ください: Platform Engineering 2.0: An Evolution for the AI Era(BroadcomとPlatformEngineering.orgの共著)。
