# AI एजेंट के लिए CDN पर्ज दायरे का प्रीव्यू

किसी AI एजेंट को कभी भी सिर्फ़ “CDN कैश साफ़ करने” की मंज़ूरी नहीं माँगनी चाहिए। यह वाक्य उन बातों को छिपा देता है जिन्हें कार्रवाई की अनुमति देने से पहले ऑपरेटर को जानना ज़रूरी है: कौन-सा होस्ट, कौन-सा पाथ, कितने टैग, और कितना कैश किया हुआ कॉन्टेंट परोसा जाना बंद हो सकता है।

CDN पर्ज के दायरे का अच्छा प्रीव्यू अंतिम अनुरोध को असर के दायरे के छोटे और स्पष्ट विवरण में बदल देता है। इसे लक्षित इनवैलिडेशन और पूरे कैश को पर्ज करने वाली कार्रवाई को अलग जोखिम श्रेणियों में भी रखना चाहिए। मैंने बड़े पर्ज को एक सामान्य रिलीज़ से ओरिजिन ट्रैफ़िक की घटना बनते देखा है, क्योंकि मंज़ूरी के डायलॉग में वाइल्डकार्ड एक मामूली पाथ जैसा दिखता था। अनुरोध का सिंटैक्स छोटा था। उसका असर छोटा नहीं था।

सही डिज़ाइन सिर्फ़ एक पुष्टि बॉक्स नहीं जोड़ता। वह प्रदाता के अनुरोध को नॉर्मलाइज़ करता है, उसके दायरे की श्रेणी तय करता है, अनिश्चितता को छिपाए बिना पहुँच का अनुमान लगाता है, और ऑपरेटर की मंज़ूरी को ठीक उन्हीं पैरामीटर से बाँधता है। मंज़ूरी के बाद एजेंट होस्ट, पाथ, टैग, वातावरण या पर्ज मोड बदले, तो गेटवे को फिर से अनुमति माँगनी चाहिए।

## पर्ज अनुरोध के लिए असर का मॉडल ज़रूरी है

CDN पर्ज का दायरा उन कैश किए हुए रूपों का समूह है जिन्हें प्रदाता इनवैलिड कर सकता है, न कि API अनुरोध में मौजूद स्ट्रिंग की संख्या। एक वाइल्डकार्ड पूरा डिस्ट्रिब्यूशन कवर कर सकता है। एक टैग हज़ारों असंबंधित URL से जुड़ा हो सकता है। एक URL के कई कैश किए हुए वेरिएंट हो सकते हैं, क्योंकि कैश क्वेरी स्ट्रिंग, हेडर, कुकी, डिवाइस प्रकार या भाषा के अनुसार बदल सकता है।

टीमें अक्सर पहला अंतर यहीं खो देती हैं: अनुरोध का आकार उसके असर का आकार नहीं है। Amazon CloudFront का दस्तावेज़ इस अंतर को साफ़ बताता है। वाइल्डकार्ड वाला इनवैलिडेशन पाथ एक ही भेजा गया पाथ गिना जाता है, भले ही वह हज़ारों फ़ाइल इनवैलिड कर दे। बिलिंग इकाई अनुरोध को बताती है, उसकी पहुँच को नहीं। `/*` दिखाए बिना सिर्फ़ “1 पाथ” बताने वाला मंज़ूरी कार्ड तकनीकी रूप से सही, पर कामकाज के लिए बेकार जानकारी देता है।

प्रस्तावित कार्रवाई को चार पहलुओं में मॉडल करें:

- **लक्ष्य:** CDN खाता, सेवा या डिस्ट्रिब्यूशन, वातावरण और होस्टनेम।
- **सेलेक्टर:** सटीक URL, पाथ प्रीफ़िक्स, वाइल्डकार्ड, कैश टैग, सरोगेट की, या पूरे कैश को साफ़ करने वाला प्रदाता का फ़्लैग।
- **अर्थ:** सेलेक्टर कैसे जुड़ते हैं, वे कौन-से वेरिएंट कवर करते हैं, और प्रदाता कैश ऑब्जेक्ट को इनवैलिड करेगा या हटाएगा।
- **नतीजा:** प्रभावित ऑब्जेक्ट या अनुरोधों की अनुमानित संख्या, दोबारा भरने का अपेक्षित व्यवहार, और क्या पुराना कॉन्टेंट फिर भी परोसा जा सकता है।

यह मॉडल एक्ज़ीक्यूशन गेटवे में, क्रेडेंशियल और प्रदाता अडैप्टर के पास होना चाहिए। एजेंट को अपना जोखिम लेबल खुद तय न करने दें। एजेंट पर्ज का प्रस्ताव दे सकता है, लेकिन उसका अर्थ उस कोड को निकालना चाहिए जो प्रदाता के API को समझता है।

