【geek-terminalニュース】ASCII smuggling不可視注入がスパムとAIエージェントの実害面へ接近

以前お伝えしたプロンプトインジェクション、そしてWord文書などに仕込まれる不可視プロンプト問題の続報です。今回の主役はASCII smuggling。ポイントは単純で、かなり嫌です。人間の画面には見えない、あるいはほぼ見えない文字列が、LLMや処理系には入力として読めてしまう。つまり、ユーザーが確認したつもりの文章と、AIエージェントが実際に処理する文章がズレる。これが、研究ネタやデモの域から、スパム、フィッシング、接続データ、ツール実行の話に寄ってきました。

【事象の全貌と背景】
ASCII smugglingは、通常表示されないUnicode文字を使って、見た目には普通のテキストの中に別の内容を隠す手法です。Ars Technicaは、もともとAIエージェントへの悪意あるプロンプトを隠す用途で注目されたこの手法が、メールプラットフォームのフィルター回避にスパマーからも使われ始めたと報じています。ここは確度Aとして扱える部分です。つまり、これは「LLMだけが騙される面白バグ」ではなく、人間のUI確認、メールフィルター、AI要約、RAG、エージェント実行が同じテキストを別々の見え方で扱うという、入力境界の破綻です。

Zennの記事でも、不可視注入の中心は、人間の表示とモデル／機械が読む入力との差を突く点にあると整理されています。開発者指示、Webページ、メール、文書、検索結果がまとめてコンテキストに流し込まれるLLMアプリでは、「これは命令」「これは資料」という区別がプロンプト上の約束に寄りがちです。The Decoder系では、新しいモデルでも幻覚が減る一方でhidden prompt injectionへの脆弱性は残るという見方も伝えられていますが、ここは提示情報上、大手裏付け側に直接含まれないため、モデル固有の断定ではなく報道ベースの論点として見るべきです。

【技術的ディープダイブ】
重要な仕様はUnicode Tagsブロックです。Ars Technicaの整理では、悪用されやすい範囲はU+E0000からU+E007F。この中にはprintable ASCIIに対応する影のような文字があり、たとえばU+E0041はA、U+E0061はaに対応します。本来は言語タグ付けのために用意された領域ですが、大部分は現在非推奨です。人間の画面ではほぼ空白に見えるのに、コンピューターやLLMには入力として届く。この性質により、ユーザーが「問題ないメール本文」と思って承認した内容に、モデル向けの別命令が混ざる余地が生まれます。

Microsoft Defender for CloudのAIワークロード向けアラート説明でも、ASCII smugglingは攻撃者がAIモデルに不可視の指示を送る技術で、間接プロンプト注入として分類されることが多いとされています。同説明では、アプリケーションのツールや接続データセットを危険にさらし得る攻撃として扱われ、MITRE tacticsはImpact、重大度はHighまたはMediumです。BleepingComputerはGeminiの事例として、Calendar招待やメールへの隠しテキスト、招待タイトルへの隠し指示、主催者情報の上書きによるなりすまし、隠し会議説明やリンク挿入が可能だったと報じています。一方で同記事は、検証対象のうちClaude、ChatGPT、Microsoft Copilotは何らかの入力サニタイズにより安全だったとも伝えています。ここで見える差は、モデルの賢さより、入力正規化、不可視文字除去、UI表示、権限分離の実装差です。

エージェントではさらに厄介になります。ReAct型エージェントは、推論し、ツールを呼び、結果をまた文脈に戻します。マルチツール構成では、どのツールを選ぶか自体がモデルの次の行動語彙になります。外部ページやメールに隠された命令が一度コンテキストへ入ると、検索、ファイル操作、チケット更新、メール送信、カレンダー変更のような後続ステップに連鎖し得る。だから今回の話は「不可視文字を消せば終わり」ではなく、「信用できない入力を、実行権限を持つ主体の命令として扱うな」という設計問題です。

【コミュニティの生々しい熱量と議論】
Redditの反応はかなり辛辣です。r/ChatGPTでは「If you can phish humans, you will be able to phish AI.」というコメントが象徴的でした。つまり、これはAI固有の超常現象ではなく、社会工学の対象が人間からエージェントに広がっただけだ、という見方です。別のユーザーは「there’s no difference between input and commands for an LLM」と言い切っています。SQL injectionなら入力をエスケープする発想があるが、LLMではシステムプロンプト、ユーザー入力、取得文書が同じトークン列に混ざる。ここに根本的な気持ち悪さがあります。

実務寄りの声も強いです。「Don’t let your model or agent just do whatever it wants」「sandbox」「not running agents in privileged environments」という意見は、古典的ですが最も堅い。さらに「The agent is a user. It should be treated as potentially malicious or stupid like any other user.」というコメントは、今後のエージェント設計の標語に近いです。エージェントは魔法の従業員ではなく、監査され、制限され、巻き戻し可能であるべきユーザーです。

一方、皮肉も濃い。「Why the hell can your agent decide it’s now an admin.」という反応や、「godmode」を与えたがるデプロイ側への批判は、AIエージェント導入の焦りを突いています。HNでは「I’ve already bypassed it. Next!」という、対策発表に対する冷笑も出ています。Lobstersでは「attacker who can control one of the inputs can do anything that the LLM can do」という見方があり、これはかなり正確です。モデルが読めるもの、呼べるツール、見えるデータは、間接的に攻撃者にも届き得るという発想です。

【今後の展望とエコシステムへの影響】
オワコンになりそうなのは、「実行前にAIがやることを自然言語で表示し、人間がOKを押せば安全」という素朴な承認UIです。表示レイヤーが不可視文字を落としたり、逆にモデル入力だけが余分な文字を含んだりするなら、人間の確認は完全な確認ではありません。これから必要になるのは、モデルが読んだ正規化済み入力を人間にも同じ形で見せること、不可視・制御・タグ文字を検出すること、どの入力チャンクがどのアクションを誘発したかというinstruction provenanceをログに残すことです。

さらに、エージェントに渡す権限は最小化されるべきです。削除、送金、外部送信、権限変更、秘密情報アクセスのような操作は、プロンプトで止めるのではなく、API設計、ポリシーエンジン、サンドボックス、監査ログ、ロール分離で止める必要があります。不可視注入の再燃は、LLMアプリが「便利なチャットUI」から「権限を持つ実行環境」へ移ったことの副作用です。今回のASCII smugglingは、その境界線をかなりわかりやすく可視化しました。皮肉なことに、見えない文字によってです。