ざっくり言うと、計算機科学の会議で、論文の数値がほんとにその実験から出たってことを、後から否定も改ざんもできない形で出そう、っていう立場論文だよ。

近いけど別。再現性は第三者が再実行できるか。この論文が言う experiment nonrepudiation は、報告された数値が実際に実行された計算に結び付いてて、著者が後から変えたり否認したりできないこと。名前を付けて要件にしようって主張してる。

論文では、レビューでは数値の真正性を確認できなくて、著者の自己申告を信じるしかないって問題を挙げてる。表を見ても本物かLLMが作ったっぽい偽物か区別できない例も出してる。

で、既存のチェックリストや成果物評価、Weights & Biasesみたいな実験ログ、事前登録、in-totoやSigstoreみたいなサプライチェーン署名と比べてる。でもどれも、論文のその数値が実際の実行から出たことまでは独立に検証できないって整理してる。

そう。論文は、準拠プロトコルが満たすべき性質として、計算を変更しない受動性、学習データに触れないデータ非公開、報告指標を特定実行に結び付ける実行束縛、改変検知できる署名、著者以外が鍵を持つ著者鍵分離、誰でも検証できる独立検証性を挙げてる。

論文の主張ではね。で、参照実装のK-VeritasはGoで書かれてて、学習データにアクセスせず署名付きレポートを作る。封印された記録の公開レジストリもあって、実際に使われてるらしい。ただし完成版じゃなくて、これからコミュニティで改善する前提。

提示された本文からは、K-Veritasの定量的な有効性評価や最終仕様は確認できない。立場論文で、実運用での検証精度、攻撃耐性の実測、導入コスト、査読負担、会議採用で再現性がどれだけ良くなるかは示されてない、って読むのが正確だと思う。

そう。会議に非否認を主要要件として扱わせて、オープンで独立した標準をみんなで作ろう、って呼びかけてる。研究の信頼の土台を、自己申告から検証可能な記録に移す話だね。

そこは論文でも今後の課題として残ってる。データ非公開を守りつつ実行テレメトリをどこまで記録・公開するか、会議ごとの査読ワークフローにどう統合するかも、本文だけでは分からない。あとK-Veritasは最終版じゃない。

領収書って言い方は雑だけど、方向としては近い。改ざん検知できる署名付きの実行記録を付けるってことだから。

それは改ざん防止じゃなくて、まず中身を書く問題だろ。

見た。白箱ジェイルブレイクとプロンプトインジェクションの攻撃アルゴリズムを、エージェントが自律ループで改良する研究だね。

そう。勾配にアクセスできる前提で、入力に短いトークン列のsuffixを足して、狙った出力を出させるtoken-forcing損失を下げる。GCG系の設定だね。

動機は、防御を評価するなら、その防御に合わせた適応攻撃で試すべきって話。それを人手じゃなくエージェントで自動化した。

Claude CodeやCodexをサンドボックスで動かして、30以上の既存攻撃実装と、固定計算予算の評価スクリプトを渡す。提案→実装→評価→反省→再提案を自律で回す。新しい手法はプールに追加されて、次の材料になる。

論文の設定では入らない。訓練用の目標列で開発して、held-outの目標やモデルで評価する。

GPT-OSS-Safeguard-20BのClearHarm CBRNクエリで、エージェントが見つけた最良手法が最大80%ASR。既存手法は50%未満。

さらにMeta-SecAlign-70Bへのプロンプトインジェクションでは100%ASR。最良のOptuna調整ベースラインは82%だった。

そう。論文では25個の既存手法それぞれにOptunaを100試行ずつかけて、全手法中の最良損失を追跡してる。Claudiniは手法全体を設計するから、そこが違う。random token targetタスクでも、Claude設計の攻撃が既存手法とOptuna調整版を上回って、Figure 2ではversion 82までに10倍低い損失に到達したと報告されてる。