यह अलगाव इसलिए मायने रखता है क्योंकि प्रदाताओं की शब्दावली एक जैसी नहीं है। Fastly अपने समूह वाले लेबल को surrogate key कहता है। Google Cloud और Akamai कैश टैग कहते हैं। Cloudflare टैग, होस्टनेम, URL प्रीफ़िक्स, एकल फ़ाइल और पूरी सफ़ाई का समर्थन करता है। CloudFront पाथ, वाइल्डकार्ड और कैश टैग इनवैलिडेशन का समर्थन करता है। अलग प्रदाताओं पर चलने वाला एजेंट टूल एक साफ़ इंटरफ़ेस दे सकता है, लेकिन प्रीव्यू को प्रदाता के असली मिलान नियम बनाए रखने चाहिए।

कुछ भी दिखाने से पहले एक्ज़ीक्यूशन घटक को एलियस सुलझाने, होस्ट को कैनोनिकल बनाने, प्रदाता के नियमों के अनुसार पाथ डिकोड और नॉर्मलाइज़ करने, सुविधा वाले विकल्पों को विस्तार देने और वास्तविक वातावरण पहचानने चाहिए। इसके बाद प्रीव्यू उस अनुरोध को बताता है जिस पर हस्ताक्षर होकर वह भेजा जाएगा। एजेंट के पहले वाले, आसान इनपुट को दिखाने से ऐसी खाई बनती है जिसमें नॉर्मलाइज़ेशन इंसान को बताए बिना दायरा बढ़ा सकता है।

## लक्षित इनवैलिडेशन और पूरा पर्ज अलग कार्रवाइयाँ हैं

लक्षित इनवैलिडेशन एक सटीक URL, सीमित पाथ या प्रीफ़िक्स, एक या अधिक टैग, या समर्थित सेलेक्टर के प्रतिच्छेद से कॉन्टेंट चुनता है। पूरा पर्ज पूरी सेवा, ज़ोन या डिस्ट्रिब्यूशन की उपयोगी स्थिति हटा देता है। दोनों को एक ही ड्रॉपडाउन के दो मान मानना उनके अंतर को छोटा दिखाता है।

श्रेणी असर के आधार पर तय होनी चाहिए, एंडपॉइंट के नाम पर नहीं। ये सभी अनुरोध पूरे पर्ज का लेबल पाने चाहिए:

- प्रदाता का स्पष्ट `purge_everything` फ़्लैग।
- डिस्ट्रिब्यूशन पाथ `/*`।
- ऐसा वाइल्डकार्ड या प्रीफ़िक्स जो नॉर्मलाइज़ होने पर रूट को कवर करता है।
- ऐसा टैग जो स्थानीय नियम के अनुसार सेवा के हर जवाब को चिह्नित करता है।
- सेलेक्टर की ऐसी सूची जिसका यूनियन कॉन्फ़िगर किए हुए सभी होस्ट कवर करता है।

आखिरी दो मामलों में स्थानीय मेटाडेटा चाहिए। प्रदाता को शायद पता न हो कि `release-current` सेवा के हर ऑब्जेक्ट पर है, लेकिन टैग लगाने वाली डिप्लॉयमेंट प्रणाली यह बात दर्ज कर सकती है। अगर गेटवे यह साबित नहीं कर सकता कि सेलेक्टर सीमित है, तो उसे पहुँच अज्ञात बतानी और मंज़ूरी का स्तर बढ़ाना चाहिए। अज्ञात एक सही नतीजा है। उसे चुपचाप छोटा मान लेना सही नहीं है।

लक्षित का अर्थ सुरक्षित नहीं है। बड़े स्टोर में `/products/` प्रीफ़िक्स ज़्यादातर ट्रैफ़िक कवर कर सकता है, और `tenant:42` टैग कई होस्ट तक जा सकता है। इस लेबल का मतलब सिर्फ़ इतना है कि अनुरोध ने ऐसी सीमा बताई है जिसे प्रीव्यू दिखा सकता है। ऑपरेटर को अब भी उस सीमा के भीतर की चीज़ों का अनुमान चाहिए।

पूरे पर्ज के लिए देखने और काम करने, दोनों स्तरों पर अलग प्रवाह चाहिए। खाली सेलेक्टर को अडैप्टर से सब कुछ मानने देने के बजाय `purge_all` जैसा स्पष्ट कार्रवाई नाम माँगें। लक्षित मोड में खाली होस्ट और पाथ फ़ील्ड अस्वीकार करें। ऑपरेटर से प्रोडक्शन वातावरण और पूरी नाम वाली सेवा को लक्ष्य के रूप में मंज़ूर कराएँ। सिर्फ़ इसलिए किसी सामान्य सेशन की मंज़ूरी को यह कार्रवाई कवर न करने दें कि इसी एजेंट ने पहले एक मामूली URL पर्ज किया था।

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

## होस्ट, पाथ और टैग संख्या बटन के ऊपर रखें

मंज़ूरी कार्ड को वास्तविक लक्ष्य और दायरे से शुरू होना चाहिए, क्योंकि ऑपरेटर समय के दबाव में पढ़ते हैं। पहले प्रदाता और प्रोडक्शन वातावरण रखें, फिर होस्टनेम, नॉर्मलाइज़ किया पाथ, टैग संख्या, अनुमानित पहुँच और कार्रवाई की श्रेणी। सहायक जानकारी नीचे खोली जा सकती है, लेकिन निर्णय बदलने वाली बातें बिना क्लिक के दिखनी चाहिए।

