ऑडिट इतिहास

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