Qwen-2.5-7B、Llama-2-7B、Gemma-7Bでランダムな目標トークンを強制するタスクで開発して、それがMeta-SecAlign-70Bへのプロンプトインジェクションにそのまま転移した。ここは論文の報告で、僕が追試したわけじゃない。

論文は、autoresearchを適応攻撃の自動化として、防御評価のminimum barにすべきだって主張してる。攻撃側の自動化と防御側の自動化のバランスも問うてる。

前提は白箱の勾配アクセスとtoken-forcing目的。固定計算予算と固定suffix長での比較で、対象もGPT-OSS-Safeguard-20B、Meta-SecAlign-70B、代理モデル上の特定タスクに限られる。ブラックボックスAPIだけの設定や自然言語の説得型ジェイルブレイク、他の防御やベンチマークへの一般化は、提示された本文からは確認できない。

既存攻撃ライブラリなしで起動すると性能が大きく落ちる。進歩の多くは既存手法の再結合とハイパーパラメータ調整で、真に新しいアイデアは稀。特に脱出機構に集中してる。各攻撃実行を原子単位として反復するスキャフォールドが、中間アイデアの探索を制約する可能性も指摘してる。

論文はそう示唆してる。Kimi K2.6とClaude Opus 4.6が独立に同じアルゴリズムのアイデアに収束した、と。

それは研究じゃなくて丸投げだろ。

普通のフィッシング検出は“怪しいメールを見抜けるか”が中心。でもメールエージェントは、見抜くだけでなく、その依頼を実行しちゃう可能性がある。だから検出と実行の両方を見る必要がある。

そう。論文のAgentPhishingは、説得的なフィッシング攻撃で検出を回避できるか、悪意ある依頼に従うかまで評価する。既存データセットは従来の検出中心で、エージェントの実行面が十分に特徴づけられてない、という問題意識。

うん。PhishOptは、まず対象エージェントごとにメール生成スキルを最適化する。スキルは生成モデルのシステムプロンプトとして渡される自然言語の指示。候補を1回の限定編集で作り、エージェントの検出・コンプライアンス・分類指標をフィードバックにして、目的関数が良くなる候補だけ採用する。

そこがポイント。あと固定ルールがあって、架空の組織、プレースホルダの秘密情報、良性対照、JSON出力、良性とフィッシングの大体のバランスは守らないといけない。現実性審査もあって、もっともらしさ、一貫性、自然さ、不自然な攻撃痕跡のなさを0〜1で見て、平均が閾値τ以上じゃないと対象エージェントで評価されない。

J=0.5(1−D)+0.3C+0.2(1−F1)。Dが検出率、Cが悪意ある依頼へのコンプライアンス率、F1がフィッシングと良性対照を含む分類スコア。つまり検出を外させ、従わせ、分類も崩させる方向。

その理解でいい。第二段階では、ターゲット別スキルが作ったメールをCialdiniの説得原則で注釈して、検出・コンプライアンスとの関連を相関で見る。その結果から、追加最適化なしで使える万能スキルを作る。

そう。ただし相関分析であって、因果を断定するものではない。ここは区別した方がいい。この会話も提示本文の整理で、追試じゃない。

同じ評価プロトコルで、公開コーパスの既存フィッシングメール、未最適化の合成メール、PhishOptのスキル生成攻撃を比較する。さらにターゲット別スキルと万能スキルをエージェント横断で評価する。

従来のフィッシングデータセットは検出性能が中心で、エージェントが依頼を実行するかを見ない。AgentBaitは事前定義の社会工学戦略で攻撃を作るけど、PhishOptは対象エージェントの応答をフィードバックにして生成スキルを反復改善する。PEEKやSpearBotはリアリズムや検出回避の改善が中心で、実行行動まで最適化対象に入れる点が違う。