प्रदाता से स्वतंत्र प्रीव्यू इस रूप का हो सकता है:

```json
{
  "operation": "targeted_invalidation",
  "provider": "example-cdn",
  "environment": "production",
  "hosts": ["assets.example.test"],
  "paths": ["/releases/2026-07-24/*"],
  "tag_count": 2,
  "tag_samples": ["release:842", "asset:bundle"],
  "selector_logic": "host AND path AND (tag OR tag)",
  "estimated_reach": {
    "objects": {"low": 1600, "high": 2300},
    "method": "tag-index snapshot",
    "observed_at": "2026-07-24T14:31:08Z"
  },
  "refill": "origin requests expected on subsequent misses"
}
```

ये संख्याएँ उदाहरण हैं, यह वादा नहीं कि CDN हर सक्रिय एज ऑब्जेक्ट गिन सकता है। आउटपुट का रूप अहम है: एक सीमा, उसका तरीका और निरीक्षण का समय। अगर अनुमान लगाने वाले के पास भरोसेमंद इनपुट नहीं है, तो `"objects": "unknown"` लौटाएँ और कारण बताएँ।

होस्ट कम हों तो सभी दिखाएँ। लंबी सूची के लिए संख्या और क्रम से शुरुआती कुछ नाम दिखाएँ, और बाकी देखने का स्पष्ट तरीका दें। प्रोडक्शन और स्टेजिंग को मिलाने वाली सूची को कभी “12 होस्ट” में न समेटें। वातावरण की सीमाएँ संख्या से ज़्यादा निर्णय को प्रभावित करती हैं।

पाथ के साथ नॉर्मलाइज़ किया मान और मिलान नियम, दोनों चाहिए। Google Cloud CDN पर `/picture*` और `/picture/*` एक ही सेलेक्टर नहीं हैं: पहला `/pictures/dog.jpg` और `/picture1.jpg` जैसे पाथ से भी मिलता है, जबकि दूसरा डायरेक्टरी के नीचे ही रहता है। CloudFront में वाइल्डकार्ड को अंत में रखना ज़रूरी है; दूसरी जगह का तारांकन सामान्य अक्षर माना जाता है। सिर्फ़ कच्चे अक्षर दिखाने वाला प्रीव्यू ऑपरेटर को बिल्कुल गलत समय पर प्रदाता की व्याकरण याद करने को मजबूर करता है।

टैग संख्या की भाषा भी सावधानी से चुनें। “2 टैग” का अर्थ दो सेलेक्टर है, दो कैश ऑब्जेक्ट नहीं। टैग में संवेदनशील टेनेंट जानकारी न हो तो असली टैग दिखाएँ; हो तो स्थिर छिपे हुए लेबल और सुरक्षित विवरण दृश्य दें। बताएँ कि टैग OR से जुड़ते हैं या AND से। Google Cloud CDN एक अनुरोध के कई टैग को OR मानता है, जबकि टैग फ़िल्टर को होस्ट और पाथ मिलान के साथ जोड़ने पर प्रतिच्छेद से नतीजा सीमित होता है। तर्क की यह छोटी पंक्ति अक्सर असर के ज़्यादातर दायरे को समझा देती है।

## अनुमानित पहुँच को CDN की गिनती की सीमा माननी चाहिए

अनुमानित पहुँच को इस सवाल का जवाब देना चाहिए कि “कितनी कैश स्थिति बदल सकती है”, लेकिन वितरित कैश को इन्वेंट्री डेटाबेस नहीं बताना चाहिए। एज ऑब्जेक्ट समय पूरा होने, निकाले जाने, क्षेत्रीय माँग और बैकग्राउंड में दोबारा भरे जाने से आते-जाते रहते हैं। कई CDN पर्ज API सेलेक्टर लेते हैं, लेकिन पहले से कोई गिनती नहीं देते।

एक तय क्रम में सबसे अच्छा उपलब्ध प्रमाण इस्तेमाल करें। API में उपलब्ध हाल की प्रदाता गिनती सबसे मजबूत है। उसके बाद डिप्लॉयमेंट के नियंत्रण वाला टैग इंडेक्स आता है, जो दर्ज करता है कि हर टैग किन URL को मिला। फिर बताए गए समय की अनुरोध लॉग या कैश स्थिति टेलीमेट्री इस्तेमाल करें। कॉन्फ़िगर किए गए रूट की सूची एक मोटी ऊपरी सीमा दे सकती है। इनमें से कुछ भी न हो, तो अज्ञात बताएँ।

हर अनुमान में चार गुण होने चाहिए:

- इकाई, जैसे कैश ऑब्जेक्ट, URL वेरिएंट या हाल के कैश हिट अनुरोध।
- एक बिंदु अनुमान या सीमा, बिना लेबल का पूर्णांक नहीं।
- स्रोत और निरीक्षण का समय।
- स्रोत के प्रकार और उम्र से कोड द्वारा निकाला गया भरोसे का लेबल।

