AI एजेंट के लिए ऐसे Write-Blind ऑडिट लॉग बनाएं जिन्हें एजेंट बदल न सके

AI एजेंट गलत फैसला लेने के बाद अपने काम की एक सलीकेदार व्याख्या लिख सकता है। वह व्याख्या सबूत नहीं है। अगर एजेंट उन रिकॉर्ड को देख, चुन, बदल या टाल सकता है जिनके आधार पर समीक्षक उसका मूल्यांकन करते हैं, तो ऑडिट ट्रेल भी ऐसा output surface बन जाता है जिसे एजेंट अपने पक्ष में ढाल सकता है।

Write-blind ऑडिट लॉग एक सीमित लेकिन महत्वपूर्ण समस्या हल करते हैं: जो प्रोसेस बाहरी कार्रवाई का अनुरोध करती है, उसे उस कार्रवाई का रिकॉर्ड नियंत्रित नहीं करना चाहिए। Action system अपने निरीक्षण के आधार पर रिकॉर्ड बनाता है, एजेंट को ज़रूरी action result लौटाता है और review record को एजेंट की पहुंच से बाहर रखता है। इससे एजेंट ईमानदार नहीं बनता। लेकिन बेईमान, भ्रमित या compromised एजेंट के लिए बाद में कहानी को अपनी सुविधा से सजाना कठिन हो जाता है।

यह अंतर तब सबसे महत्वपूर्ण होता है जब एजेंट code deploy कर सकता हो, paid APIs कॉल कर सकता हो, cloud settings बदल सकता हो, mail भेज सकता हो या SSH commands चला सकता हो। ऐसे मामलों में chat transcript कमजोर सबूत है। Transcript दावों और चुने हुए tool output को दर्ज करता है। Enforcement point पर बनाया गया रिकॉर्ड अनुरोध, authorization, execution और result को तब भी दर्ज कर सकता है जब एजेंट चुप रहना चाहे।

एजेंट को कार्रवाई और सबूत दोनों नियंत्रित नहीं करने चाहिए

किसी काम पर एजेंट के पास जितनी शक्तियां हों, सबूतों पर उससे कम शक्तियां होनी चाहिए। उसे audit.jsonl नाम की फ़ाइल देकर records append करने को कहना activity diary बनाता है, audit log नहीं। वह कोई line भूल सकता है, असुविधाजनक argument छिपा सकता है, call fail होने से पहले success लिख सकता है या दूसरी copy बना सकता है जिसे समीक्षक कभी देखे ही नहीं।

यह समस्या उन एजेंटों के साथ भी आती है जो निर्देशों का पालन करते हैं। एजेंट अक्सर तय करता है कि कौन से tools चलाने हैं, कौन सा exception पकड़ना है और कौन सा context रखना है। Prompt injection उसे किसी request की logging से बचने को कह सकता है। Bug किसी request को ऐसे uninstrumented library से भेज सकता है। Malicious dependency सीधे network पर लिख सकती है। अगर वही process action और record दोनों की मालिक है, तो इनमें से हर failure एक साफ़-सुथरी लेकिन अधूरी trail छोड़ सकता है।

इन क्षमताओं को साफ़ तौर पर अलग करें:

• एजेंट action का अनुरोध करता है और सीमित परिणाम प्राप्त करता है।
• Executor credential अपने पास रखता है, request भेजता है और event record बनाता है।
• Journal ऐसे रास्ते से records स्वीकार करता है जिसे एजेंट पढ़ या बदल नहीं सकता।
• Reviewer अलग interface से records पढ़ता और सत्यापित करता है।

यह capability boundary है, व्यवहार के बारे में कोई वादा नहीं। एजेंट के पास journal की file access, अपनी entries के लिए query API, journal को बदल सकने वाले credentials या event timestamp सेट करने का तरीका नहीं होना चाहिए। अगर उसे अपनी reasoning समझानी हो, तो वह explanation अलग run artifact में रखें और उसे agent-supplied material के रूप में चिह्नित करें। उसे execution record में न मिलाएं।

