पंजीकृत पहचान
हर एजेंट एक रिकॉर्ड होता है: स्थिर agent_id, भूमिका, Ed25519 कुंजी बाइंडिंग, निर्माण तिथि। अब अनुमान लगाना बंद करें कि किस प्रक्रिया ने क्या किया — रजिस्ट्री यह स्रोत है कि कौन मौजूद है।
एंटरप्राइज · एजेंट गवर्नेंस
आपके एजेंट्स के नाम और मालिक होते हैं
और एक ऑफ स्विच।
2027 तक, फ़्लीट्स — और गुमनाम प्रक्रियाओं का एक फ़्लीट एक देनदारी है। LeanCTX हर एजेंट को एक पंजीकृत पहचान बनाता है: अद्वितीय, किसी इंसान के स्वामित्व वाला, जीवनचक्र-प्रबंधित, प्रमाणित और वापस लेने योग्य — हर बदलाव का ऑडिट ट्रेल छेड़छाड़-रोधी होता है।
मॉडल
पहचान जवाब देती है। भूमिका चलती है।
भूमिकाएँ पुन: प्रयोज्य अनुमति प्रोफ़ाइल बनी रहती हैं। पहचान इसके ऊपर जवाबदेही जोड़ती है: agent_id, owner, status, key binding, attestation, heartbeat। चार गुण एक फ़्लीट को प्रबंधनीय बनाते हैं।
मालिक, हमेशा
किसी मानव मालिक के बिना पंजीकरण को अस्वीकार कर दिया जाता है। जवाबदेही संरचनात्मक होती है: हर ऑडिट प्रविष्टि, हर जीवनचक्र घटना, हर साक्ष्य बंडल एक व्यक्ति से जुड़ा होता है जो एजेंट के लिए जवाबदेह होता है।
एक लेनदेन में वापस लेने योग्य
किसी एजेंट को निलंबित करें, या किसी मालिक को ऑफ़बोर्ड और उनके पूरे फ़्लीट को परमाणु रूप से निलंबित करें — प्रत्येक निलंबन का व्यक्तिगत ऑडिट किया जाता है। डीकमीशनिंग अंतिम होती है और ऑडिट-समापन प्रविष्टि लिखती है।
प्रमाणित, ईमानदारी से
पंजीकरण और हर हार्टबीट पर बाइनरी और भूमिका-कॉन्फ़िग हैश। विचलन तुरंत सामने आता है (एग्जिट कोड 3) — अपग्रेड, कॉन्फ़िगरेशन संपादन या छेड़छाड़। हम दस्तावेज़ करते हैं कि यह किस चीज़ की सुरक्षा नहीं करता है।
व्यवहार में
एक फ़्लीट, पाँच कमांड।
सब कुछ CLI-पहला और एग्जिट-कोड ईमानदार होता है, ताकि आपके पाइपलाइन और आपका मॉनिटरिंग इस पर कार्य कर सकें।
$ lean-ctx agent register --id ci-reviewer-1 --role reviewer --owner alice@org registered: ci-reviewer-1 (role reviewer, owner alice@org) spiffe id: spiffe://org.example/agent/reviewer/ci-reviewer-1 $ lean-ctx agent heartbeat ci-reviewer-1 # liveness + drift; exit 3 on drift $ lean-ctx agent offboard-owner alice@org --reason "left company" suspended 2 agent(s): ci-coder-1, ci-reviewer-1 $ lean-ctx agent check ci-reviewer-1 # enforce-path decision point ci-reviewer-1: DENIED — suspended: left company # exit 1
हर बदलाव एक छेड़छाड़-प्रूफ ऑडिट एंट्री लिखता है — पंजीकृत (registered), निलंबित (suspended), फिर से सक्रिय (resumed), या निष्क्रिय (decommissioned) मानकीकृत इवेंट प्रकार हैं (OCP Part 4), इसलिए पहचान इतिहास स्वचालित रूप से आपके सबूत बंडलों में आ जाता है। पूर्ण मॉडल और खतरा मॉडल: agent-identity docs।
"जब कोई चला जाता है तो क्या होता है?"
उनके एजेंट रुक जाते हैं। यांत्रिक रूप से। मालिक को बाहर निकालना (Owner offboarding) एक ही लॉक किए गए लेनदेन में उस मालिक के हर सक्रिय एजेंट को निलंबित कर देता है — जो आपके SCIM डीप्रोविजनिंग फ्लो से जुड़ा होता है या लीवर चेकलिस्ट से चलाया जा सकता है। अनाथ एजेंट (Orphaned agents) एजेंट युग के भूले हुए सेवा खाते होते हैं; LeanCTX उन्हें संरचनात्मक रूप से असंभव बनाता है।
FAQ
प्लेटफ़ॉर्म टीमें क्या पूछती हैं।
एजेंटों को पहचान की आवश्यकता क्यों होती है जब उनके पास पहले से ही भूमिकाएँ (roles) हैं?
एक भूमिका बताती है कि कोई प्रक्रिया क्या कर सकती है; एक पहचान बताती है कि इसके लिए कौन जवाबदेह है। फ़्लीट्स के साथ, मायने रखने वाले प्रश्न परिचालन संबंधी होते हैं: इस एजेंट का मालिक कौन है, यह आखिरी बार कब सक्रिय था, इसे किसने और क्यों बंद किया, जब इसका मालिक चला जाता है तो इसकी अनुमतियाँ क्या होती हैं? रजिस्ट्री उनका यांत्रिक रूप से उत्तर देती है — पहचान (कौन) भूमिका (क्या) से अलग रहती है, इसलिए भूमिकाएँ पुन: प्रयोज्य प्रोफाइल बनी रहती हैं।
अनाथ-एजेंट समस्या क्या है?
एक एजेंट जिसके मानव मालिक ने कंपनी छोड़ दी है लेकिन जो अपने क्रेडेंशियल्स के साथ चलता रहता है — यह एजेंट युग का भूले हुए सेवा खाते जैसा है, सिवाय इसके कि यह कोड पढ़ता है और कमांड चलाता है। LeanCTX इसे संरचनात्मक रूप से बंद करता है: पंजीकरण पर मालिक अनिवार्य होते हैं, और एक कमांड (या आपका SCIM डीप्रोविजनिंग फ्लो) एक ही लॉक किए गए लेनदेन में मालिक के पूरे सक्रिय फ़्लीट को निलंबित कर देता है, हर निलंबन का ऑडिट होता है।
लाइफ़साइकल कैसे काम करता है?
active → suspended ⇄ active → decommissioned। निलंबन एक कारण रखता है और इसे वापस किया जा सकता है; डीकमीशनिंग डिज़ाइन द्वारा अंतिम है — रिकॉर्ड कभी डिलीट नहीं होता और न ही सक्रिय होता है, क्योंकि पहचान ऑडिट इतिहास का हिस्सा होती है। हर बदलाव मानकीकृत इवेंट प्रकारों (agent_registered, agent_suspended, agent_resumed, agent_decommissioned — OCP Part 4) का उपयोग करके एक छेड़छाड़-प्रूफ ऑडिट एंट्री लिखता है, इसलिए पहचान परिवर्तन स्वचालित रूप से सबूत बंडलों में दिखाई देते हैं।
सर्टिफिकेशन (attestation) वास्तव में क्या साबित करता है?
पंजीकरण और हर हार्टबीट रनिंग बाइनरी और सक्रिय भूमिका फ़ाइल को हैश करते हैं। एक बदला हुआ हैश का मतलब है कि कुछ बदल गया है — कोई अपग्रेड, कॉन्फ़िग संपादन, या छेड़छाड़ — और यह ड्रिफ्ट के रूप में सामने आता है जिस पर आपके मॉनिटरिंग से अलर्ट किया जा सकता है। यह ड्रिफ्ट डिटेक्शन है, न कि रिमोट अटैस्टेशन: एक हमलावर जिसके पास पूर्ण होस्ट नियंत्रण है वह हैश बना सकता है, और हमारा खतरा मॉडल इसे स्पष्ट रूप से कहता है। यह होस्ट हार्डनिंग और कोड साइनिंग का पूरक है, उन्हें प्रतिस्थापित नहीं करता।
यह हमारे IAM के साथ कैसे एकीकृत होता है?
तीन हुक। SPIFFE: हर रिकॉर्ड spiffe://<trust-domain>/agent/<role>/<agent_id> से मैप होता है, इसलिए K8s वर्कलोड आइडेंटिटी (SPIRE) और LeanCTX पहचान एक ही नाम होती है। SCIM: अपने डीप्रोविजनिंग फ्लो को मालिक के बाहर निकलने वाले कॉल से जोड़ें। लागू करने का मोड (Enforce mode): चेक API एक एकल निर्णय बिंदु है — अपंजीकृत या निलंबित एजेंटों को अस्वीकार किया जाता है; मॉनिटर मोड में शुरू करें, फ़्लीट पंजीकृत होने पर लागू करने पर स्विच करें।
एजेंट कार्यबल का शासन करें।
मिनटों में, स्थानीय रूप से और मुफ्त में अपना पहला एजेंट पंजीकृत करें — या SCIM और SPIFFE के साथ फ़्लीट रोलआउट पर हमसे बात करें।