On this page

Triage एजेंट

triage एजेंट उनके HTTP साक्ष्य को रीप्ले करके ड्राफ्ट कमजोरी निष्कर्षों को स्वतंत्र रूप से सत्यापित करता है। यह कभी रिपोर्टिंग एजेंट के वर्णन पर भरोसा नहीं करता — यह हर अनुरोध रीप्ले करता है और प्रतिक्रिया बॉडी की स्वयं जांच करता है।

अवलोकन

गुण	मान
Agent ID	`triage`
मोड	`subagent`
उपकरण पहुंच	प्रतिबंधित (read, grep, http_replay, triage_vulnerability, web_get_session_context)
डिज़ाइन	रूढ़िवादी — असत्यापनीय निष्कर्षों को ड्राफ्ट के रूप में छोड़ता है

सत्यापन प्रोटोकॉल

प्रत्येक ड्राफ्ट निष्कर्ष के लिए triage एजेंट:

संलग्न HTTP साक्ष्य (कैप्चर किया गया अनुरोध/प्रतिक्रिया) पढ़ता है
अनुरोध को स्वतंत्र रूप से रीप्ले करने के लिए http_replay का उपयोग करता है
वास्तविक प्रमाण के लिए रीप्ले प्रतिक्रिया की जांच करता है
निष्कर्ष का भाग्य तय करता है:

निर्णय	कब
Triaged	रीप्ले कमजोरी की पुष्टि करता है
Rejected	रीप्ले झूठी सकारात्मक दिखाता है
Duplicate	निष्कर्ष किसी अन्य सत्यापित निष्कर्ष का डुप्लिकेट है
Draft (अपरिवर्तित)	सत्यापित नहीं कर सकता — मानव समीक्षा के लिए छोड़ दिया

प्रमाण क्या होता है

triage एजेंट सख्त साक्ष्य मानक लागू करता है:

अकेले 200 स्थिति प्रमाण नहीं है — प्रतिक्रिया बॉडी में लक्ष्य डेटा होना चाहिए
deleted:0, खाली ऐरे, सामान्य सफलता संदेश साक्ष्य नहीं हैं
क्रॉस-टेनेंट/IDOR निष्कर्षों के लिए, प्रतिक्रिया में अन्य टेनेंट का डेटा होना चाहिए
प्राधिकरण निष्कर्षों के लिए, compare मोड रीप्ले को दिखाना चाहिए कि विशेषाधिकार सीमा पार हो गई है

उदाहरण

Draft: IDOR in GET /api/users/42 — claimed to return user data for another tenant

Triage:
1. Replay GET /api/users/42 with original auth → 200, body: {"id": 42, "name": "Other User"}
2. Replay GET /api/users/42 with attacker auth → 200, body: {"id": 42, "name": "Other User"}
3. Both return the same user data → CONFIRMED cross-tenant access
4. → triage_vulnerability(id, status: "triaged")

Info

triage एजेंट कमजोरी परीक्षण सबएजेंट्स द्वारा निष्कर्ष रिपोर्ट करने के बाद स्वचालित रूप से भेजा जाता है। यह निष्कर्ष प्रस्तुत करने से पहले अंतिम गुणवत्ता द्वार के रूप में चलता है।