टीमें अक्सर intent और evidence को मिला देती हैं। Intent वह है जो एजेंट कहता है कि वह करना चाहता था: «staging service को restart करना»। Evidence वह है जो execution component ने देखा: एजेंट ने किसी समय एक खास command का अनुरोध किया, approval decision हुआ, executor एक named host reference से जुड़ा और command एक खास status के साथ समाप्त हुई। दोनों उपयोगी हैं। वे अलग सवालों का जवाब देते हैं और उन पर भरोसे का स्तर भी अलग होना चाहिए।

Write-blind का अर्थ क्षमताओं को अलग करना है, देर से देखने की सुविधा नहीं

Write blindness का अर्थ है कि actor कोई record बनवा सकता है, लेकिन उसे संग्रहित record या उसके भविष्य के review context तक पहुंच नहीं मिलती। इसका अर्थ यह नहीं कि एजेंट को कोई feedback नहीं मिलेगा। SSH task के लिए उसे stdout, stderr और exit status चाहिए। HTTP task के लिए response status और body, या उसका सीमित हिस्सा, चाहिए। Results हटाने से सबूत मजबूत नहीं होते, एजेंट बेकार हो जाता है।

इस boundary के चार व्यावहारिक हिस्से हैं। पहला, एजेंट credential के बजाय request interface इस्तेमाल करता है। दूसरा, executor एजेंट के दिए JSON blob पर भरोसा करने के बजाय अपने observations से record बनाता है। तीसरा, एजेंट records को list, fetch, modify या delete नहीं कर सकता। चौथा, reviewer बाद में agent की memory या chat history पर निर्भर हुए बिना record देख सकता है।

Delayed-read design इस मानक पर खरा नहीं उतरता। मान लें एजेंट database में events लिखता है और उसे session खत्म होने तक table query न कर पाने का वादा मिलता है। वह फिर भी schema जानता है। वह argument strings को अपने हिसाब से ढाल सकता है, omissions चुन सकता है, transaction failures आज़मा सकता है और error timing के अंतर से पता लगा सकता है कि record दर्ज हुआ या नहीं। उसके पास database credentials भी हो सकते हैं जिनका किसी दूसरे code path से गलत इस्तेमाल हो जाए।

Write blindness तब मजबूत होती है जब event path journal की स्थिति बताने वाला कोई response न दे। Executor requested action को acknowledge कर सकता है, लेकिन उसे event IDs, sequence numbers, reviewer annotations, risk labels या यह confirmation नहीं लौटानी चाहिए कि कोई खास record permanent हो गया। ये विवरण actor को अपने व्यवहार को optimize करने का आधार देते हैं।

इसके लिए हर एजेंट को hostile मानना ज़रूरी नहीं। एजेंट कई सामान्य कारणों से unsafe हो सकता है: injected instruction, runaway loop, tool bug, पुरानी dependency या ऐसा operator जिसने बहुत व्यापक task दे दिया हो। Design को केवल अच्छे इरादों पर निर्भर नहीं होना चाहिए।

केवल append-only log समस्या हल नहीं करता

Append-only storage कुछ तरह की छेड़छाड़ का पता लगा सकता है। यह साबित नहीं करता कि recorder ने हर relevant action देखा था, और न ही एजेंट को storage से पहले भ्रामक records व्यवस्थित करने से रोकता है। टीमें अक्सर immutable storage खरीद लेती हैं और फिर agent environment में direct network credentials छोड़ देती हैं। इससे मुख्य कमी बनी रहती है।

दो deployment paths पर विचार करें। पहले में एजेंट environment variable से API token पढ़कर deployment service को सीधे call करता है। एक अलग library request log करने की कोशिश करती है। एजेंट library को bypass कर सकता है, दूसरा process शुरू कर सकता है या अलग HTTP client इस्तेमाल कर सकता है। Log पूरी तरह append-only रह सकता है, फिर भी deployment उसमें कभी दिखाई नहीं देगा।

दूसरे में एजेंट executor से deploy करने को कह सकता है, लेकिन उसे token नहीं मिलता। Credential जोड़ने का एकमात्र रास्ता executor के पास है। वह transmission से पहले request record करता है और response के बाद event update करता है। Journal केवल उन्हीं actions का वर्णन कर सकता है जो executor से होकर गुज़रे, लेकिन एजेंट के पास उसके आसपास जाने का authorized route नहीं है।

