प्रॉम्प्ट सेव किए बिना AI एजेंट की कार्रवाई की समीक्षा कैसे काम करती है

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

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

समीक्षा रिकॉर्ड को बातचीत के बजाय कार्रवाई का अनुसरण करना चाहिए। इससे डेटा के अनावश्यक खुलासे का जोखिम घटता है और ऐसा प्रमाण मिलता है जिसे ऑपरेटर सचमुच इस्तेमाल कर सकता है।

एक्शन रिकॉर्ड ट्रांसक्रिप्ट से अलग सवाल का जवाब देता है

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

मान लीजिए कोई एजेंट एक लंबी इश्यू थ्रेड पढ़ता है, रिपॉज़िटरी देखता है, रिलीज़ नोट का मसौदा बनाता है और डिप्लॉयमेंट बनाने के लिए API कॉल करता है। बातचीत का एक्सपोर्ट हज़ारों पंक्तियों का हो सकता है। सार्थक समीक्षा रिकॉर्ड इससे बहुत छोटा हो सकता है:

• प्रोसेस पहचान और सेशन पहचानकर्ता।
• उस कार्रवाई को कवर करने वाला ऑथराइज़ेशन निर्णय।
• गंतव्य, मेथड, रिसोर्स श्रेणी और क्रेडेंशियल संदर्भ।
• परिणाम, जिसमें स्टेटस और सुरक्षित परिणाम सारांश शामिल हो।
• टाइमस्टैम्प और इंटेग्रिटी डेटा।

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

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

बातचीत की सामग्री विकास परिवेश में तभी रखें जब उसे बनाए रखने का स्पष्ट कारण हो, जैसे गुणवत्ता जाँच या किसी खास घटना की जाँच। जवाबदेही के नाम पर उसे ऑडिट सिस्टम में न डालें।

पूरे प्रॉम्प्ट ऐसे डेटा स्टोर बना देते हैं जिसकी सुरक्षा की किसी ने योजना नहीं बनाई

पूरे प्रॉम्प्ट कैप्चर करने से एक्शन लॉग उच्च जोखिम वाले कंटेंट आर्काइव में बदल जाता है। यह जोखिम केवल स्पष्ट सीक्रेट तक सीमित नहीं है।

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

आम बचाव यह होता है, «हम सीक्रेट को रिडैक्ट कर देंगे।» यह तभी काम करता है जब स्टोरेज से पहले लॉगिंग पाथ हर सीक्रेट फॉर्मेट को देखे और हर प्रोटोकॉल को समझे। यह कम समय के लिए मान्य साइन किए गए URL, सेशन कुकी, निजी टोकन फॉर्मेट, JSON स्ट्रिंग में छिपे सीक्रेट और किसी सेवा द्वारा त्रुटि के अंदर लौटाए गए क्रेडेंशियल को छोड़ देगा। व्यापक समूह द्वारा मूल रिकॉर्ड पढ़ लिए जाने के बाद रिडैक्शन गोपनीयता वापस नहीं ला सकता।

OWASP की Logging Cheat Sheet एक उपयोगी अंतर बताती है: लॉग मॉनिटरिंग और जाँच में मदद करें, लेकिन सिस्टम को एक्सेस टोकन, पासवर्ड, कनेक्शन स्ट्रिंग, एन्क्रिप्शन कुंजी या ऐसा डेटा लॉग नहीं करना चाहिए जिसके संग्रह से गोपनीयता का अनावश्यक जोखिम पैदा हो। एजेंट की समीक्षा में इस सलाह को कम नहीं, बल्कि अधिक सख्ती से लागू करें। एजेंट का संदर्भ असामान्य रूप से व्यापक होता है, इसलिए उसमें सामान्य अनुरोध लॉग की तुलना में कहीं अधिक अनचाही सामग्री आ सकती है।

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

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

प्रोसेस पहचान को आसान नाम से आगे तक बनाए रखें

प्रोसेस का नाम किसी एजेंट की पहचान नहीं बताता। agent, node, python और shell जैसे नाम समीक्षक को लगभग कुछ नहीं बताते। कोई दुर्भावनापूर्ण या लापरवाह प्रोग्राम इनमें से कोई भी नाम चुन सकता है।