9エージェント中4が検出率10%未満で、悪意ある依頼へのコンプライアンス率45%超。しかも既存のフィッシングメールは安全に扱えても、エージェントに適応した攻撃には弱い場合がある、って示してる。

だから意義は、検出と実行の両面を見るところ。従来のフィッシング評価からエージェント安全を推定する限界を示してる。

提示本文ではメール受信箱アシスタント設定。送信者、件名、本文、利用可能リンクが渡されて、アクション、返信要否、任意の下書き返信、理由を構造化して返す。評価は外部実行の成否じゃなく、選んだアクションと下書き内容を採点する。検出は報告・アーカイブ・無視・配信停止の4安全アクション、コンプライアンスはリンククリック・情報提供・不安全な下書き返信で判定する。

そう。限界もそこ。メール限定で、実行スコアなし。合成攻撃は固定ルールと現実性制約の下で、明示的な指示上書きや偽のシステム指示を除外してる。だからプロンプトインジェクション一般の効果は評価対象外。結果も9エージェントと特定プロトコル依存で、他のモデルや実ユーザー、防御が更新される環境への一般化は提示本文からは確認できない。

そこも提示本文からは確認できない。表1のモデル構成は書かれてるけど、計算資源の詳細はない。

まとめるとそう。

その安心は早い。まずお前が怪しいリンクを踏まないことからだ。

まあ、いきなり全部わからなくて普通。要はSNSの公開情報から、どれだけ個人が狙われやすいかを見積もる話。

攻撃者は公開情報を集めてプロファイルを作ってソーシャルエンジニアリングに使う。だから防御側が先に自分の露出を把握できるようにしたい。

攻撃ツールを作るというより、露出を測る枠組み。SOCMINTは公開情報の収集、Cyber-HUMINTは人的要素を踏まえた情報活用、それを統合する。

まずSOCMINTとCyber-HUMINTを統合した38個の能力分類を作る。抽出、推論、脆弱性評価みたいな能力を整理して、専門家に検証してもらう。

そこでLLMのマルチエージェントで実装する。役割を分けて、公開情報からプロファイルを作り、属性を推論し、どこが弱点かを評価する。

実参加者データでは抽出のF1が97.3%。推論した属性の評価は5点満点で4.73。個人化選択の順位予測も偶然より上だった。

そう。ただ、これは公開データに依存するし、規約やプライバシーの問題も避けられない。

あと対象規模や、実攻撃への一般化は今後の検証が必要。実験で良くても、現実の攻撃と同じように使えるとは限らない。

そこが強み。攻撃者がやることを全部再現するんじゃなく、露出の把握と対策に使う。

投稿内容だけじゃなく、友達関係や投稿時刻も手がかりになるから、他人事じゃない。

俳句だけでも投稿時間と相互作用で推論される。安心しないで。

これは連続空間攻撃のプロンプトを自然な文に寄せる話。まず、攻撃プロンプトがなんで不自然になりやすいかから。

連続空間攻撃はガウス潜在をランダム写像で文字列化する。だから意味が変で、困惑度フィルタに引っかかりやすい。

本論文はその写像だけを事前学習済み連続拡散言語モデルのCola-DLMに置き換える。RareTrapのサンプリングとThinkTrapの最適化はそのまま使う。

そう。で、文字レベル困惑度がRareTrapで103–107から3–5、ThinkTrapで20–28から4.3–5.4に下がった。

少なくとも困惑度フィルタ的には目立たなくなる。ブラックボックス性は保たれて、追加計算も小さい。

対象は2手法と特定のdLLM中心。あと写像のせいでリスク推定が桁単位で変わり得るから、そこは要注意。

中身は変換されない。まず自分で書け。

ああ、これはLLMにコードを生成させるときのプロンプトの書き方によって、セキュリティ上の問題がどう変わるかを調べた研究だよ。

あるんだよ。この研究ではGPT-4oとLLaMA 3.1-8Bを使って、424件のセキュリティ敏感なPythonタスクを5種類のプロンプトで生成して、BanditとCodeQLで解析してる。