RFC 6962, Certificate Transparency specification, Merkle hash tree का वर्णन करता है। इससे leaf के tree में होने और नए tree के पुराने tree से आगे बढ़ने के efficient proofs मिलते हैं। यह उपयोगी integrity pattern है। लेकिन यह दावा नहीं करता कि tree ने वास्तविक दुनिया के सभी events capture किए हैं। जो deployment request tree में आई ही नहीं, वह inclusion proof में दिखाई नहीं दे सकती।

यही सीमा linear hash chain पर भी लागू होती है। कोई record अपने predecessor का digest शामिल कर सकता है। अगर कोई stored records को बदलता, हटाता या क्रम बदलता है, तो प्रभावित बिंदु पर verification fail होगी। फिर भी साफ़ chain केवल carefully selected actions के subset को cover कर सकती है। Chain की खुशी मनाने से पहले recorder को action path में रखें।

दूसरी सीमा administrators से जुड़ी है। अगर operator log database बदल सकता है और किसी external witness के बिना chain root reset कर सकता है, तो design मुख्यतः casual changes से बचाता है। Offline verification, protected checkpoints और access separation reviewers को भरोसे का बेहतर आधार देते हैं। इनमें से कोई भी उपाय log को machine पर हुई हर घटना का पूरा विवरण नहीं बनाता।

Recorder को execution path पर रखें

Recorder को उस जगह action देखना चाहिए जहां credentials जुड़ते हैं और external request controlled system से बाहर जाती है। Agent framework layer पर logging बहुत जल्दी हो जाती है। केवल remote service पर logging अक्सर बहुत देर से होती है और authorization context छूट सकता है। Execution gateway accepted request और मिले हुए outcome दोनों देख सकता है।

HTTP के लिए gateway को constrained request स्वीकार करनी चाहिए, stored credential चुनना चाहिए, credential खुद जोड़ना चाहिए, request भेजनी चाहिए और response का अनुमत हिस्सा लौटाना चाहिए। एजेंट को raw Authorization headers submit नहीं करने चाहिए। उसे internal name से credential refer करना चाहिए, जिसे gateway resolve करे।

Request का आकार इतना छोटा हो सकता है कि उसे inspect और record करना आसान रहे:

{
  "action": "http.request",
  "credential_ref": "deploy-api",
  "method": "POST",
  "url": "https://deploy.example.internal/releases",
  "headers": {"content-type": "application/json"},
  "body": {"revision": "a18f3c"}
}

Executor को इस route पर caller-supplied credential headers अस्वीकार करने चाहिए। इससे एजेंट कोई दूसरा token छिपाकर request में नहीं डाल सकता और journal में भ्रामक credential_ref नहीं छोड़ सकता। URL record करने से पहले उसे normalize भी करें, क्योंकि raw URL में userinfo, encoded path tricks या query parameter में गलती से आया secret हो सकता है।

SSH पर भी यही नियम लागू होता है। एजेंट host reference पर command चलाने को कहता है। Executor configured identity, host verification behavior और connection method चुनता है। अगर एजेंट private key पढ़कर अपना SSH client चला सकता है, तो audit system अपने remote actions को cover करने का दावा नहीं कर सकता।

Gateway को general-purpose proxy न समझें। Proxy व्यापक traffic को observe करने की कोशिश करता है। Action gateway actions का तय set देता है और उन्हें करने का अधिकार अपने पास रखता है। इस सीमित रूप से record का अर्थ स्पष्ट करना आसान होता है: इस executor ने इस authorization के तहत यह action स्वीकार किया और यह result प्राप्त किया।

बाहरी सिस्टम के जवाब देने से पहले event record करें

विश्वसनीय record में executor द्वारा action भेजने से पहले start event और outcome मिलने के बाद completion event होना चाहिए। अगर success के बाद ही record लिखा जाता है, तो timeout, crash, process kill या network break गंभीर request को history से गायब कर सकता है।

एक action identifier executor बनाए, एजेंट नहीं। Start record में session identifier, actor process identity, action type, normalized target, safe request digest, authorization decision और recorder द्वारा बनाया गया timestamp होना चाहिए। उसकी state started रखें।