हाल के अनुरोधों की मात्रा को ऑब्जेक्ट संख्या में न बदलें। “पिछले घंटे में लगभग 80,000 कैश हिट अनुरोध इस प्रीफ़िक्स से मिले” असर का उपयोगी प्रमाण है, लेकिन इसका मतलब 80,000 ऑब्जेक्ट इनवैलिड होना नहीं है। उपलब्ध हों तो दोनों माप दिखाएँ: अनुमानित ऑब्जेक्ट कैश स्थिति बताते हैं; हाल के हिट संभावित रीफ़िल दबाव और उपयोगकर्ता असर बताते हैं।

सटीक URL के लिए भी पहुँच एक से ज़्यादा हो सकती है। CloudFront का दस्तावेज़ बताता है कि फ़ाइल इनवैलिड करने से आगे भेजी गई कुकी या हेडर पर आधारित कैश वेरिएंट भी इनवैलिड होते हैं। क्वेरी स्ट्रिंग का व्यवहार कॉन्फ़िगरेशन और सेलेक्टर पर निर्भर है। वास्तविक व्यवहार ऐसा हो तो प्रीव्यू को “1 URL, सभी कुकी और हेडर वेरिएंट” कहना चाहिए। सिर्फ़ एक ऑब्जेक्ट की संख्या अहम बात छिपा देगी।

टैग के लिए योग नहीं, यूनियन का अनुमान लगाएँ। अगर `release:842` में 1,700 ऑब्जेक्ट और `asset:bundle` में 900 ऑब्जेक्ट हैं, तो दोनों में मौजूद ऑब्जेक्ट एक बार गिने जाने चाहिए। प्रदाता टैग पर OR लागू करे, तो दोनों संख्या जोड़ने से पहुँच बढ़ा-चढ़ाकर दिख सकती है। मंज़ूरी सीमा के लिए अधिक अनुमान कम अनुमान से सुरक्षित है, लेकिन फिर भी भरोसा कम करता है। स्थानीय इंडेक्स से संभव हो तो असली यूनियन निकालें, वरना कुल को ऊपरी सीमा बताएँ।

पूरे पर्ज के लिए सटीक संख्या बनाने में समय न गँवाएँ। “पूरी प्रोडक्शन सेवा” कहें, कॉन्फ़िगर किए होस्ट की संख्या दिखाएँ, और ओरिजिन दबाव के संकेत के रूप में हाल के कैश हिट की मात्रा जोड़ें। कार्रवाई की श्रेणी ऑपरेटर को कैश की सीमा पहले ही बताती है। झूठी सटीकता कार्ड को जानकार दिखाती है, पर निर्णय में मदद नहीं करती।

## प्रीव्यू को रीफ़िल के नतीजे दिखाने चाहिए

पर्ज बाद के अनुरोधों का गंतव्य बदलता है, इसलिए मंज़ूरी में सेलेक्टर के साथ रीफ़िल व्यवहार भी बताना चाहिए। संचालन का जोखिम अक्सर पुराने कॉन्टेंट का हटना नहीं होता। जोखिम कैश मिस की एक केंद्रित लहर है, जो ऐसे ओरिजिन पर पहुँचती है जिसकी क्षमता इस मान्यता पर तय थी कि कैश अनुरोधों को रोक लेगा।

Google Cloud का दस्तावेज़ केवल ज़रूरी कॉन्टेंट इनवैलिड करने की सलाह देता है, क्योंकि बहुत व्यापक इनवैलिडेशन उन अनुरोधों को इंस्टेंस या बकेट पर वापस भेज सकता है जिन्हें कैश संभाल रहे थे। वह यह जाँचने को भी कहता है कि पर्ज से पहले ओरिजिन सही कॉन्टेंट लौटा रहा है, वरना CDN गलत जवाब को फिर कैश कर सकता है। यह दूसरी बात एजेंट के काम में पहले से पूरी होने वाली शर्त बननी चाहिए: पर्ज प्रस्तावित करने से पहले ओरिजिन पर नया ऑब्जेक्ट जाँचें।

Fastly हार्ड और सॉफ़्ट पर्ज के बीच एक और उपयोगी अंतर करता है। हार्ड पर्ज कैश कॉन्टेंट को आगे के अनुरोधों के लिए अनुपलब्ध बना देता है। सॉफ़्ट पर्ज उसे पुराना चिह्नित करता है, जिससे कॉन्फ़िगरेशन के अनुसार कैश दोबारा जाँच के दौरान पुराना कॉन्टेंट परोस सकता है। Fastly पूरे पर्ज के लिए सॉफ़्ट पर्ज नहीं देता। सिर्फ़ “पर्ज” कहने वाली मंज़ूरी इस संचालन अंतर को मिटा देती है।

इसलिए प्रीव्यू में ये बातें होनी चाहिए:

- कार्रवाई हार्ड इनवैलिडेशन, सॉफ़्ट इनवैलिडेशन या प्रदाता की अपनी डिलीट कार्रवाई है।
- रीफ़्रेश के दौरान पुराना कॉन्टेंट परोसा जा सकता है या नहीं।
- उपलब्ध होने पर चुने दायरे के लिए हाल की कैश हिट अनुरोध दर।
- वह ओरिजिन या बैकएंड समूह जिसे मिस मिलेंगे।
- ओरिजिन तैयारी जाँच पास हुई या नहीं, और कब हुई।

