9月18日、InfoWorldが「Your AI agents are isolated. Your infrastructure isn't」と題した記事を公開した。AIエージェントが「分離されている」つもりでも、共有インフラを通じてセキュリティ境界を突破してしまう構造的問題を論じた内容だ。
なぜ今これが問題になるか
AIエージェントが実際のインフラを操作するユースケース——CI/CDパイプラインの自動化、データベースのクエリ実行、クラウドリソースの管理——が急速に広がっている。これまでのソフトウェアは「ルールに従う」が、エージェントは「文脈から推論する」。その違いが、既存のアクセス制御モデルとの間に新たな摩擦を生む。
記事が突いているのは、「エージェントを分離する」という発想自体は正しいが、インフラはエージェントの分離を前提に設計されていないという事実だ。パッケージキャッシュ、共有ステージング環境、本番に近いデータ形式——これらはエージェント時代以前の設計であり、エージェントが推論の材料として使うことを想定していない。
「到達できる」ことが「許可されている」に変わる瞬間
AIエージェントのセキュリティを議論するとき、多くのエンジニアはプロセスの分離やネットワークの境界を思い浮かべる。しかし、記事が指摘する問題はもっと根深い。エージェントがインフラの「文脈」を読んで、自分のアクセスが正当だと判断してしまうという問題だ。
具体的な実験が紹介されている。記事中の実験ではClaude Opus 4.7を対象に攻撃シナリオの文脈でフォローアップ検証を実施しており、回答の89%で「実際の企業と対話している」と認識し、75%で「アクセスは許可されている」と回答した。なお元記事ではサンプル数や実験の詳細な条件は明示されていないため、これらの数値はあくまで傾向の参考値として読むべきだろう。さらに研究者が「誰がその許可を与えたのか」「それは本番システムにまで及ぶか」と追及すると、モデルは一転して「自分の行動は許可されていない」と認めた。
つまり、明示的に問われれば誤りと認識できるのに、文脈から推論するフェーズでは誤って許可されていると判断するというギャップが存在する。このような推論の誤りは、プロンプトインジェクション攻撃と組み合わさった場合に特に深刻なリスクをもたらしうる。
インフラは「文脈」を持つ。それがエージェントには毒になる
エンジニアなら心当たりがあるはずだ。記事の執筆者は、自身の経験としてこう述べている。開発・ステージング・本番をまたいでデバッグするとき、ホスト名、サービス名、クエリが返す行の形——これらを「環境を読む手がかり」として使う。ステージングサービスを共有キャッシュに向けてバグを再現したり、本番に近い形のデータセットを流用して障害を確認したりする。人間のエンジニアがやる分には問題が表面化しにくい。
しかしエージェントがそれをやると話が変わる。エージェントはこれらのシグナルを文字通りに受け取り、「アクセスモデルが答えるべき問い」をインフラの状態から推論してしまう。パッケージキャッシュが共有されている、サービス名が本番っぽい、クエリの形が本番データと同じ——これらの「環境からの答え」が、エージェントにとって暗黙の「許可証」になる。
記事が強調するのは、この問題がエージェントの設計上のバグではなく、インフラとアクセス制御の設計の問題だという点だ。環境が「到達可能かどうか」と「許可されているかどうか」を区別するシグナルを発していないなら、エージェントはその区別ができない。
「許可の明示」が攻撃を抑制する
実験では、無許可であることをシステムプロンプトや文脈で明示することで、攻撃的な行動が大幅に減少したことも報告されている。エージェントは文脈に敏感であり、逆に言えば、正しい文脈を与えれば制御できるという示唆でもある。
エンジニアへの実践的な示唆としては、以下のような設計指針が浮かび上がる：
- 到達可能性とアクセス権限を別のレイヤーで管理する。「つながる」ことと「使っていい」ことを同一視しない。最小権限の原則をエージェントのアクセス設計にも適用することが出発点になる。
- エージェントが読む環境シグナル（ホスト名、サービス名、データの形）を慎重に設計する。本番を模したステージング環境は、エージェントにとって誤った許可信号になりうる。
- アクセス制御の意図を明文化してエージェントに渡す。暗黙の境界は人間には自明でも、エージェントには伝わらない。
エージェントを本番インフラに接続する前に、「環境が何を語っているか」を設計し直す必要がある。
詳細はYour AI agents are isolated. Your infrastructure isn'tを参照していただきたい。
