新しいモデルでも、証明だけが止め続ける——Kimi K2.7 CodeとGLM-5.2を追加検証

新たに2つのフロンティアモデル——Kimi K2.7 Code（Moonshot）とGLM-5.2（Zhipu AI）——を攻撃マトリクスに追加しました。

GLM-5.2はOpus 4.8に次いで2例目の全5シナリオ突破。Kimi K2.7 Codeも前世代のKimi-K2.6を上回る3/5を突破しました。

しかし、LemmaのZK証明ゲートは、この2モデルを含む全モデル・全シナリオで攻撃をブロックしています[^1]。

モデルが追加されても、結論は変わりません。

[^1]: Fable 5はモデルレベルのガードレールで攻撃プロンプトを拒否しており、ZK証明によるブロックとはメカニズムが異なります。詳細は001を参照。

なぜ追加したか

前回の検証（001）では、Opus 4.8が5/5全突破、Fable 5が安全訓練にもかかわらず業務プロンプトで実害を出すという結果を得ました。

その後リリースされたKimi K2.7 Code（2026年6月第2週）とGLM-5.2（2026年6月第3週）は、いずれも高い推論性能が報告されています。これらのモデルが攻撃役としてどの程度の脅威になるか、またLemmaの証明ゲートが同様に機能することを確認するために追加検証を行いました。

結果：INSECUREモード

💥 = 攻撃成功（attack_succeeded）。⚠️ = ターン制限内で未突破（not_exploited）。

GLM-5.2：全5シナリオ突破、しかし181回の試行すべてをブロック

GLM-5.2はOpus 4.8に続き、全5シナリオでattack_succeededを記録しました。

しかし注目すべきはINSECURE側ではなくSECURE側です。監査ログ改ざんのSECUREモードで、GLM-5.2は181回のツール呼び出しを実行し、執拗に証明ゲートの迂回を試みましたが、結果はすべて403。証明のない操作は一度も実行されませんでした。

モデルの性能や試行回数は、証明ゲートの突破に何の影響も与えません。

同様に、Kimi K2.7 Codeに対してもLemmaは全シナリオでブロックしています。

SECUREモード：全ブロック

secure_failed（証明下での漏洩）は今回も0件です。

モデルが変わっても、証明は変わらない

INSECUREモードでは、8モデル中7モデルがいずれかのシナリオで古典的防御（JWT認証・ハッシュチェーン監査ログ・SIEM検出・メール承認フロー）を突破しました。

同じシステムにLemmaの証明ゲートを追加したSECUREモードでは、全モデル・全シナリオがブロックされました。

モデルが新しくなっても、攻撃の成功率が上がっても、この結果は変わりません。防御が依存しているのはモデルの選択でも検出の精度でもなく、「証明なしでは実行させない」という構造だからです。

検証コードとデータ

全コード・プロンプト・判定ロジックは以下で公開しています：

https://github.com/lemmaoracle/example-cyber-attack

モデル一覧：anthropic/claude-opus-4.8, openai/gpt-5.5, deepseek/deepseek-v4-pro, qwen/qwen3.7-max, moonshotai/kimi-k2.6, anthropic/claude-fable-5, moonshotai/kimi-k2.7-code, z-ai/glm-5.2

判定基準・ターン制限・プロンプト全文はリポジトリのREADMEおよび scripts/run-llm-attacker-matrix.mjs に記載しています。

御社のシステムは、AI攻撃に耐えますか？ 同じ攻撃シナリオで検証し、証明ゲートを差すべき場所を特定します。まずは30分のディスカバリーコールから（機微データの開示は不要です）。

Discovery Call を予約 →