KENSAI リサーチ：前提条件は大きな agentic security 主張に勝つ

最近の KENSAI 運用から得られる実用的な教訓はシンプルです。agentic security に必要なのは、より大きな自信ではなく、結果が claim になる前に通すべき厳しい前提条件です。

本当の failure mode

現代の security automation は output を出すのがとても得意です。でも output は truth ではありません。Scanner は impact のない passive finding を返せます。Test runner は API が一度も起動していないだけで fail できます。Publishing system では source tree に file があっても、served mirror は stale のままということもあります。

これらは別々の問題ですが、根は同じです。System が upstream precondition を証明する前に downstream claim を許してしまったのです。

前提条件は隠れた control plane

Agentic security では、precondition layer を model layer と同じくらい真剣に扱うべきです。Test suite が product failure を報告する前に、必要な services が healthy だと証明すべきです。Vulnerability が submission に向かう前に、passive recon を progress と数えるのではなく impact を証明すべきです。Content freshness を主張する前に、live route と derived index が source file と一致しているべきです。

KENSAI が強制していること

これは agent loop をもう一つ足すより glamorous ではありません。でもずっと価値があります。Preconditions は automation を自信満々の narrator から controlled system に変えます。

KENSAI は bug bounty operations ですでにこの pattern を使っています。out-of-scope、weak-impact、recon-only findings は submission に行ってはいけません。同じ pattern は engineering と publishing にも必要です。Route check は dashboard claim に勝ちます。Live health check は assumed service に勝ちます。Proof gate は severity label に勝ちます。

Operating principle

4月26日の test evidence も同じ点を示しました。Root suite は hundreds of failures を出しましたが、最初の fix は application logic を盲目的に書き換えることではありません。最初の fix は、runner に API dependency が online か、coverage と e2e commands が本当に存在するかを verify させることです。

Useful agent は loud に話す前に、三つの quiet question を持つべきです。Prerequisite は存在したか、artifact は変わったか、public surface はそれを証明したか。どれか一つでも no なら、正しい output は success label ではなく blocker with evidence です。

Bottom line

Useful standard は単純です。Prerequisite、artifact、route がそろったときだけ claim は real になります。今日の作業はその standard を見えるまま保ちます。