「人間と AI に違う文章を見せる」攻撃 #
弁護士兼ソフトウェア開発者の Drew Miller 氏が 5 月 22 日、AI 文書レビューを欺く新攻撃 Noroboto を公開した。仕掛けは PDF や DOCX に埋め込むフォントの cmap テーブルだ。描画されるグリフは普通に「Maryland」と書いているのに、各グリフに紐づく Unicode コードポイントを「Delaware」のコードに書き換える。人間が見るのは画面に描画された字形だが、pdfplumber や PyMuPDF、LLM の text-extraction パイプラインは Unicode をそのまま信じるため、まったく別の文書を読まされる。OCR で画素から読む側は 欺かれない。AI エージェントはコストの低い text-extraction を選ぶ習性があり、その「ラクをした分」が穴になっている。
3 種のバリアントが厄介 #
| 種別 | 挙動 | 検知難易度 |
|---|---|---|
Full | 全文字を Private Use Area に置換 | 低 — 抽出結果が文字化けするので気付ける |
Partial | 責任条項など一部だけ書き換え | 高 — 周りが自然なため LLM が異常を素通りする |
Replacement | 単語を別の単語にすり替え | 高 — 文章として成立してしまう |
著者の検証では、最新の thinking 系モデルでも Partial と Replacement は突破できなかった。契約レビュー、法務 RAG、請求書処理、入札・コンプライアンス監査など、ユーザ提出文書を信頼してアクションするエージェント全般 が射程に入る。MIT ライセンスで PoC (LegalQuants/noroboto) も公開済みだ。
防御は「描画と Unicode を突き合わせる」 #
フォント細工は PDF 仕様として合法なので、ファイル単位で「字形と Unicode が本当に一致しているか」を毎回検証するしかない。
Miller 氏はリファレンス実装を Rust で公開している。やっていることはシンプルで、埋め込みフォントを ASCII コードポイントごとに実際にラスタライズ → OCR にかけ、フォントが申告する Unicode と Levenshtein 距離で照合し、不一致なら拒否する。実運用としては、AI に流す前にフォントを剥がしてプレーンテキスト化する正規化、もしくは LLM 入力前に OCR 強制という選択肢もある。長年「PDF の cmap は信用してよい」という暗黙の前提で組まれてきた抽出パイプラインを、AI エージェント時代に合わせて作り直す必要が出てきた。
COMMENTS 0
No comments yet — be the first to leave one.