पाठ 27 / 28

केस स्टडी: Customer-Support सहायक को सुरक्षित करना

पूरे कोर्स को एक यथार्थवादी सहायक पर लागू करें।

डिज़ाइन

सहायक ग्राहकों को orders के बारे में उत्तर देता है, उनका order इतिहास पढ़ता है, help centre खोजता है और refunds प्रस्तावित कर सकता है। Threat model: अविश्वसनीय पाठ ग्राहक संदेशों, अपलोड किए screenshots के पाठ, retrieved help लेखों (कुछ user-योगदान वाले) और उसके सार किए web pages से आता है; lethal-trifecta जोखिम निजी order डेटा, अविश्वसनीय सामग्री और ईमेल/refund कार्रवाइयाँ हैं, इसलिए कम से कम एक कड़ी हटाई गई (मुक्त-रूप बाहर जाने वाला ईमेल नहीं: वह पाठ का मसौदा बनाता है और मनुष्य भेजता है)। Tools: get_order(order_id) केवल-पढ़ने वाले account से प्रमाणित ग्राहक के रूप में चलता है; propose_refund(order, amount<=5000) मानव अनुमोदन के लिए queue होता है और ठीक राशि पर हस्ताक्षरित; कोई shell, सामान्य SQL, file tool नहीं; URLs केवल allow-list से अलग-थलग fetcher के ज़रिए। Prompting: अविश्वसनीय पाठ fenced और डेटा के रूप में लेबल; system prompt में canary token; prompts में secrets नहीं। आउटपुट: render पर उत्तर escape, दूरस्थ images स्वतः render नहीं, संरचित fields validated, URLs filter। डेटा: मॉडल को न्यूनतम ग्राहक डेटा, logs से व्यक्तिगत डेटा redacted, retrieval tenant और लेख दृश्यता से filtered, ingestion छिपा पाठ हटाता है। सीमाएँ: प्रति-user rate limits, token व चरण सीमाएँ, alert सहित दैनिक ख़र्च सीमा। Supply chain: pin की dependencies, सुरक्षित format में सत्यापित स्रोतों के मॉडल, समीक्षित tools। संचालन: CI में attack suite (injection, निकासी, cross-user, tool दुरुपयोग, आउटपुट payloads, हिंदी व Hinglish), audit logs, canary hits और denials पर alerts, kill switches वाला घटना runbook।

हेरफेर मानें, नुक़सान सीमित करें

सुरक्षित LLM app सीमित करता है कि मॉडल कहाँ पहुँचे, जो बनाए उसे validate करता है, डेटा तक access नियंत्रित करता है और दुरुपयोग पर नज़र रखता है।

चार आदतें: सीमित करें, validate करें, authorise करें, निगरानी।
चित्र 8.1 — सीमित करें, validate करें, authorise करें और निगरानी।

एक पन्ने पर डिज़ाइन

हर पंक्ति इस कोर्स के एक खंड से जुड़ती है।

Threat model  untrusted text sources listed; lethal trifecta broken (human sends emails)          (Sec 1)
Injection     fenced + labelled data, canary token, no secrets in prompts, filters as monitoring      (Sec 2)
Output        escape on render, no auto-images, validate fields, URL allow-list                      (Sec 3)
Agency        read-only per-customer tool, refund proposals signed + human approved, default-deny    (Sec 4)
Data          minimum data, redacted logs, retrieval filtered by tenant, ingestion strips hidden text (Sec 5)
Platform      pinned deps, safe model formats, rate limits, token/step/spend caps                    (Sec 6)
Operations    attack suite in CI, audit logs, alerts, kill switches, runbook                          (Sec 7)

हर नए tool के लिए threat model दोबारा चलाएँ

हर जोड़ी क्षमता प्रभाव क्षेत्र बदलती है।

त्वरित जाँच: इस सहायक में कौन-सा डिज़ाइन चुनाव "lethal trifecta" तोड़ता है?

  • ज़्यादा logging
  • बड़ा मॉडल उपयोग करना
  • लंबा prompt उपयोग करना
  • सहायक ईमेल का मसौदा बनाता है और मनुष्य भेजता है, इसलिए उसके पास मुक्त बाहरी channel नहीं
Answer

सहायक ईमेल का मसौदा बनाता है और मनुष्य भेजता है, इसलिए उसके पास मुक्त बाहरी channel नहीं — Trifecta की एक कड़ी हटाना उस रास्ते से डेटा निकासी रोकता है।