आपका AI कोडिंग एजेंट जो कोड लिखता है, उसकी सुरक्षा-समीक्षा कैसे करें

AI कोडिंग एजेंट तेज़ होते हैं, और यह तेज़ी दोनों तरफ़ काटती है। वे मिनटों में ख़ुशी-ख़ुशी एक काम करता फ़ीचर बना देंगे — और उतनी ही ख़ुशी से स्ट्रिंग कॉन्कैटनेशन से SQL क्वेरी जोड़ देंगे, किसी सीक्रेट को लॉग कर देंगे, या ऑथराइज़ेशन जाँच छोड़ देंगे। कोड चलता है, टेस्ट पास होते हैं, और भेद्यता प्रोडक्शन में चली जाती है। जब टाइपिंग कोई एजेंट कर रहा हो तब सुरक्षा-समीक्षा वैकल्पिक नहीं होती; यह वह हिस्सा है जिसका ज़िम्मा अब भी आपका है।

यहाँ प्रोडक्शन तक पहुँचने से पहले AI-जनित कोड की समीक्षा के लिए एक व्यावहारिक, टूल-निरपेक्ष वर्कफ़्लो है।

जानें कि क्या देखना है

वास्तविक दुनिया की अधिकांश भेद्यताएँ मुट्ठीभर पैटर्न में सिमट जाती हैं। जब आप (या कोई टूल) एजेंट के आउटपुट की समीक्षा करें, तो पहले इन्हें स्कैन करें:

• इंजेक्शन (Injection) — SQL, शेल या टेम्पलेट इनपुट जो पैरामीटराइज़्ड क्वेरी के बजाय स्ट्रिंग जोड़कर बनाया गया हो।
• क्रॉस-साइट स्क्रिप्टिंग (XSS) — यूज़र इनपुट जो बिना escaping के HTML में रेंडर किया गया हो।
• टूटा हुआ ऑथेंटिकेशन/ऑथराइज़ेशन — ऐसे एंडपॉइंट जो जाँचते हैं कि आप कौन हैं पर यह नहीं कि आपको अनुमति है या नहीं; रिकॉर्ड्स पर स्वामित्व जाँच का अभाव।
• असुरक्षित डेटा हैंडलिंग — कोड में सीक्रेट, लॉग में क्रेडेंशियल, एरर संदेशों में संवेदनशील डेटा।
• भेद्य निर्भरताएँ (dependencies) — एजेंट द्वारा जोड़ा गया कोई पैकेज जिसमें ज्ञात CVEs हों।

ये OWASP Top 10 से बारीकी से मेल खाती हैं, और ये ठीक वही श्रेणियाँ हैं जिन्हें Anthropic के अनुसार उसकी स्वचालित सुरक्षा-समीक्षा खोजती है। इस छोटी सूची को दिमाग़ में रखने से मैनुअल समीक्षा कहीं अधिक प्रभावी हो जाती है।

एजेंट से ही उसकी समीक्षा कराएँ — एक नए संदर्भ में

जिस मॉडल ने कोड लिखा है वही उसकी समीक्षा कर सकता है, पर उसी साँस में नहीं। जिस एजेंट ने अभी-अभी किसी फ़ीचर को चलाने में 20 चक्कर लगाए हों, वह उसका बचाव करने के लिए तैयार बैठा होता है। एक नया सेशन शुरू करें और उसे एक ही काम दें: खामियाँ ढूँढ़ना।

एक प्रॉम्प्ट जो अच्छा काम करता है:

Review the diff on this branch for security vulnerabilities only.
For each finding, give me: the file and line, the vulnerability class
(e.g. SQL injection), a concrete exploit scenario, and the fix.
If you find nothing, say so — do not invent issues.

"concrete exploit scenario" वाला खंड ही महत्वपूर्ण हिस्सा है। यह मॉडल को मजबूर करता है कि वह साबित करे कि समस्या असली है, बजाय इसके कि वह "consider validating input" जैसी अस्पष्ट रटी-रटाई बातें गिनाता रहे।

अंतर्निहित (built-in) टूल्स का सहारा लें