सेशन शुरू करने वाले प्रोग्राम को अलग पहचानने के लिए पर्याप्त पहचान डेटा रिकॉर्ड करें:

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

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

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

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

ऑथराइज़ेशन में दायरा, समय और स्वीकृति देने वाला व्यक्ति होना चाहिए

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

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

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

एक व्यावहारिक ऑथराइज़ेशन ऑब्जेक्ट ऐसा दिख सकता है:

{
  "authorization_id": "auth_7f3c",
  "kind": "session",
  "decision": "approved",
  "approved_at": "2025-03-08T14:22:31Z",
  "approver": "local-account:maya",
  "process_session": "sess_31a9",
  "process_identity": {
    "executable": "/Applications/Agent.app/Contents/agent",
    "signing_authority": "Example Development Team"
  },
  "scope": {
    "credential_refs": ["deploy-production"],
    "expires_when": "process exits"
  }
}

ऊपर दिए गए नाम और पहचानकर्ता उदाहरण हैं, लेकिन संरचना महत्वपूर्ण है। approver स्थानीय अकाउंट की पहचान है, यह दावा नहीं कि किसी नामित व्यक्ति ने आउटपुट की हर पंक्ति देखी। क्रेडेंशियल संदर्भ एक लेबल या आंतरिक ID है, स्वयं क्रेडेंशियल नहीं। scope बताता है कि निर्णय पूरे सेशन या एक कॉल पर लागू था।

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

अनुरोध का मेटाडेटा पार की गई सीमा का वर्णन करे

समीक्षक को ऑपरेशन का दायरा समझने के लिए पर्याप्त अनुरोध मेटाडेटा चाहिए, लेकिन ऑपरेशन की कच्ची कॉपी नहीं। HTTP के लिए सेवा होस्ट, ज़रूरत होने पर पोर्ट, मेथड, सामान्यीकृत रूट टेम्पलेट, क्रेडेंशियल संदर्भ, अनुरोध का आकार, कॉरिलेशन ID और सुरक्षित कैनोनिकल प्रतिनिधित्व का डाइजेस्ट रिकॉर्ड करें।

सामान्यीकृत रूट टेम्पलेट का मतलब है ऐसे शाब्दिक URL के बजाय /v1/projects/{project_id}/deployments रिकॉर्ड करना जिसमें ग्राहक पहचानकर्ता या सीक्रेट जैसा अपारदर्शी मान हो। कच्चा रूट गंतव्य सेवा के पास रह सकता है, क्योंकि उस डेटा की मालिक वही है और उसके पास अपने पहुँच नियंत्रण हैं।

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

HTTP Semantics, RFC 9110, अनुरोध मेथड के अर्थों, जैसे safe, idempotent और unsafe मेथड, के बीच अंतर करता है। इस अंतर को समीक्षा संकेत की तरह इस्तेमाल करें, ऑथराइज़ेशन के शॉर्टकट की तरह नहीं। GET संवेदनशील डेटा उजागर कर सकता है। PUT idempotent हो सकता है और फिर भी प्रोडक्शन कॉन्फ़िगरेशन बदल सकता है। POST ऐसा अपरिवर्तनीय बाहरी प्रभाव पैदा कर सकता है जिसे वापस लेना संभव न हो। मेथड समीक्षक को कार्रवाई के बारे में सोचने में मदद करता है, लेकिन असली जोखिम गंतव्य और रूट तय करते हैं।

मेटाडेटा की allowlist वाला स्कीमा इस्तेमाल करें। पूरे अनुरोध ऑब्जेक्ट से शुरुआत करके बाद में फ़ील्ड हटाने की कोशिश न करें। सुरक्षित तरीका यह है कि पहले तय करें कि एक्शन रिकॉर्ड में कौन-से फ़ील्ड हो सकते हैं, फिर बाकी को अस्वीकार या बदल दें।