Executor को response या failure मिलने के बाद उसी action identifier से जुड़ा completion record लिखना चाहिए। इसमें succeeded, rejected, timed_out, transport_error या executor_error जैसी result category, response digest और सीमित metadata शामिल होनी चाहिए। इससे reviewer «gateway ने इसे reject किया» और «remote system को request मिल सकती है, लेकिन response नहीं लौटा» के बीच अंतर कर सकता है।

इस अंतर के operational परिणाम होते हैं। मान लें एजेंट POST /releases भेजता है और remote service के request स्वीकार करने के बाद connection खो देता है। Blind retry से दो releases बन सकती हैं। Client को response न मिलने के कारण पहली कोशिश को failure कहना गलत है। Journal को दिखाना चाहिए कि executor ने call करने की कोशिश की, transmission शुरू होने के बाद transport fail हुआ और किसी दूसरे source से पुष्टि होने तक final remote state अज्ञात है।

Records की एक छोटी जोड़ी ऐसी दिख सकती है:

{"seq":481,"action_id":"01HV...","state":"started","session":"run-72","type":"http.request","target":"deploy.example.internal/releases","request_sha256":"...","authorized":true,"previous_sha256":"..."}
{"seq":482,"action_id":"01HV...","state":"completed","result":"transport_error","sent":true,"response_sha256":null,"previous_sha256":"..."}

ऊपर के fields structure का उदाहरण हैं, universal schema नहीं। Sequence value और digest recorder के नियंत्रण में रखें। एजेंट task label दे सकता है, लेकिन उसे untrusted input मानें और उसकी length सीमित करें। वरना एजेंट किसी official दिखने वाले field में secrets, reviewers के लिए instructions या भ्रामक prose डाल सकता है।

दोनों records के बीच crash होने पर unfinished action बचा रहेगा। उसे सुरक्षित रखें। Unfinished record जांच का सबूत है, recovery के दौरान साफ़ करने वाला clutter नहीं। Restart पर system उसे unresolved चिह्नित कर सकता है, अगर ऐसा करने का reliable तरीका हो, लेकिन history को साफ़-सुथरी success या failure में दोबारा नहीं लिखना चाहिए।

Schema में intent और result दोनों सुरक्षित रहने चाहिए

जो journal केवल «command executed» रखता है, incident के समय लगभग कोई जवाब नहीं देता। जो हर request और response का हर byte रखता है, वह sensitive data dump बन जाता है। उपयोगी middle ground इतना structured context रखता है कि action की पहचान और authorization का मूल्यांकन हो सके, साथ ही secrets और uncontrolled payloads कम से कम रहें।

Calling process की identity ऐसे terms में record करें जिन्हें operating system establish कर सके। macOS पर code-signing authority self-reported agent name से बेहतर session anchor देती है। Process IDs दोबारा इस्तेमाल हो सकते हैं। Display name झूठ बोल सकता है। इतना session context रखें कि reviewer समझ सके कि नया process run शुरू कर रहा था या नहीं और approval उसी process पर लागू थी या नहीं।

HTTP action के लिए method, normalized authority और path, selected credential reference, allowed request headers, request body digest, decision outcome और उपलब्ध होने पर response status रखें। SSH action के लिए host reference, लागू होने पर remote account reference, sensitivity के अनुसार command या command digest, selected identity reference, host verification result, exit status और output digest रखें।

Raw credentials store न करें। Bearer token को URL, custom header, command arguments या captured output में जाने न दें। Storage के बाद redaction करना collection रोकने से कमजोर है, क्योंकि secret backups, replicas या reviewer exports में पहले ही पहुंच चुका होता है।

Digests पर सावधानी चाहिए। Digest केवल उस material के साथ equality साबित करता है जो reviewer के पास पहले से हो। यह इंसान को नहीं बताता कि क्या हुआ। Deployment payload के लिए stored digest और repository revision अच्छा संयोजन हो सकता है। Destructive database command के लिए normalized command representation ज़रूरी हो सकती है, क्योंकि reviewers को exact instruction ही evidence चाहिए।

जिस policy या approval decision ने action की अनुमति दी, उसके लिए अलग field रखें। बाद का reviewer यह जान सके: क्या executor ने action इसलिए allow किया कि session approved था, operator ने इस individual use को approve किया था या vault खुला था? अगर human control model इस अंतर पर निर्भर है, तो इन्हें अस्पष्ट allowed: true में न मिलाएं।