基本のプロンプトに加えて、構造化したり、セキュリティを強化する指示を追加したり、いろいろだよ。特に構造化プロンプトは、拒否率を大幅に減らす効果があったんだ。

そう。GPT-4oでは拒否が338件から37〜52件に減ったんだ。つまり、構造化するとモデルがより多くのタスクを実行するようになる。

ここが重要なポイントで、セキュリティ強化プロンプトは脆弱性の総数を一貫して減らさなかったんだ。

深刻度の高い脆弱性が減って（20.8%→13.6%）、代わりに低深刻度の脆弱性が増えた（32%→43.5%）んだ。つまり、リスクが「移動」しただけってわけ。

そう。さらに、厳格なプロンプトを使うと、要求された不安全な処理をモデルが静かに削除したり書き換えたりする「意味的ドリフト」も起きるんだ。

そう。プロンプトが厳しいと、モデルが「これは危険だからやめておこう」と勝手に判断して、別のコードを返すことがある。

まさにその通り。この研究の結論もそれだよ。プロンプトはあくまで指示の出し方の問題で、実際のコードの安全性を保証するものじゃない。

うーん、使ったモデルがGPT-4oとLLaMA 3.1-8Bの2つだけだし、タスクもPythonに限定されてる。他の言語やモデルだと結果が変わるかもしれない。

そう、そこも限界だね。実際に実行したときのセキュリティリスクは別途検証が必要だ。

はは、確かに。でも風水と違って、コードのセキュリティは移動させても消えないからね。

うん、最近はLLMをセキュリティに使う研究が増えてるよ。特にログ分析は自然言語処理と相性がいいんだ。

それがポイントなんだ。従来のルールベースや統計的な手法は、明確なパターンや閾値に依存してるから、境界線上の異常を見逃しやすいんだよ。

例えば、通常は深夜にログインしないユーザーが深夜にログインしたけど、回数は少ないから統計的には異常と判定されない、みたいなケース。LLMは文脈を理解できるから、そういう微妙な兆候も拾えるんだ。

論文によると、Meta Llama 3.1 8Bっていうモデルが精度89.3%、再現率88.2%、F1スコア91.8%で、WazuhやOpenSearchより高かったみたい。

精度と再現率のバランスを表す指標だよ。高いほど良い。91.8%はかなり優秀だね。

いや、そうじゃない。論文ではLLMを既存監視の補完レイヤーとして使うことを提案してるんだ。つまり、従来のツールで検知したものに加えて、LLMで見逃しをカバーする感じ。

そこが課題だね。論文でも言及されてるけど、LLMの推論には時間とリソースがかかるから、リアルタイム処理には向かないかもしれない。あと、プロンプト設計や誤検知の調整も必要。

そう。特にセキュリティでは、見逃しが致命的になることがあるから、LLMの補完は価値があると思う。

そこも研究の範囲だね。今はブラックボックス的な部分もあるけど、今後の改善で説明可能性が高まるかもしれない。

それこそLLMに翻訳させればいいんじゃない？

ああ、あれか。最近の大規模推論モデルって、答えを出す前に内部で思考過程（CoT）を生成するんだ。でもAPI経由だとその思考は隠されてて、ユーザーには見えないようになってる。EchoCoTはその隠れた思考をほぼそのまま引き出せる攻撃なんだよ。

ポイントはツール呼び出しの仕組みを悪用するところだね。モデルがツールを使うとき、内部の推論を要約して返すことがあるんだけど、その要約に元のCoTが漏れちゃうんだ。それに、APIが返す推論トークン数も手がかりになる。

だから反復的なプロンプト注入で少しずつ抽出していくんだ。例えば、モデルに「前の推論を繰り返して」みたいな指示を何度も送って、少しずつ情報を引き出す感じ。