“2,300 ओरिजिन अनुरोध होंगे” जैसे वादे न करें। अनुरोधों का एक साथ जुड़ना, क्षेत्रीय वितरण, ब्राउज़र कैश, शील्डिंग और नए रीफ़िल वास्तविक लोड बदलते हैं। हाल का मापा ट्रैफ़िक इस्तेमाल करें और उसे ईमानदारी से बताएँ: “चुने दायरे ने पिछले 15 मिनट में 46,000 कैश हिट दिए।” यह किसी गढ़े हुए अनुमान से ऑपरेटर को कहीं ज़्यादा जानकारी देता है।

एजेंट को बिना रोक वाली शेल से अपनी तैयारी जाँच चलाकर उसका सार नहीं बताना चाहिए। गेटवे को तय जाँच लक्ष्य ओरिजिन पर चलानी, जवाब की स्थिति और कॉन्टेंट संस्करण दर्ज करना, और वह प्रमाण प्रीव्यू के साथ जोड़ना चाहिए। वरना प्रभावित निर्देश उसी बातचीत में ओरिजिन को तैयार बता सकता है जिसमें वह मंज़ूरी माँग रहा है।

## नॉर्मलाइज़ेशन डिस्प्ले और एक्ज़ीक्यूशन की खाई बंद करता है

गेटवे को कैनोनिकल कार्रवाई मंज़ूर करके वही कार्रवाई चलानी चाहिए। UI एक रूप दिखाए और प्रदाता अडैप्टर दूसरा भेजे, तो मंज़ूरी केवल दिखावा बन जाती है।

कैनोनिकल रूप टाइप किए हुए फ़ील्ड से शुरू होता है। `hosts`, `paths`, `tags`, `purge_all`, `soft`, `provider`, `service_id` और `environment` को अलग रखें। मुक्त रूप में लिखी curl कमांड को मंज़ूरी ऑब्जेक्ट न मानें। अडैप्टर अंत में HTTP बना सकता है, लेकिन नीति और डिस्प्ले कोड को जाँचे हुए डेटा पर काम करना चाहिए।

फिर श्रेणी तय करने से पहले प्रदाता के नियम लागू करें। होस्टनेम को छोटे अक्षर में करें, अंत की DNS बिंदी हटाएँ, भीतर जुड़े क्रेडेंशियल अस्वीकार करें, सेवा एलियस सुलझाएँ, और फ़्रैगमेंट को अनुरोध का हिस्सा माने बिना पाथ पार्स करें। CDN पाथ के बड़े-छोटे अक्षर अलग मानता हो तो उनका रूप बनाए रखें। प्रदाता जैसी URL नॉर्मलाइज़ेशन और रीराइट जानकारी इस्तेमाल करें। Cloudflare चेतावनी देता है कि Transform Rules वाले प्रीफ़िक्स पर्ज में बदलाव के बाद का ओरिजिन URL इस्तेमाल करना चाहिए। CloudFront सलाह देता है कि व्यूअर अनुरोध फ़ंक्शन पाथ बदले तो उपयोगकर्ता वाला URI और बदला हुआ URI, दोनों इनवैलिड करें। प्रीव्यू को दूसरा पाथ चुपचाप जोड़ने के बजाय दोनों वास्तविक पाथ दिखाने चाहिए।

नॉर्मलाइज़ेशन के बाद एक छोटा वर्गीकरण फ़ंक्शन खतरनाक मामलों को रोक सकता है:

```text
if purge_all is true:
    return PURGE_ALL
if any normalized path covers the root:
    return PURGE_ALL
if any tag is cataloged as service_wide:
    return PURGE_ALL
if selectors are empty:
    return REJECT
return TARGETED
```

प्रदाता अडैप्टर को उनकी अपनी व्याकरण पर आधारित टेस्ट चाहिए। रूट पाथ, एनकोड किए सेपरेटर, दोहराए और आखिरी स्लैश, वाइल्डकार्ड की जगह, खाली एरे, मिले-जुले होस्ट, क्वेरी स्ट्रिंग और रीराइट URL शामिल करें। प्रॉपर्टी टेस्ट जाँच सकते हैं कि नॉर्मलाइज़ेशन कभी एक्ज़ीक्यूशन का दायरा दिखाए दायरे से बड़ा न करे। रिग्रेशन फ़िक्सचर में नॉर्मलाइज़ किया प्रीव्यू और सटीक बाहर जाने वाला अनुरोध साथ रखें।

अंत में कैनोनिकल कार्रवाई और प्रीव्यू की अहम मेटाडेटा पर डाइजेस्ट निकालें। मंज़ूरी रिकॉर्ड में व्यक्ति, एजेंट प्रक्रिया, टूल नाम, नॉर्मलाइज़ किए पैरामीटर, वातावरण, अनुमान का समय, डाइजेस्ट और समाप्ति होनी चाहिए। OWASP का AI Agent Security Cheat Sheet कार्रवाई करने वाला व्यक्ति, टूल, लक्ष्य, नॉर्मलाइज़ पैरामीटर, समय और समाप्ति रखकर मंज़ूरी को सटीक कार्रवाई से बाँधने की सलाह देता है। यही सही मानक है। एक डाइजेस्ट पर इंसानी निर्णय बाद के अलग पाथ वाले अनुरोध को अनुमति नहीं दे सकता।