अगर आप Claude Code इस्तेमाल करते हैं, तो एक समर्पित /security-review कमांड है जो आपके बदलावों का सामान्य भेद्यता पैटर्न के लिए विश्लेषण करती है और, आपकी मंज़ूरी पर, फ़िक्स सीधे लागू कर देती है। यह भुगतान वाली Pro और Max योजनाओं तथा pay-as-you-go API अकाउंट्स पर उपलब्ध है।

निरंतर कवरेज के लिए, Anthropic एक ओपन-सोर्स GitHub Action भी देती है जो हर pull request पर चलती है और ठीक उन्हीं लाइनों पर इनलाइन टिप्पणियाँ पोस्ट करती है जिनकी उसे चिंता है। इसे किसी रिपॉज़िटरी में डालना कुछ इस तरह दिखता है:

# .github/workflows/security.yml
name: Security Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

अब हर PR — चाहे उसे किसी इंसान ने खोला हो या एजेंट ने — merge दबाने से पहले एक सुरक्षा-पास से गुज़रता है। Cursor, Copilot और अन्य सहायक भी तुलनीय समीक्षा-एकीकरण देते हैं; सिद्धांत टूल चाहे जो हो, वही रहता है।

नियतात्मक (deterministic) जाँचें न छोड़ें

AI समीक्षा एक मज़बूत अतिरिक्त उपाय है, न कि उस उबाऊ टूलिंग का विकल्प जो कभी नहीं थकती:

• डिपेंडेंसी स्कैनिंग — npm audit, pip-audit या Dependabot उन ज्ञात-भेद्य पैकेज को पकड़ते हैं जिन्हें कोई LLM नाम से नहीं पहचान पाएगा।
• सीक्रेट स्कैनिंग — gitleaks जैसे टूल या GitHub की push protection किसी लीक हुई कुंजी को इतिहास में पहुँचने से ही रोक देते हैं।
• स्टैटिक एनालिसिस (SAST) — linters और Semgrep जैसे टूल पूरे कोडबेस पर नियमों को एक-समान ढंग से लागू करते हैं।

AI का उपयोग लॉजिक और संदर्भ पर तर्क करने के लिए करें — "क्या यहाँ कोई प्रमाणित यूज़र किसी दूसरे यूज़र के रिकॉर्ड पढ़ सकता है?" — और यांत्रिक, पैटर्न-मिलान वाले काम के लिए नियतात्मक स्कैनर का उपयोग करें। ये एक-दूसरे के अंधे धब्बों को ढँकते हैं।

एक ठोस उदाहरण

मान लें आपका एजेंट यह एंडपॉइंट बनाता है:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(f"SELECT * FROM invoices WHERE id = '{invoice_id}'")

एक सुरक्षा-पास को दो समस्याएँ चिह्नित करनी चाहिए: यह क्वेरी घटित होने के इंतज़ार में बैठी SQL इंजेक्शन है (invoice_id को इंटरपोलेट किया गया है), और यह जाँच है ही नहीं कि इनवॉइस वास्तव में user की है — कोई भी लॉग-इन अकाउंट IDs का अंदाज़ा लगाकर कोई भी इनवॉइस पढ़ सकता है। फ़िक्स है एक पैरामीटराइज़्ड क्वेरी के साथ एक स्वामित्व फ़िल्टर:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        [invoice_id, user.id],
    )

इंजेक्शन वह चीज़ है जिसे कोई स्कैनर पकड़ लेता है। लापता ऑथराइज़ेशन जाँच वह चीज़ है जिसके लिए किसी व्यक्ति — या सही प्रॉम्प्ट वाले AI समीक्षक — की ज़रूरत होती है जो समझे कि कोड किस लिए है। यही वह विभाजन है जिसे ध्यान में रखना चाहिए।

निष्कर्ष

आपका एजेंट जो भी diff बनाता है उसे तब तक अविश्वसनीय मानें जब तक उसकी समीक्षा न हो जाए — वही मानक जो आप किसी नए साथी की पहली pull request पर लागू करते। एक नए-संदर्भ की AI समीक्षा, एक स्वचालित PR जाँच और नियतात्मक स्कैनर को मिलाएँ, और आपको AI-सहायित विकास की अधिकांश तेज़ी मिल जाएगी — उसकी सबसे बुरी आदतें विरासत में लिए बिना।