साझा जवाबदेही के बिना AI एजेंट के लिए सर्विस अकाउंट

AI एजेंट को सर्विस अकाउंट की ज़रूरत होती है, लेकिन सर्विस अकाउंट को कभी भी उस नाम का विकल्प नहीं बनना चाहिए जिसका इस्तेमाल आप तब करते हैं जब आपको पता ही न हो कि किसी कार्रवाई को मंज़ूरी किसने दी। हर लंबे समय चलने वाले वर्कफ़्लो को अपनी पहचान दें, उस पहचान के पीछे किसी व्यक्ति को स्पष्ट मालिक बनाएँ और वर्कफ़्लो बंद होते ही उसे हटा दें। इससे कमज़ोर व्यवस्था साझा जवाबदेही पैदा करती है, जिसका सीधा अर्थ है कि गलत कार्रवाई के बाद कोई भी पूरी कहानी नहीं बता सकता।

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

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

सर्विस अकाउंट अधिकार की पहचान बताता है, कार्रवाई करने वाले की नहीं

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

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

परतों को अलग रखें:

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

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

RFC 6749 OAuth 2.0 client credentials grant के वर्णन में एक उपयोगी, लेकिन सीमित बात कहता है: क्लाइंट अपने behalf पर काम करते समय अपने क्रेडेंशियल को authorization grant की तरह इस्तेमाल कर सकता है। सीमित मशीन वर्कलोड के लिए यह सही है। इसका अर्थ यह नहीं है कि क्रेडेंशियल पेश कर सकने वाली हर प्रक्रिया का उद्देश्य वैध है। grant को पूरी जवाबदेही मानना ही वह गलती है जिससे टीमें नुकसान उठाती हैं।

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

एक वर्कफ़्लो के लिए एक सीमित पहचान रखें

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

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

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

एक उपयोगी नामकरण पद्धति है:

<environment>.<product-or-repository>.<workflow-purpose>

prod.payments.release-publisher
dev.docs.dependency-updater
prod.data.backfill-reader

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

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

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

मालिक ऐसा व्यक्ति होना चाहिए जो काम रोक सके

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

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

NIST SP 800-53 Revision 5 का account management नियंत्रण AC-2 संगठनों से अकाउंट के प्रकार परिभाषित करने, समूह और भूमिका सदस्यता की शर्तें तय करने तथा उपयोगकर्ता से संबद्ध न रहने या आवश्यक न रहने पर अकाउंट बंद करने को कहता है। यह नियंत्रण गैर-मानवीय अकाउंट पर भी साफ़ तौर पर लागू होता है, भले ही लोग इसे केवल कर्मचारी अकाउंट के लिए पढ़ते हों। जवाबदेह संरक्षक के बिना मशीन पहचान के पास इन शर्तों को तय करने या अकाउंट की आवश्यकता समाप्त होने का निर्णय लेने वाला कोई नहीं होता।

अकाउंट रिकॉर्ड ऐसी रजिस्ट्री में रखें जिसका इस्तेमाल एक्सेस समीक्षा प्रक्रिया करती हो। उसे ऐसी विकी में न दबाएँ जो वास्तविक बाइंडिंग से अलग होती जाए। गंभीर समीक्षा के लिए यह न्यूनतम रिकॉर्ड पर्याप्त है:

identity: prod.payments.release-publisher
owner: "Morgan Lee"
technical_contact: "Release engineering on-call"
purpose: "Publish approved signed payment service artifacts to production"
allowed_actions:
  - "upload signed artifact to production release repository"
  - "read release metadata for the payment service"
environments:
  - production
permission_bindings:
  - "artifact-repository/publish-payments-prod"
credential_method: "short lived workload token"
source_repository: "payments-service"
review_after: "2026-06-30"
retire_when: "The payment service stops using this release workflow"
incident_contact: "Release engineering on-call"

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

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

साझा अकाउंट छोटी घटना को अनुमान लगाने की कवायद बना देते हैं

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