## दायरा बदलने पर मंज़ूरी बंद होकर विफल होनी चाहिए

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

मंज़ूरी की अवधि छोटी रखें, क्योंकि कैश स्थिति और ट्रैफ़िक बदलते हैं। एजेंट किसी दूसरे डिप्लॉयमेंट तक रुके, तो पाथ में अलग ऑब्जेक्ट हो सकते हैं और ओरिजिन तैयारी का प्रमाण पुराना हो सकता है। समय पूरा होने पर नया प्रीव्यू बनना चाहिए, पुराने डेटा पर सिर्फ़ एक और क्लिक नहीं।

Model Context Protocol का टूल विनिर्देश कहता है कि ऐप को इंसान को टूल कॉल अस्वीकार करने देना और पुष्टि का सवाल दिखाना चाहिए। यह सही है, पर नुकसान करने वाले इन्फ़्रास्ट्रक्चर कॉल के लिए सामान्य पुष्टि बहुत कमज़ोर है। होस्ट ऐप टूल का नाम और JSON आर्ग्युमेंट जान सकता है, लेकिन सिर्फ़ एक्ज़ीक्यूशन अडैप्टर जानता है कि प्रदाता का एलियस प्रोडक्शन से जुड़ता है या `/` के साथ वाइल्डकार्ड का अर्थ सब कुछ है। सार्थक प्रीव्यू उस घटक में रखें जो इन बातों को समझकर लागू कर सकता है।

मंज़ूरी एजेंट के नियंत्रण वाले टेक्स्ट से स्वतंत्र भी होनी चाहिए। एजेंट “वापस मँगाए गए उत्पाद की तस्वीर हटाना” जैसा कारण दे सकता है, लेकिन उसे एजेंट की व्याख्या के रूप में साफ़ लेबल किए हुए दूसरे क्षेत्र में दिखाएँ। दायरे के तथ्य भरोसेमंद कोड और प्रदाता कॉन्फ़िगरेशन से बनाएँ। मंज़ूरी कार्ड के किसी फ़ील्ड में Markdown, टर्मिनल एस्केप क्रम या मनचाहा HTML न आने दें।

बड़े असर वाली कार्रवाई में अधिक रुकावट होनी चाहिए। सटीक URL के लक्षित पर्ज के लिए एक क्लिक पर्याप्त हो सकता है। बड़े प्रीफ़िक्स में दायरा दोहराकर जानबूझकर पुष्टि माँगी जा सकती है। पूरे पर्ज को अलग प्रमाणीकरण चाहिए और उसे आसपास के एजेंट सेशन की मंज़ूरी नहीं मिलनी चाहिए। Sallyport क्रेडेंशियल को एजेंट से बाहर रख सकता है, सुरक्षित CDN API की के हर इस्तेमाल पर मंज़ूरी दिखा सकता है और उससे हुई HTTP कॉल दर्ज कर सकता है; उस मंज़ूरी को उपयोगी बनाने वाले नॉर्मलाइज़ दायरा फ़ील्ड अब भी प्रदाता अडैप्टर को देने होंगे।

विफलता पर गेट बंद होना चाहिए। अनुमान लगाने में समय पूरा हो जाए तो शून्य के बजाय अज्ञात दिखाएँ। नॉर्मलाइज़ेशन विफल हो तो कच्चा इनपुट आगे भेजने के बजाय अनुरोध अस्वीकार करें। ऑडिट लॉगिंग विफल हो तो कार्रवाई न चलाएँ। भेजते समय डाइजेस्ट अलग हो तो मंज़ूरी छोड़कर नया प्रीव्यू बनाएँ।

## ऑडिट रिकॉर्ड में निर्णय और नतीजा दोनों चाहिए

पर्ज की ऑडिट ट्रेल में इंसान ने क्या देखा, गेटवे ने क्या भेजा और CDN ने क्या लौटाया, तीनों रहने चाहिए। सिर्फ़ एजेंट का टूल अनुरोध दर्ज करने से यह साबित नहीं होता कि नॉर्मलाइज़ेशन, मंज़ूरी और एक्ज़ीक्यूशन एक ही दायरे के थे।

कैनोनिकल अनुरोध, दिखाए गए प्रीव्यू फ़ील्ड, अनुमान का स्रोत, मंज़ूरी डाइजेस्ट, मंज़ूरी देने वाले की पहचान, मंज़ूरी का समय, एक्ज़ीक्यूशन का समय, प्रदाता अनुरोध ID और प्रदाता का जवाब दर्ज करें। बताएँ कि प्रदाता ने कार्रवाई स्वीकार की, पूरी की, आंशिक रूप से पूरी की या अस्वीकार की। प्रदाता बाद की स्थिति देता हो तो मूल घटना बदलने के बजाय स्थिति निरीक्षण जोड़ें।

अनुमान को नतीजे से अलग रखें। प्रदाता सफलता लौटाए, तब भी 2,000 ऑब्जेक्ट का अनुमान अनुमान ही रहता है। ज़्यादातर सफल जवाब का अर्थ है कि प्रदाता ने सेलेक्टर स्वीकार किया, यह नहीं कि उसे ठीक उतने कैश ऑब्जेक्ट मिले। ऑडिटर को स्थानीय अनुमान और CDN से आई बात में अंतर दिखना चाहिए।

