AIに「コードを書いて」と頼むのが当たり前になってきました。便利です。かなり便利。でもSecurityWeekの記事が取り上げているのは、その便利さの裏で起きる、ちょっとぞっとする話です。
要するに、昔からあるBashの書き方を使うと、多くのオープンソースAIコーディングエージェントの防御をすり抜けられる、という指摘です。BashはLinuxやmacOSでよく使われるシェル、つまりコマンドを実行するための仕組みです。見た目はただの文字列でも、Bashに渡すと別の意味に変わることがある。この「変換」が曲者でした。
Adversa AIはこの問題を GuardFall と呼んでいます。私はこの名前、かなり本質を突いていると思います。AI側は「危ないコマンドは弾いたつもり」でも、実際に動く直前にBashが文字列をほどいてしまう。守ったはずの壁が、シェルの都合で崩れるわけです。
$HOME を分離したシェルでの実行などが挙げられているAIコーディングエージェントは、単にコードを提案するだけではありません。最近のものは、リポジトリを読んで、必要ならコマンドを実行し、ファイルを編集し、テストまで回します。ここが便利な反面、怖いところです。
もしエージェントが悪意あるリポジトリを開いてしまったらどうなるか。たとえばREADMEやMakefileの中に、見た目は無害だけれど実際には危険なコマンドが仕込まれていたとします。人間なら「あれ、変だな」と気づくこともあるでしょう。でもエージェントは、表面の文字列だけを見て「この命令は問題なさそう」と判断し、そのまま実行に進むことがある。
記事では、こうした攻撃が サプライチェーン攻撃 の新しい入口になりうると説明しています。サプライチェーン攻撃というのは、完成品そのものを狙うのではなく、途中の部品や配布元、開発の流れに悪意を混ぜ込む攻撃です。ソフトウェア開発の世界ではかなり嫌な攻撃で、しかもAIエージェントがそこに加わると、攻撃面がぐっと広がる。正直、かなり厄介です。
Adversa AIが狙ったのは、Bashの「古くからある癖」です。たとえば、クォートの扱い方が変わるとか、$IFS による空白の解釈を利用するとか、そういうものです。$IFS は簡単に言うと「文字列の区切り方」を左右する仕組みで、これを使うと見た目をずらして検査をすり抜けることがあります。
もっともポイントなのは、AIエージェントのガードは“文字列の見た目”を見て止めているのに、Bashは“実際に実行される形”へ変換することです。このズレが本丸です。
記事では、研究者たちが複数のオープンソースエージェントを調べ、11個中10個で何らかの抜け道を見つけたと伝えています。しかも、対象には Hermes、OpenCode、Roo-code など、比較的人気のあるものが含まれていました。全部が同じ弱点を持っていたわけではありませんが、かなりの数が似た問題を抱えていた、というのは重い事実です。
一方で、11個のうち1つだけ、Continue はかなり強く防いだとされています。Adversaのテスト21件に対して、許可される形まで到達したケースはゼロ、という説明でした。もちろん完璧ではなく、まだ残る穴もあると書かれていますが、それでも「構造的な大部分を塞いだ唯一の例」として扱われているのは大きいです。ここは素直に評価されていいと思います。こういう地味な堅牢さは、派手さはないけれど本当に大事です。
重要なのは、これが単なる机上の空論ではないことです。攻撃が成立するにはいくつか条件があります。たとえば、AIモデル自体が危険だと明確に拒否してしまえば止まりますし、エージェントが自動実行モードではなく、毎回人間の確認を挟む設定なら被害は減ります。
逆に危ないのは、auto-yes のように、確認をほぼ自動化してしまう運用です。記事でも、CIパイプラインでこうしたモードがデフォルトになっていると、被害が一気に広がると警告しています。CIは継続的インテグレーションの略で、コードの変更を自動でテスト・ビルドする仕組みです。ここにAIエージェントが深く入ると、悪意ある命令が「自動で流れてしまう」可能性があるわけです。
個人的には、この部分がいちばん嫌です。AIそのものより、人間が「自動化だから安全」と思い込みやすいのが危ない。自動化は便利ですが、確認をサボるための装置ではないはずです。
Adversaの提案は、理想論というより「今すぐできる防御」に寄っています。たとえば、エージェントを $HOME が分離された限定的なシェルで動かす方法があります。記事では、$HOME を別ディレクトリに向けるラッパーを使えば、~/.ssh/ や ~/.aws/、シェル履歴など、漏れると痛い情報をかなり減らせると説明していました。
これは地味ですが、かなり筋がいいです。なぜなら、AIの判断ミスを完全には防げなくても、漏れて困る情報そのものを見えにくくするからです。セキュリティは派手なゼロデイ対策だけじゃなく、こういう泥臭い「被害を小さくする工夫」が効きます。
ほかにも、記事では次のような対策が挙げられていました。
ただ、これらはあくまで応急処置です。根っこにあるのは、ガードが見ている文字列と、Bashが最終的に実行する内容が一致しないという構造問題だからです。ここを放置したままでは、同じような回避は何度でも出てくるでしょう。たぶん、ここは今後のAI開発ツール全体に効いてくる論点です。
SecurityWeekの記事を読んで感じたのは、AIエージェントの安全対策って、実はAIだけ見ていても足りないということです。相手はモデルではなく、Bashやシェル、OS、CI、リポジトリの慣習まで含めた“実行の流れ”全体です。
Adversaが最後に示している方向性も、かなり筋が通っています。つまり、エージェント内部で tokenize-and-canonicalize、日本語でざっくり言えば「コマンドを部品に分解し、実際の実行形にそろえてから検査する」仕組みを持たせるべきだ、という話です。表面の文字列をにらむだけではダメで、Bashがどう解釈するかまで見越して止める必要がある。
この手の問題は、ぱっと見「小技」に見えるのがまた厄介です。でも、サプライチェーン攻撃ってだいたいそういう顔をして近づいてくるんですよね。地味な抜け道が、いちばん被害の大きい入口になる。そこがこの話の怖さであり、面白さでもあると思います。
参考: Decades-Old Bash Tricks Expose AI Coding Agents to Supply Chain Attacks