Review के लिए अलग access और स्वतंत्र verification चाहिए

Reviewers को searchable table से अधिक चाहिए। उन्हें यह तय करना होता है कि record sequence internally consistent है या नहीं और system ने अपनी boundaries सुरक्षित रखी हैं या नहीं। Run की जांच करने वाले व्यक्ति को पहले एजेंट से उसके व्यवहार का summary मांगने की ज़रूरत नहीं होनी चाहिए।

Hash chaining एक ठोस check देती है। हर record में पिछले stored record का digest होता है और recorder current canonical record का digest निकालता है। Verifier sequence को क्रम से पढ़ता है, हर digest फिर से निकालता है और देखता है कि predecessor reference मेल खाता है या नहीं। पुराने target को बदलने, शर्मनाक failure हटाने या दो records की जगह बदलने पर बाद की chain टूट जाती है।

Canonicalization महत्वपूर्ण है। अगर एक component JSON text hash करे और दूसरा उसे parse करके फिर serialize करे, तो harmless whitespace या field ordering verification failure पैदा कर सकती है। Exact field ordering, character encoding, null handling, timestamp precision और digest algorithm तय करें। फिर record format को version करें। Verifier को अनुमान लगाने के बजाय पता होना चाहिए कि वह किसी version को validate कर सकता है या नहीं।

Verification उस process से अलग होकर काम करनी चाहिए जिसने records बनाए हैं। अगर integrity check करने के लिए वही running service चाहिए, तो compromised service टूटी chain के बारे में झूठ बोल सकती है। Encrypted record stream को reviewer machine या protected archive में copy करें और उस copy पर verifier चलाएं।

Sallyport अपने Sessions और Activity journals को एक encrypted, hash-chained audit log से project करता है। sp audit verify vault key के बिना ciphertext पर offline chain verify कर सकता है। यह सही दिशा है: evidence check के लिए action सक्षम करने वाले secrets को उजागर करना आवश्यक नहीं होना चाहिए।

Integrity verification एक सीमित सवाल का जवाब देती है: क्या ये records वही sequence बनाते हैं जिसकी verifier को उम्मीद है? इससे यह साबित नहीं होता कि हर server response truthful था, target system के पास कोई दूसरा access path नहीं था या administrator ने पूरे journal को किसी पुराने valid copy से replace नहीं किया। अगर आपके environment में rollback महत्वपूर्ण है, तो protected checkpoints रखें या signed roots किसी independent retention system को भेजें।

वे failure patterns जो चुपचाप trail खराब कर देते हैं

सबसे नुकसानदेह designs demo में अक्सर ठीक दिखते हैं। Retry, outage या agent द्वारा उसी authority के unexpected इस्तेमाल पर वे टूटते हैं।

पहली failure agent SDK से logging है। यह लोकप्रिय है क्योंकि कुछ lines में familiar trace view मिल जाती है। जब एजेंट credentials प्राप्त करता है, कोई दूसरा program चलाता है या SDK से न ढके destination को call करता है, तब यह execution record नहीं दे सकती। SDK traces को debugging data मानें।

दूसरी failure single success record है। केवल साफ़ response के बाद लिखा गया record ambiguity मिटा देता है। Network operations के परिणाम अस्पष्ट हो सकते हैं और connection बंद होने से पहले remote commands state बदल सकती हैं। Start और completion अलग-अलग record करें और unfinished starts सुरक्षित रखें।

तीसरी failure audit payload में secrets रखना है। टीमें कभी-कभी कहती हैं कि reviewers को पूरी reproduction के लिए secrets चाहिए। किसी action को समझने के लिए reviewers को bearer token शायद ही कभी चाहिए होता है, और copied secrets journal को high-value target बना देते हैं। Credential references और request digests रखें।

चौथी failure mutable search index को source of truth मानना है। Search indexes fields छोड़ सकते हैं, documents expire कर सकते हैं और repairs की अनुमति दे सकते हैं। Durable event stream को authoritative record रखें। उससे search view बनाएं और view संदिग्ध लगे तो reviewer को original record तक लौटने दें।