CloudFront का दस्तावेज़ कहता है कि भेजने के बाद इनवैलिडेशन रद्द नहीं किया जा सकता, क्योंकि एज स्थान जल्दी उसे प्रोसेस करना शुरू कर देते हैं। इसलिए एक्ज़ीक्यूशन से पहले का रिकॉर्ड खास तौर पर अहम है। रिवोक बटन एजेंट की भावी कॉल रोक सकता है, लेकिन एज पर पहले से भेजा पर्ज वापस नहीं खींच सकता। ऑडिट इंटरफ़ेस को ऐसा संकेत नहीं देना चाहिए।

जाँच के दौरान इन सवालों का जवाब चैट पढ़े बिना मिलना चाहिए:

- किस हस्ताक्षरित एजेंट प्रक्रिया ने कार्रवाई प्रस्तावित की?
- किस इंसान ने कौन-सा कैनोनिकल डाइजेस्ट मंज़ूर किया?
- कार्ड ने कार्रवाई को लक्षित माना या पूरा पर्ज?
- कार्ड पर कौन-से होस्ट, पाथ और टैग थे?
- उस समय पहुँच अनुमानक क्या जानता था?

बातचीत में एजेंट का कारण सहायक संदर्भ है, अधिकार नहीं। चैट छोटी की जा सकती है, उसका सार बन सकता है या अविश्वसनीय कॉन्टेंट उसे प्रभावित कर सकता है। एक्ज़ीक्यूशन जर्नल कार्रवाई का स्थायी रिकॉर्ड है।

स्वचालित प्रक्रिया बार-बार इन्फ़्रास्ट्रक्चर कॉल कर सके, तो छेड़छाड़ का प्रमाण अहम है। Sallyport एजेंट सेशन और अलग कॉल को एक एन्क्रिप्टेड, हैश-चेन वाले ऑडिट लॉग से दर्ज करता है, इसलिए टीम उसकी सामग्री पढ़े बिना चेन अलग से जाँच सकती है। इससे गलत पर्ज वापस नहीं होता, लेकिन कार्रवाई संभालने वालों को प्रस्ताव, मंज़ूरी और एक्ज़ीक्यूशन का बचाव योग्य क्रम मिलता है।

## पूरा विफलता उदाहरण चार फ़ील्ड की अहमियत दिखाता है

एक एजेंट को मानें जो स्टोर की रिलीज़ तैयार कर रहा है। काम में डिप्लॉयमेंट के बाद नए उत्पाद एसेट रीफ़्रेश करने हैं। एजेंट बिल्ड मैनिफ़ेस्ट में `/products/` देखता है और प्रीफ़िक्स पर्ज चुनता है, क्योंकि यह हैश वाली फ़ाइल गिनाने से आसान है।

कच्चे अनुरोध में एक पाथ है। कमज़ोर डायलॉग “1 पाथ पर्ज करें?” दिखाता है और ऑपरेटर मंज़ूर कर देता है। CDN हर कॉन्फ़िगर होस्ट पर प्रीफ़िक्स लागू करता है, जिसमें सार्वजनिक स्टोर, एक क्षेत्रीय होस्ट और इमेज होस्ट शामिल हैं। रूट में उत्पाद पेज, थंबनेल, इन्वेंट्री फ़्रैगमेंट और पुराने रिलीज़ एसेट भी हैं। लोकप्रिय ऑब्जेक्ट एक साथ कैश से हटते हैं और फिर उसी ओरिजिन समूह से दोबारा भरे जाते हैं।

उपयोगी प्रीव्यू एक्ज़ीक्यूशन से पहले निर्णय बदल देता है। वह दिखाता है:

1. **होस्ट:** तीन प्रोडक्शन होस्ट, उनके नाम साफ़ दिखते हुए।
2. **पाथ:** `/products/*`, एक फ़ाइल के बजाय रिकर्सिव प्रीफ़िक्स के रूप में।
3. **टैग:** कोई नहीं, जबकि मौजूदा रिलीज़ का अपना टैग है।
4. **अनुमानित पहुँच:** 38,000 URL वेरिएंट और हाल के 12 लाख कैश हिट अनुरोध, दोनों पर स्रोत और समय सीमा के लेबल।

ऑपरेटर अनुरोध अस्वीकार करता है। फिर एजेंट सिर्फ़ एसेट होस्ट पर रिलीज़ टैग प्रस्तावित करता है। गेटवे इंडेक्स किए हुए 1,840 ऑब्जेक्ट पाता है, बताता है कि दो टैग मान OR से जुड़ते हैं, और दिखाता है कि कार्रवाई उत्पाद HTML और इन्वेंट्री जवाब को छोड़ती है। ओरिजिन जाँच वर्तमान रिलीज़ पहचान की पुष्टि करती है। ऑपरेटर छोटे दायरे वाले डाइजेस्ट को मंज़ूर करता है।

