ऑडिट इतिहास

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

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

रिकॉर्ड समूह

ऑडिटिंग सक्षम होने पर रन और टूल इवेंट हमेशा रिकॉर्ड किए जाते हैं (यह डिफ़ॉल्ट है)। संदेश लाइफ़साइकल इवेंट वैकल्पिक हैं और डिफ़ॉल्ट रूप से अक्षम रहते हैं।

हर रिकॉर्ड में एक स्थिर इवेंट आईडी, एक एकदिश बढ़ता लेजर अनुक्रम, एक लाइफ़साइकल टाइमस्टैम्प, कर्ता, कार्रवाई, स्थिति, schemaVersion: 1, और redaction: "metadata_only" होता है। फ़ील्ड के पूर्ण संदर्भ और क्वेरी फ़िल्टर के लिए ऑडिट रिकॉर्ड देखें।

संदेश लाइफ़साइकल इवेंट

क्या रिकॉर्ड किया जाए यह चुनने के लिए audit.messages सेट करें, फिर Gateway को पुनः आरंभ करें:

• off (डिफ़ॉल्ट): कोई संदेश रिकॉर्ड नहीं।
• direct: केवल प्रत्यक्ष वार्तालापों के संदेश।
• all: प्रत्यक्ष, समूह और चैनल संदेश।

दो आधिकारिक सीमाएँ संदेश रिकॉर्ड उत्पन्न करती हैं:

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

वार्तालाप-प्रकार वर्गीकरण

direct मोड एक गोपनीयता सीमा है, इसलिए किसी संदेश को प्रत्यक्ष वार्तालाप के रूप में केवल तभी वर्गीकृत किया जाता है जब गंतव्य संबंधी तथ्य इसे प्रमाणित करते हों: भेजने वाले पथ ने गंतव्य वार्तालाप प्रकार घोषित किया हो, या डिलीवरी सेशन रूट ठीक उसी चैनल और पीयर का नाम देता हो जहाँ डिलीवरी की जा रही है। कमज़ोर संकेत, जैसे नीति स्थिति या आरंभिक वार्तालाप, किसी संदेश को group के रूप में वर्गीकृत कर सकते हैं (जिससे वह direct संग्रह से बाहर हो जाता है), लेकिन कभी भी direct का दावा नहीं कर सकते। जिन संदेशों का प्रत्यक्ष होना प्रमाणित नहीं किया जा सकता, उन्हें unknown के रूप में वर्गीकृत किया जाता है और direct मोड में रिकॉर्ड नहीं किया जाता। इसलिए चैट प्रकार घोषित न करने वाले चैनल direct मोड में, all मोड की तुलना में कम पंक्तियाँ रिकॉर्ड कर सकते हैं।

गोपनीयता मॉडल

संदेश पंक्तियाँ कभी भी अपरिष्कृत प्लेटफ़ॉर्म पहचानकर्ता संग्रहीत नहीं करतीं। सहसंबंध उपलब्ध होने पर अकाउंट, वार्तालाप, संदेश और लक्ष्य पहचानकर्ता केवल इंस्टॉलेशन-स्थानीय कुंजीबद्ध छद्मनामों (hmac-sha256:v1:<keyId>:<digest>) के रूप में निर्यात किए जाते हैं:

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

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

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

कवरेज और प्रमाण की सीमाएँ

लेजर सर्वोत्तम-प्रयास पर आधारित और जानबूझकर सीमित है। इसे इस बात के साक्ष्य के रूप में मानें कि क्या रिकॉर्ड किया गया था, न कि इस बात के प्रमाण के रूप में कि वास्तव में क्या हुआ:

• किसी पंक्ति का न होना कुछ भी प्रमाणित नहीं करता। प्रवेश-पूर्व इनबाउंड ड्रॉप, चालू Gateway रिकॉर्डर के बिना CLI प्रक्रियाओं से भेजे गए संदेश, और साझा टिकाऊ डिलीवरी को बायपास करने वाले Plugin-स्थानीय या प्रत्यक्ष-प्रेषण पथ कोई रिकॉर्ड नहीं छोड़ते।
• लेखन एक सीमित बैकग्राउंड वर्कर के माध्यम से होता है; वर्कर की विफलता या क्यू संतृप्ति के कारण रिकॉर्ड छोड़ दिए जाते हैं और एक संचालन चेतावनी लॉग की जाती है।
• क्रैश-अस्पष्ट आउटबाउंड प्रेषणों को मनगढ़ंत परिणामों के बजाय unknown के रूप में रिकॉर्ड किया जाता है।

यह लेजर डीबगिंग और संचालन समीक्षा में सहायक है। यह दोषरहित अनुपालन आर्काइव नहीं है; यदि आपको इसकी आवश्यकता है, तो OpenTelemetry या चैनल-स्तरीय टूलिंग से डेटा प्राप्त करने वाली किसी बाहरी प्रणाली का उपयोग करें।

स्टोरेज, अवधारण और माइग्रेशन

रिकॉर्ड साझा स्टेट डेटाबेस (state/openclaw.sqlite) में रहते हैं और डिलीवरी हॉट पाथ के बाहर लिखे जाते हैं। क्वेरी कभी भी 30 दिनों से पुराने रिकॉर्ड नहीं लौटातीं और लेजर की सीमा 100,000 पंक्तियाँ है; समय-सीमा समाप्त पंक्तियों को स्टार्टअप, प्रति घंटे रखरखाव और बाद के लेखनों के दौरान हटाया जाता है। संग्रह अक्षम होने पर भी अवधारण रखरखाव चलता रहता है।

पहले की केवल रन/टूल वाली लेजर के Gateway से अपग्रेड करने पर स्कीमा स्टार्टअप के समय (या openclaw doctor --fix के माध्यम से) अपने आप माइग्रेट हो जाता है; मौजूदा पंक्तियाँ और उनके लेजर अनुक्रम सुरक्षित रहते हैं।

क्वेरी करना

• CLI: एजेंट, सेशन, रन, प्रकार, स्थिति, दिशा, चैनल, समय सीमाओं और कर्सर पेजिंग के फ़िल्टर के साथ openclaw audit।
• Gateway RPC: audit.activity.list (इसके लिए operator.read आवश्यक है) संस्करणित V1 गतिविधि इवेंट यूनियन लौटाता है; पुराने रन/टूल क्लाइंट के लिए जारी किया गया audit.list RPC अपरिवर्तित है। Gateway प्रोटोकॉल देखें।

संबंधित

• ऑडिट रिकॉर्ड CLI
• कॉन्फ़िगरेशन संदर्भ
• Gateway प्रोटोकॉल
• OpenTelemetry