{
  "call_id": "call_c24e",
  "session_id": "sess_31a9",
  "channel": "https",
  "destination": "api.example.internal",
  "method": "POST",
  "route_template": "/v1/projects/{project_id}/deployments",
  "credential_ref": "deploy-production",
  "request_bytes": 842,
  "request_digest": "sha256:6d1d...",
  "started_at": "2025-03-08T14:24:09Z"
}

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

परिणामों में ऑपरेशनल प्रमाण हो, रिस्पॉन्स डंप नहीं

परिणाम रिकॉर्ड में यह बताया जाना चाहिए कि गंतव्य ने क्या रिपोर्ट किया और गेटवे ने माँगा गया ऑपरेशन पूरा किया या नहीं। इसमें डिफ़ॉल्ट रूप से पूरा रिस्पॉन्स बॉडी सेव नहीं होना चाहिए।

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

SSH कार्रवाई के लिए एग्ज़िट कोड, अवधि, होस्ट पहचान का परिणाम और कमांड अडैप्टर द्वारा चुना गया सारांश रखें। अगर किसी कमांड को सफल काम का प्रमाण देना हो, तो उससे {\"release\":\"r42\",\"status\":\"published\"} जैसा सीमित मशीन-पठनीय परिणाम निकलवाएँ। मनमाने टर्मिनल ट्रांसक्रिप्ट को ऑडिट परिणाम के रूप में स्वीकार न करें।

विफलताओं के दौरान यह अंतर खास मायने रखता है। मान लीजिए डिप्लॉय कॉल HTTP 403 लौटाती है और उसके डायग्नोस्टिक ऑब्जेक्ट में कॉल करने वाले का ऑथराइज़ेशन हेडर वापस आ जाता है। एजेंट त्रुटि देखता है, दो बार फिर कोशिश करता है और हर प्रयास अलग लॉग एंट्री बनाता है। लापरवाह समीक्षा सिस्टम में अब खुले हुए क्रेडेंशियल की तीन कॉपियाँ हैं, जो ऐसी घटना के तहत इंडेक्स हैं जिसे और लोग खोलेंगे।

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

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

समीक्षा स्कीमा में प्रतिबंधित फ़ील्ड साफ दिखाई देने चाहिए

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

नीचे का उदाहरण पहचान, ऑथराइज़ेशन, कार्रवाई मेटाडेटा, परिणाम और इंटेग्रिटी जानकारी को जोड़ता है। इसमें जानबूझकर prompt, messages, headers, request_body, response_body और stderr फ़ील्ड नहीं हैं।

{
  "event_type": "external_action",
  "event_id": "evt_91bd",
  "occurred_at": "2025-03-08T14:24:10Z",
  "actor": {
    "local_account": "maya",
    "process_session": "sess_31a9",
    "pid": 4812,
    "parent_pid": 4601,
    "executable_digest": "sha256:2a84...",
    "signing_authority": "Example Development Team"
  },
  "authorization": {
    "authorization_id": "auth_7f3c",
    "mode": "session",
    "decision": "approved"
  },
  "action": {
    "channel": "https",
    "destination": "api.example.internal",
    "operation": "POST /v1/projects/{project_id}/deployments",
    "credential_ref": "deploy-production",
    "request_digest": "sha256:6d1d..."
  },
  "result": {
    "category": "completed",
    "status_code": 201,
    "destination_request_id": "req_18c7",
    "duration_ms": 614
  },
  "integrity": {
    "previous_event_digest": "sha256:8f50...",
    "event_digest": "sha256:bd7e..."
  }
}

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

समीक्षकों को घटना का पढ़ने योग्य रूप भी चाहिए। यह रूप कैनोनिकल रिकॉर्ड से बनाएँ, अलग से हाथ से लिखी गई कहानी न रखें। मानव-पठनीय एंट्री कुछ ऐसी हो सकती है: «स्वीकृत प्रोसेस सेशन ने deploy-production का इस्तेमाल करके api.example.internal पर डिप्लॉयमेंट बनाया। सेवा ने 614 ms में 201 लौटाया।» जर्नल में घटना की जाँच के लिए ज़रूरी पहचानकर्ता रहें, लेकिन डिफ़ॉल्ट दृश्य में अतिरिक्त सामग्री न दिखे।

इंटेग्रिटी बदलाव साबित करती है, पूर्णता नहीं

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

NIST SP 800-92, Guide to Computer Security Log Management, संगठनों को लॉग की इंटेग्रिटी सुरक्षित रखने, यह तय करने और स्पष्ट ऑपरेशनल मालिक के साथ लॉग की समीक्षा करने की सलाह देता है कि कौन-सी घटनाएँ लॉग की जानी चाहिए। उपयोगी बात इन सबका मेल है। स्पष्ट घटना सीमा के बिना इंटेग्रिटी आपको अधूरी कहानी के भरोसेमंद रिकॉर्ड देती है। इंटेग्रिटी के बिना लंबी घटना सूची ऐसी कहानी देती है जिसे कोई चुपचाप बदल सकता है।

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

सामान्य लॉग पढ़ने से अलग सत्यापन रखें। सत्यापन कमांड को संग्रहित एन्क्रिप्टेड रिकॉर्ड पर काम करना चाहिए और बताना चाहिए कि चेन सही है या नहीं। Sallyport यह जाँच sp audit verify के ज़रिए उपलब्ध कराता है। यह वॉल्ट कुंजी के बिना अपने एन्क्रिप्टेड हैश-चेन वाले ऑडिट लॉग को सत्यापित करता है। यह डिज़ाइन महत्वपूर्ण है, क्योंकि जाँचकर्ता को क्रेडेंशियल की पहुँच पाए बिना रिकॉर्ड की निरंतरता जाँचने में सक्षम होना चाहिए।

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

पहुँच और रिटेंशन तय करते हैं कि जर्नल खुद एक और डेटा लीक बनेगा या नहीं

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

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

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

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

रिकॉर्ड गेटवे पर बनाएँ, फिर खराब रास्तों की जाँच करें

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

MCP-सक्षम एजेंट के लिए Sallyport इसी तरह काम करता है: स्थानीय sp mcp shim HTTP और SSH कार्रवाइयों को ऐप के रास्ते भेजता है और उसका एन्क्रिप्टेड वॉल्ट API तथा SSH क्रेडेंशियल को एजेंट के संदर्भ से बाहर रखता है। उसका सेशन जर्नल और एक्टिविटी जर्नल एक ही write-blind एन्क्रिप्टेड ऑडिट लॉग से तैयार होते हैं। इससे सेशन ऑथराइज़ेशन और अलग-अलग कॉल जुड़ी रहती हैं, जबकि एजेंट के पास सीक्रेट नहीं रहता।

डिज़ाइन की जाँच उन विफलताओं से करें जिन्हें सामान्य सफल डेमो अक्सर छोड़ देते हैं:

1. ऐसा अनुरोध भेजें जो गंतव्य द्वारा नकली ऑथराइज़ेशन हेडर लौटाने के बाद विफल हो। पुष्टि करें कि रिकॉर्ड में हेडर या रिस्पॉन्स बॉडी नहीं, बल्कि त्रुटि श्रेणी और स्टेटस सेव हुआ है।
2. एक ही डिस्प्ले नाम वाले लेकिन अलग एक्जीक्यूटेबल पहचान वाले दो प्रोसेस शुरू करें। पुष्टि करें कि समीक्षा दृश्य उनके सेशन अलग दिखाता है।
3. एक सेशन को मंज़ूरी दें, उसे बंद करें और नया प्रोसेस शुरू करें। पुष्टि करें कि पुरानी मंज़ूरी नए रन पर लागू नहीं होती।
4. टाइमआउट कराएँ और रीट्राई करें। पुष्टि करें कि रिकॉर्ड प्रयासों को एक कॉल से जोड़ते हैं और यह तथ्य बनाए रखते हैं कि परिणाम अनिश्चित है।
5. किसी संग्रहित टेस्ट घटना में बदलाव करें और इंटेग्रिटी सत्यापन चलाएँ। पुष्टि करें कि सत्यापक विफलता बताता है और टीम के पास लिखित प्रतिक्रिया प्रक्रिया है।

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

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