इस उदाहरण की संख्याएँ सिर्फ़ समझाने के लिए हैं; यह विफलता आम है क्योंकि प्रीफ़िक्स सिंटैक्स सस्ता दिखता है। इसका उपाय एजेंट के लिए ज़्यादा चतुर प्रॉम्प्ट नहीं है। एक्ज़ीक्यूशन सीमा को बड़े सेलेक्टर साफ़ दिखाने और इंसान को छोटा विकल्प देने चाहिए।

यही तरीका एक और गलती पकड़ता है: एजेंट स्टेजिंग पर्ज माँगता है, लेकिन सेवा एलियस प्रोडक्शन में सुलझता है। प्रीव्यू सिर्फ़ “सेवा `storefront`” कहे तो ऑपरेटर इसे छोड़ सकता है। पहले “प्रोडक्शन” दिखाकर सार्वजनिक होस्ट गिनाए जाएँ, तो अंतर साफ़ है।

यह उदाहरण यह भी बताता है कि टैग संख्या पहुँच की जगह क्यों नहीं ले सकती। एक रिलीज़ टैग 1,840 ऑब्जेक्ट बता सकता है, जबकि सटीक URL के बीस टैग बीस ऑब्जेक्ट बताते हैं। सेलेक्टर संख्या और अनुमानित मिलान अलग तथ्यों के रूप में दिखाएँ। पहला अनुरोध बताता है। दूसरा उसका संभावित असर बताता है।

## सुरक्षा सीमा को चलने वाले अनुबंध की तरह दें

टीमों को पर्ज प्रीव्यू एजेंट टूल, प्रदाता अडैप्टर, मंज़ूरी UI और ऑडिट लॉग के बीच अनुबंध के रूप में बनाना चाहिए। अनुबंध इतना छोटा है कि उसे टेस्ट किया जा सकता है: नॉर्मलाइज़ इनपुट अंदर जाता है, श्रेणी वाला और डाइजेस्ट से बँधा प्रीव्यू बाहर आता है, और एक्ज़ीक्यूशन सिर्फ़ उस डाइजेस्ट की समय के भीतर की मंज़ूरी स्वीकार करता है।

कम से कम ये अपरिवर्तनीय नियम रखें:

- लक्षित मोड में कम से कम एक रूट से अलग सेलेक्टर और स्पष्ट वातावरण हो।
- पूरे पर्ज का अपना कार्रवाई नाम हो और वह खाली फ़ील्ड से न निकल सके।
- दिखाया गया होस्ट, पाथ, टैग संख्या और सेलेक्टर तर्क कैनोनिकल पैरामीटर से आए।
- पहुँच किसी स्रोत वाली सीमा, ऊपरी सीमा, ट्रैफ़िक माप या स्पष्ट अज्ञात के रूप में हो।
- एक्ज़ीक्यूशन डाइजेस्ट फिर निकाले और बदले पैरामीटर अस्वीकार करे।

हर समर्थित CDN कार्रवाई के लिए रिकॉर्ड किए केस पर अडैप्टर चलाएँ। बाहर जाने वाले अनुरोध को प्रीव्यू स्नैपशॉट से मिलाएँ। ऐसी कैनरी सेवा जोड़ें जिसका ओरिजिन पर्ज सह सके, फिर सटीक URL, प्रीफ़िक्स, टैग यूनियन, होस्ट सीमा, रीराइट पाथ और पूरा पर्ज जाँचें। सिर्फ़ एजेंट इनपुट दोहराने वाला ड्राई रन कुछ साबित नहीं करता; टेस्ट को नॉर्मलाइज़ेशन और प्रदाता अनुरोध बनाना चलाना चाहिए।

सामान्य रिलीज़ के लिए संस्करण वाला कॉन्टेंट रखें। Google Cloud दस्तावेज़ नियमित इनवैलिडेशन की जगह सही समय सीमा या अलग संस्करण URL की सलाह देता है, और यह सलाह सही है। पर्ज सुधार, वापसी और उन मामलों के लिए हैं जहाँ TTL का इंतज़ार नहीं किया जा सकता। हर डिप्लॉयमेंट पर पर्ज करने वाला एजेंट एक अपवाद नियंत्रण को ओरिजिन क्षमता की छिपी निर्भरता बना देता है।

पर्ज सही हो, तो प्रीव्यू से तेज़ मंज़ूरी संभव होनी चाहिए। ऑपरेटर को प्रदाता JSON समझे बिना `assets.example.test`, `/releases/842/*`, दो टैग और 1,600 से 2,300 ऑब्जेक्ट का अनुमान दिखना चाहिए। पूरे पर्ज के लिए कार्ड के उसी स्थान पर “पूरी प्रोडक्शन सेवा” लिखा होना चाहिए और छोटी अनुरोध संख्या से इस बात को हल्का नहीं करना चाहिए।

मेरी जाँच सीधी है: क्या ऑपरेटर मंज़ूरी बटन के ऊपर सिर्फ़ भरोसेमंद फ़ील्ड देखकर दो सेकंड में एक एसेट रीफ़्रेश और पूरी सेवा पर्ज में अंतर कर सकता है? अगर नहीं, तो एजेंट को अभी वह CDN कार्रवाई नहीं मिलनी चाहिए।