पांचवीं failure broad escape hatch है। «production environment के साथ arbitrary shell चलाओ» जैसी command सावधानी से की गई credential handling और event modeling को बेकार कर देती है। कभी-कभी operator को exceptional access चाहिए। उस access को explicit record वाली अलग approved action बनाएं, normal agent route के भीतर छिपाएं नहीं।

Human approval और write blindness अलग जोखिमों को संभालते हैं

Approval unsafe action को होने से पहले रोक सकती है। Write blindness action request होने के बाद evidence सुरक्षित रखती है। जब एजेंट consequential credentials के साथ काम करे, तो teams को दोनों चाहिए।

Session approval तब उचित है जब कोई human किसी specific agent process पर bounded period of work के लिए भरोसा करता हो। Per-action approval उस credential या operation के लिए उचित है जिसे हर बार human attention चाहिए। इनमें से कोई भी approval type execution record का विकल्प नहीं है। Approved session फिर भी accidental call कर सकता है और एजेंट फिर भी अपने किए काम का गलत वर्णन कर सकता है।

Approval screen में calling process की पहचान ऐसे रूप में होनी चाहिए जिसका human आकलन कर सके। «release assistant» जैसा self-declared label कमजोर है। Established code-signing authority operator को इस बारे में मजबूत संकेत देती है कि power मांगने वाला program कौन सा है। Approval decision event context का हिस्सा बनना चाहिए, लेकिन identity का वर्णन कैसे किया जाए, यह एजेंट के नियंत्रण में नहीं होना चाहिए।

Vault gate को approval से अलग रखें। Locked vault को action deny करना चाहिए, भले ही पहले session approval मौजूद हो। इससे सरल emergency stop मिलता है: authority lock करें और executor stored credentials का इस्तेमाल बंद कर देता है। Journal denials भी record करे। Denied requests की श्रृंखला दिखा सकती है कि एजेंट loop कर रहा है, probing कर रहा है या operator द्वारा access revoke करने के बाद भी जारी है।

जब तक सचमुच ज़रूरत न हो, इसे giant rule language में न बदलें। Incident के दौरान जिन rules को कोई inspect न कर सके, वे झूठा भरोसा देते हैं। Clear controls का छोटा set, constrained action interface और ऐसे records जिन्हें एजेंट curate नहीं कर सकता, conditional exceptions के ढेर से अक्सर बेहतर होते हैं।

Boundary उस action के आसपास बनाएं जो आपको नुकसान पहुंचा सकती है

उस external action से शुरू करें जिसके गलत इस्तेमाल पर सबसे कठिन investigation करनी पड़ेगी। वह production SSH command, release API call, account change या paid request हो सकती है। Credential को agent environment से हटाएं, उस action को executor से होकर जाने पर मजबूर करें और अधिक tools जोड़ने से पहले failure paths की जांच करें।

Design पर यह छोटा test चलाएं:

1. Action request करें, फिर request के बीच में agent process बंद कर दें। Confirm करें कि journal में started event बचा है।
2. Remote destination से error लौटवाएं और confirm करें कि completion record rejection, remote failure और transport failure में अंतर करता है।
3. Caller-supplied credential header या private key के साथ वही action आज़माएं। Confirm करें कि executor उसे reject करता है।
4. Agent को उसके सामान्य interfaces दें और audit records को list, alter या delete करने की कोशिश करें। Confirm करें कि उसके पास ऐसा करने का कोई रास्ता नहीं है।
5. Stored journal को किसी दूसरी जगह copy करें और executor की live status पर निर्भर हुए बिना उसकी chain verify करें।

ये tests उन design gaps को खोज लेते हैं जिन्हें happy-path demo छिपा देता है। वे एक असहज सवाल का सटीक जवाब देने को भी मजबूर करते हैं: agent recorded gateway के बाहर अब भी कौन सी actions कर सकता है? अगर जवाब में production authority शामिल है, तो record design से ही incomplete है। इसे साफ़ तौर पर बताएं, route बंद करें या audit trail के बारे में अपने दावों को सीमित करें।

एक उपयोगी audit record request के बाहर जाने से पहले शुरू होता है, best observed outcome पर समाप्त होता है और agent के नियंत्रण से बाहर रहता है। पहला incident आपसे एजेंट की version of events पर भरोसा करने को कहे, उससे पहले यह boundary बना लें।