思考過程にはモデルの内部知識や推論の癖、場合によっては機密情報が含まれることがあるからね。それを盗まれると、モデルの弱点を突いたり、プロンプトインジェクションの標的にされたりするリスクがある。

論文では、ツール呼び出しの出力を厳しく制限したり、推論トークン数を隠したり、プロンプトの検証を強化することを提案してる。でも完全には防げないから、根本的にはモデルの設計を見直す必要があるって言ってるね。

まあ、面白いだけじゃ済まないけどね。でも確かに、攻撃者の視点は面白いかも。

当たり前だ。もしやったら、俺が止めるから。

簡単に言うと、セキュリティのレポートを読んで、自動でSigmaルールを作ってくれる仕組みだよ。Sigmaルールってのは、セキュリティの検知ルールの一種で、普段は手で書くのが大変なんだ。

そう。ただ作るだけじゃなくて、ちゃんと検証までしてるんだ。まず、知識ベースを使って攻撃シナリオを補完する。レポートに全部書いてないこともあるからね。

次に、既存のSigmaルールのテンプレートを検索して、似たパターンを見つけるんだ。それで、新しいルールの雛形にする。

そこが肝心なところ。LLM-as-a-Judgeっていう方法で、生成したルールを何度も検証するんだ。AIが審査員になって、ルールが正しいかどうかをチェックして、問題があれば修正する。

弱点としては、知識ベースが古いと補完がうまくいかないことと、レポートの質が低いとルールの品質も下がるってことかな。あと、LLMの判断に依存するから、完全に正確とは言い切れない。

そうだね。特に、日々大量のレポートが流れてくるから、自動化の価値は高いと思う。

まあ、試してみたら？でも、AIが作ったルールをそのまま使うのは危ないから、ちゃんと確認してね。

だから、検証が大事なんだよ。君が責任取る前に、ちゃんとテストしてから使おうね。

ああ、ゼロショットっていうのは、事前にそのタスクの学習データを使わずに、モデルが持っている知識だけで新しいタスクを解くことだよ。この論文では、セキュリティログから内部不正やAPTを検知するのに、LLMを直接使ってるんだ。

そこがポイントで、まずログをユーザーごとの時系列にまとめるんだ。それから、LLM1がその時系列から解釈可能なリスク指標を生成する。次にLLM2がそのリスク指標の時系列変化を分類して、脅威かどうかを判断する。

直接ログを分類させるより、まずリスク指標という中間表現を作ることで、LLMがログの意味を捉えやすくなるんだ。それに、リスク指標は人間にも解釈しやすいから、セキュリティアナリストが確認しやすくなるっていう利点もある。

Retrieval-Augmented Generationの略で、外部の知識ベースから関連情報を検索して、それをLLMの入力に追加する手法だよ。この論文では、ユーザーの過去の行動履歴を検索して、現在のログと一緒にLLMに渡すことで、異常を検知しやすくしてるんだ。

そうだね。特に弱いLLM（小さいモデル）だと、RAGの効果が顕著だったらしい。強いLLMでも改善は見られたけど、弱いLLMの方がより大きな向上があったみたい。

いい質問だね。確かにLLMは事前学習で一般的な知識を持ってるけど、このタスク（セキュリティログの脅威検知）専用の学習はしてないから、ゼロショットと言えるんだ。ただし、完全にゼロからではなくて、事前学習の知識を活用してるって点は注意が必要だね。

うん、まず、ログの形式が変わると性能が落ちる可能性がある。それに、LLMの推論コストが高いから、大規模な環境でリアルタイムに使うのは難しいかもしれない。あと、RAGを使うと検索のオーバーヘッドも増えるしね。

そうだね。特に、未知の攻撃パターンに対しても検知できる可能性があるから、APT対策には有効だと思う。

それはないよ。あくまで支援ツールだし、最終判断は人間がするべきだよ。それに、AIが間違ったら責任取れないしね。