16:20 पर किसी को पता चलता है कि वातावरण चर गलत मान में बदल गया है। API लॉग कहता है कि अनुरोध prod.agent-ops ने किया। रिलीज़ टीम कहती है कि उसका रन पहले ही पूरा हो चुका था। घटना टीम कहती है कि उसका एजेंट केवल स्थिति पढ़ रहा था और सेटिंग नहीं लिखता। इंफ्रास्ट्रक्चर मालिक कहता है कि उस दोपहर सुधार प्रॉम्प्ट का परीक्षण किया गया था, लेकिन किसी ने पूरा सत्र सुरक्षित नहीं रखा। तीनों बातें सही हो सकती हैं और अकाउंट लॉग इस विवाद को सुलझा नहीं सकता।

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

अलग पहचान से क्रम बदल जाता है। यदि prod.payments.release-publisher अप्रत्याशित कॉल करे, तो वही पहचान बंद करें। घटना-सारांश और सुधार अकाउंट अपने-अपने अधिकार बनाए रखते हैं। कार्रवाई रिकॉर्ड में वर्कफ़्लो पहचान और रन संदर्भ होना चाहिए, ताकि जाँचकर्ता याददाश्त के आधार पर बहस किए बिना सटीक सत्र ढूँढ सकें। इसी कारण «हर टीम के लिए एक अकाउंट» समझौता नहीं है। यह विफलता के क्षेत्रों को जानबूझकर मिला देना है।

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

साझा अकाउंट और साझा अनुमति भूमिका को एक न समझें। कई पहचान एक ही सीमित भूमिका पा सकती हैं, यदि वे वही अनुमत ऑपरेशन करती हैं। पहचान अलग रहती हैं, इसलिए लॉग और अनुमति रद्द करना काम करते हैं। भूमिका साझा करने से प्रबंधन आसान होता है; पहचान साझा करने से attribution नष्ट होता है।

अनुमति का दायरा एजेंट की महत्वाकांक्षा नहीं, कार्रवाइयों के अनुसार तय करें

जिस कार्रवाई-पथ को अनुमति देनी है, उसी के लिए एक्सेस दें और एजेंट से किसी अतिरिक्त अधिकार की आवश्यकता साबित करवाएँ। एजेंट की सामान्य क्षमता सामान्य अधिकार का आधार नहीं है।

वर्कफ़्लो के क्रियापद और वस्तुओं से शुरुआत करें। «रिपॉज़िटरी A में खुले मुद्दे पढ़ना और उसी में शाखा बनाना» कार्रवाई का विवरण है। «रिपॉज़िटरी A को संभालना» नहीं है। पहले वाक्य से प्रशासक पढ़ने और शाखा बनाने का सटीक दायरा ढूँढ सकता है। दूसरा वाक्य आम तौर पर व्यापक write access पर खत्म होता है, क्योंकि कोई उसे स्पष्ट अनुमति में नहीं बदल पाता।

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

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

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

परीक्षण परिणाम को स्वामित्व रिकॉर्ड के साथ रखें। एक छोटी तालिका पर्याप्त है:

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

क्रेडेंशियल भूले हुए वर्कफ़्लो से पहले समाप्त होने चाहिए

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

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

बेहतर क्रम सरल है:

1. कॉल करने वाले रनटाइम या एजेंट सत्र की पुष्टि करें।
2. कम अवधि और सीमित दायरे वाला क्रेडेंशियल जारी करें, या उसकी ओर से अनुरोधित कार्रवाई करें।
3. अनुरोधित कार्रवाई और अनुमति निर्णय दर्ज करें।
4. सत्र समाप्त करें और केवल उसी सत्र से जुड़े अधिकार को अमान्य करें।

