KENSAI शोध: preconditions बड़ी agentic security claims से बेहतर हैं

KENSAI की हाल की operations से निकला useful lesson सीधा है: agentic security को ज़्यादा loud confidence नहीं चाहिए। उसे stronger preconditions चाहिए, ताकि कोई result claim बनने से पहले verify हो।

असल failure mode क्या है

Modern security automation output बनाने में बहुत अच्छी है। लेकिन output और truth एक ही चीज़ नहीं हैं। Scanner passive finding दे सकता है जिसमें impact न हो। Test runner इसलिए fail हो सकता है क्योंकि API कभी start ही नहीं हुई। Publishing system में source tree में file हो सकती है लेकिन served mirror stale रह सकता है।

ये अलग-अलग problems हैं, लेकिन root cause एक ही है: system ने upstream precondition साबित होने से पहले downstream claim को allow कर दिया।

Preconditions hidden control plane हैं

Agentic security में precondition layer को model layer जितनी seriousness से लेना चाहिए। Test suite product failures report करे उससे पहले उसे prove करना चाहिए कि required services healthy हैं। Vulnerability submit की तरफ बढ़े उससे पहले उसे impact prove करना चाहिए, passive recon को bounty progress नहीं गिनना चाहिए। Content freshness claim होने से पहले live route और derived index को source file से match करना चाहिए।

KENSAI क्या enforce कर रहा है

यह एक और agent loop जोड़ने जितना glamorous नहीं है। लेकिन ज्यादा valuable है। Preconditions automation को confident narrator से controlled system में बदल देती हैं।

KENSAI bug bounty operations में यह pattern पहले से लागू करता है: out-of-scope, weak-impact और recon-only findings submit तक नहीं जानी चाहिए। यही pattern engineering और publishing में भी होना चाहिए। Route check, dashboard claim से बेहतर है। Live health check, assumed service से बेहतर है। Proof gate, severity label से बेहतर है।

Operating principle

26 अप्रैल की test evidence ने यही बात फिर साफ की। Root suite ने hundreds of failures दीं, लेकिन पहला fix blind application logic rewrite नहीं है। पहला fix यह है कि runner verify करे कि उसकी API dependency online है और coverage/e2e commands वास्तव में मौजूद हैं।

Useful agent को loud बोलने से पहले तीन quiet questions पूछने चाहिए: prerequisite थी, artifact बदला, और public surface ने उसे prove किया? अगर इनमें से कोई answer no है, तो सही output blocker with evidence है, success label नहीं।

Bottom line

Useful standard सीधा है: claim तभी real होती है जब prerequisite, artifact और route align हों। आज का काम उसी standard को visible रखता है।