सिर्फ इसलिए एजेंट को plain text secret न दें कि उसे API कॉल करनी है। इससे हर प्रॉम्प्ट, टूल आउटपुट, ट्रेस और गलती से बने लॉग में क्रेडेंशियल फैलने का रास्ता खुल जाता है। कंसोल आउटपुट में secret मान छिपाना उसके सामने आने के बाद मदद करता है, लेकिन एजेंट को उसे पाने और दोबारा इस्तेमाल करने से नहीं रोकता।

Sallyport अपने समर्थित HTTP और SSH चैनलों के लिए दूसरा तरीका अपनाता है: एजेंट अपने MCP कनेक्शन से कार्रवाई का अनुरोध करता है, जबकि ऐप API और SSH क्रेडेंशियल को एन्क्रिप्टेड वॉल्ट में रखकर खुद कार्रवाई करता है। इससे क्रेडेंशियल एजेंट संदर्भ से बाहर रह सकते हैं, लेकिन अलग वर्कफ़्लो पहचान और मालिक बनाने की आवश्यकता समाप्त नहीं होती।

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

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

ऑडिट रिकॉर्ड को अधिकार को किसी खास रन से जोड़ना चाहिए

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

एक समान event shape इस्तेमाल करें। यह JSON किसी प्रदाता पर निर्भर नहीं है, लेकिन इसमें वे फ़ील्ड हैं जिनकी कमी घटना के बाद अक्सर महसूस होती है:

{
  "event_id": "act_01J8Q7M6K4",
  "time": "2026-04-14T16:20:31Z",
  "workflow_identity": "prod.payments.release-publisher",
  "run_id": "run_8f3c1d",
  "trigger": {
    "type": "approved_ci_job",
    "initiator": "morgan.lee",
    "source_revision": "a1b2c3d4"
  },
  "authorization": {
    "decision": "approved",
    "approved_by": "morgan.lee",
    "approval_ref": "apr_31fa"
  },
  "action": {
    "target": "production artifact repository",
    "operation": "publish",
    "resource": "payments-service/2.4.1"
  },
  "result": "success"
}

फॉरेंसिक विवरण के नाम पर ऑडिट रिकॉर्ड में क्रेडेंशियल, संवेदनशील सामग्री वाले पूरे प्रॉम्प्ट या बिना सीमा के payload न रखें। कारण-श्रृंखला स्थापित करने के लिए पर्याप्त स्थिर संदर्भ दर्ज करें और वही डेटा-प्रबंधन नियम लागू करें जो किसी संचालन लॉग पर लागू होते हैं। दूसरा secret store बन जाने वाला ऑडिट सिस्टम खुद घटना का रास्ता बन जाता है।

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

Sallyport के Sessions और Activity journals write-blind, एन्क्रिप्टेड और hash-chained ऑडिट लॉग से तैयार होते हैं। उसका sp audit verify कमांड वॉल्ट क्रेडेंशियल के बिना ऑफलाइन उस चेन की जाँच करता है। यह उसके माध्यम से की गई कार्रवाइयों के लिए उपयोगी सबूत है, लेकिन आसपास के सिस्टम को वर्कफ़्लो मालिक, ट्रिगर और कारोबारी मंज़ूरी का संदर्भ फिर भी सुरक्षित रखना होगा।

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

अकाउंट बंद करना वर्कफ़्लो है, सालाना सफाई नहीं

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

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

पहचान बंद करते समय यह क्रम अपनाएँ:

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

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

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

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

जवाबदेही तभी बचती है जब समीक्षा एक्सेस रद्द कर सके

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

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

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

पहला व्यावहारिक कदम है कि मौजूदा एजेंट पहचान निर्यात करें और हर एक के सामने एक वाक्य लिखें: «यह वर्कफ़्लो Y के लिए X कर सकता है, इसका मालिक Z है और यह W शर्त तक चलेगा।» जो अकाउंट इस वाक्य का विरोध करें, वे छिपी साझा जवाबदेही ढो रहे हैं। अधिक एजेंट क्षमता जोड़ने से पहले उन्हें बंद या अलग करें।