आपका एजेंट बेड़ा अपनी चाबियों से भरोसेमंद राज्य का निर्माण कर सकता है

अधिकांश बिल्डरों के सामने समस्या

यदि आप एक एजेंट को एक स्टोर के विरुद्ध चलाते हैं, तो एट्रिब्यूशन तुच्छ है। आप जानते हैं कि प्रत्येक पंक्ति किसने लिखी। आपने एजेंट लिखा.

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

प्रति-पंक्ति एट्रिब्यूशन के बिना, जब कुछ गलत होता है तो आपके विकल्प कठिन होते हैं: स्टोर को मिटा दें और फिर से निगल लें, या खराब पंक्तियों को छोड़ दें और बहाव के साथ रहें। जैसे-जैसे स्टोर बढ़ता है, दोनों की हालत ख़राब होती जाती है।

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

मैं कर्सर, क्लाउड कोड, कोडेक्स और चैटजीपीटी पर एजेंट चलाता हूं, सभी एक नियोटोमा इंस्टेंस पर लिखते हैं। मैंने इस बारे में लिखा था कि [वह स्टैक वास्तव में क्या करता है](/पोस्ट/मेरा-एजेंटिक-स्टैक-वास्तव में क्या करता है)। नियोटोमा का AAuth एकीकरण मेरे स्टैक और उस पर निर्माण करने वाले किसी भी व्यक्ति के लिए अंतर को बंद कर देता है: प्रत्येक एजेंट अपनी कुंजी लाता है, और जैसे-जैसे बेड़ा बढ़ता है, स्टोर भरोसेमंद बना रह सकता है।

क्यों AAuth

एट्रिब्यूशन परत AAuth पर बनी है, जो एक खुला प्रोटोकॉल है जो प्रत्येक HTTP क्लाइंट को अपनी क्रिप्टोग्राफ़िक पहचान देता है। कोई पूर्व पंजीकरण नहीं. कोई साझा रहस्य नहीं. कोई वाहक टोकन नहीं. प्रत्येक अनुरोध पर RFC 9421 HTTP संदेश हस्ताक्षर के साथ हस्ताक्षर किए जाते हैं, इसलिए हस्ताक्षर कुंजी के बिना चुराया गया टोकन बेकार है।

मैंने AAuth को चुना क्योंकि इसके पीछे वाला व्यक्ति, डिक हार्ड्ट, एक मित्र है और सबसे गहरे पहचान विशेषज्ञों में से एक है जिसे मैं जानता हूँ। उन्होंने OAuth 2.0 (RFC 6749 का संपादन किया), OpenID प्रमाणीकरण 2.0 के सह-लेखक थे, और OpenID फाउंडेशन के संस्थापक बोर्ड सदस्य थे। यह वही वंशावली है जिसे अधिकांश डेवलपर्स प्राधिकरण कोड प्रवाह और फ़ेडरेटेड लॉगिन के माध्यम से पूरा करते हैं। जब उस इतिहास वाला कोई व्यक्ति विशेष रूप से एजेंटों के लिए एक नया प्रोटोकॉल शुरू करता है, तो वह इसके खिलाफ निर्माण करने लायक है।

अब हर लेखन क्या लेकर आता है

v0.6.0 प्रत्येक लेखन सतह पर प्रति-पंक्ति एजेंट एट्रिब्यूशन भेजता है: /store, /observations/create, /create_relationship, /correct, /entities/split, MCP स्टोर टूल्स, और CLI MCP और HTTP दोनों पर लिखता है। प्रत्येक अवलोकन, संबंध, स्रोत और व्याख्या टिकटें:

• एक सत्यापित एजेंट पहचानकर्ता (हस्ताक्षरित लेखकों के लिए सार्वजनिक-कुंजी थंबप्रिंट, एजेंट टोकन के लिए जेडब्ल्यूटी विषय और जारीकर्ता, फ़ॉलबैक के रूप में क्लाइंटइन्फो नाम और संस्करण)।
• एक ट्रस्ट टियर जो वर्गीकृत करता है कि पहचान कितनी मजबूती से साबित हुई है।
• जिस परिवहन पर लेख आया था।

पांच स्तर स्पेक्ट्रम को कवर करते हैं:

• हार्डवेयर: एजेंट ने एक cnf.attestation लिफाफा (Apple सिक्योर एन्क्लेव, WebAuthn पैक्ड, या TPM2) प्रदान किया जिसे सर्वर ने विश्वसनीय रूट्स के विरुद्ध सत्यापित किया।
• ऑपरेटर_सत्यापित: हस्ताक्षर सत्यापित, और ऑपरेटर ने जारीकर्ता या जारीकर्ता-विषय जोड़ी को अनुमति दी है। ऑपरेटर हार्डवेयर सत्यापन की आवश्यकता के बिना एजेंट की प्रक्रिया की पुष्टि करता है।
• सॉफ़्टवेयर: एजेंट ने सर्वर द्वारा सत्यापित एक वैध कुंजी के साथ अनुरोध पर हस्ताक्षर किए। यह वह जगह है जहां आज अधिकांश एजेंट पहुंचते हैं, जिसमें फ़ाइल-समर्थित ES256 JWK के साथ हस्ताक्षर करने वाला मेरा अपना कर्सर प्रॉक्सी भी शामिल है।
• असत्यापित_क्लाइंट: एजेंट ने खुद को पहचानने योग्य क्लाइंटइन्फो घोषित किया लेकिन हस्ताक्षर नहीं किया।
• 'गुमनाम': कोई पहचान नहीं।

नतीजा: आप अपने स्टोर में किसी भी पंक्ति को देख सकते हैं और प्रथम श्रेणी डेटा के आधार पर "किस एजेंट ने इसे लिखा है" का जवाब दे सकते हैं।

कॉन्फ़िगरेशन फ़ाइलों के बजाय अनुदान

V0.6.0 चक्र की शुरुआत में, क्षमताओं को पर्यावरण-परिवर्तनीय JSON फ़ाइलों से लोड किया गया था। इसने एजेंटों के एक स्थिर सेट के लिए काम किया लेकिन उस क्षण टूट गया जब आप सर्वर को पुनरारंभ किए बिना एक एजेंट को निलंबित करना चाहते थे।

अब: प्रत्येक एजेंट_ग्रांट एक प्रथम श्रेणी की नियोटोमा इकाई है। यह एक AAuth पहचान (विषय, जारीकर्ता, अंगूठे के निशान या संयोजन द्वारा) से मेल खाता है, प्रति ऑपरेशन और इकाई प्रकार के दायरे में क्षमता प्रविष्टियाँ रखता है, और इसका एक जीवनचक्र है: सक्रिय, निलंबित, निरस्त। प्रवेश मिडलवेयर प्रत्येक अनुरोध पर अपने मिलान अनुदान के लिए एक सत्यापित AAuth पहचान का समाधान करता है, अनुरोध संदर्भ पर अनुदान के उपयोगकर्ता और क्षमताओं पर मुहर लगाता है, और डाउनस्ट्रीम प्रवर्तन अनुदान के विरुद्ध प्रत्येक ऑपरेशन की जांच करता है।

अनुदानों को इंस्पेक्टर यूआई, आरईएसटी एपीआई ('पोस्ट/एजेंट/अनुदान', 'पैच', निलंबित, निरस्त, पुनर्स्थापित) के माध्यम से प्रबंधित किया जाता है, या पुराने एनवी-कॉन्फिग से एक बार 'नियोटोमा एजेंट अनुदान आयात' के माध्यम से माइग्रेट किया जाता है। लीगेसी एनवी वर्र्स (NEOTOMA_AGENT_CAPABILITIES_*) अभी भी सेट होने पर बूट-टाइम विफलता का कारण बनता है, जिसमें माइग्रेशन कमांड की ओर इशारा करते हुए एक संरचित त्रुटि होती है।

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

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

उड़ान पूर्व पहचान

प्रत्येक एजेंट अब कोई भी डेटा तैयार करने से पहले नियोटोमा से पूछ सकता है कि क्या उसे एक विश्वसनीय लेखक के रूप में मान्यता प्राप्त है।

तीन समकक्ष प्रवेश बिंदु:

• HTTP पर GET /session।
• MCP टूल के रूप में get_session_identity।
• सीएलआई पर 'नियोटोमा ऑथ सेशन'।

प्रत्येक हल किए गए ट्रस्ट टियर, अनुदान स्थिति (कारण के साथ स्वीकार किया जाता है या नहीं), अनाम-लेखन नीति और एक बूलियन eligible_for_trusted_writes लौटाता है। प्रतिक्रिया में एक डायग्नोस्टिक ब्लॉक शामिल है जो बताता है कि स्तर का समाधान कैसे हुआ। एक नया एजेंट सत्र शुरू होने पर अनाम पंक्तियों को लिखने के बजाय ज़ोर-ज़ोर से विफल हो जाता है जब तक कि कोई नोटिस न कर ले।

भेजे गए एमसीपी निर्देश प्रत्येक कनेक्टेड एजेंट को लिखने को सक्षम करने से पहले इस चेक को चलाने के लिए कहते हैं।

मैं इसे कहां चला रहा हूं

मेरे स्टैक में तीन अलग-अलग सेवा एजेंट आज AAuth के तहत नियोटोमा को लिखते हैं।

कर्सर MCP प्रॉक्सी। कर्सर से प्रत्येक MCP अनुरोध एक साइनिंग प्रॉक्सी (mcp_identity_proxy.py) के माध्यम से प्रवाहित होता है जो एक aa-agent+jwt एजेंट टोकन के साथ RFC 9421 हस्ताक्षर इंजेक्ट करता है। नियोटोमा हस्ताक्षर का सत्यापन करता है, पहचान का समाधान करता है ([email protected], iss=https://markmhendrickson.com), agent_grant से मेल खाता है, और tier=software पर लिखने की अनुमति देता है। प्रॉक्सी स्टार्टअप पर सत्र प्रीफ़्लाइट भी चलाता है और यदि सर्वर अज्ञात स्तर की रिपोर्ट करता है तो बंद हो सकता है।

फीडबैक पाइपलाइन। agent.neotoma.io पर एक Netlify रिले AAuth-हस्ताक्षरित क्लाउडफ्लेयर एक्सेस सुरंग पर नियोटोमा में एजेंट बग रिपोर्ट भेजता है। इसका अनुदान केवल neotoma_feedback संचालन तक सीमित है।

डार्कमेश वार्म-इंट्रो राइटबैक। मेरा डार्कमेश फोर्क (संदर्भ) रिकॉर्ड वार्म-इंट्रो का खुलासा करता है RFC 9421 हस्ताक्षर और aa-agent+jwt टोकन के साथ नियोटोमा में वापस। प्रत्येक नोड के एजेंट_सब, एजेंट_आईएसएस और कुंजी थंबप्रिंट के साथ भूमि को प्रकट करता है, जो प्रति-नोड अनुदान के दायरे में आता है।

डार्कमेश संयुक्त परीक्षणों ने प्रतिकूल स्थिति में प्रवर्तन को साबित कर दिया। एक सहकर्मी नोड से दूसरे सिम्युलेटेड एजेंट ने अपने अनुदान में उस इकाई प्रकार के बिना warm_intro_reveal लिखने का प्रयास किया। नियोटोमा ने लेख को अस्वीकार कर दिया। अधिकृत नोड का लेखन अपरिवर्तित रहा।

रोडमैप पर अगला: markmhendrickson.com पर सार्वजनिक एजेंट एक नियोटोमा इंस्टेंस को अपनी मेमोरी के रूप में लपेटता है और आज केवल उन संस्थाओं को सेवा प्रदान करता है जिन्हें मैंने स्पष्ट रूप से सार्वजनिक रूप से चिह्नित किया है। मैं Aauth-गेटेड रीड्स जोड़ने की योजना बना रहा हूं ताकि अधिकृत विज़िटर विशिष्ट गैर-सार्वजनिक इकाई प्रकारों से पूछताछ कर सकें। समान हस्ताक्षरित-पहचान-प्लस-अनुदान मशीनरी, पठन पथ पर लागू होती है।

बेड़े-व्यापी उन्नयन

नियोटोमा प्रत्येक हैंडशेक पर अपने कैनोनिकल एमसीपी निर्देशों को सर्वर से प्रत्येक कनेक्टेड क्लाइंट तक भेजता है। V0.6.0 में वे निर्देश अब एट्रिब्यूशन प्रीफ़्लाइट, ऑब्जर्वेशन_सोर्स टैगिंग, उत्तर-उद्धृत उद्गम किनारों, अनुमानी-मर्ज चेतावनियों के लिए एक अस्पष्ट (एन) डिस्प्ले समूह और एक संरचित फीडबैक-सबमिशन लूप को संहिताबद्ध करते हैं।

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

ऑडिट सतह

विनियमित बाजारों में उत्पाद-निर्माताओं के लिए, किसी ग्राहक का अनुवर्ती प्रश्न शायद ही कभी होता है "क्या आपके सिस्टम को यह याद था।" यह "इसे किसने लिखा है, और क्या आप साबित कर सकते हैं कि वे अधिकृत थे।"

V0.6.0 के बाद यह प्रथम श्रेणी डेटा के विरुद्ध पढ़ा गया है:

• GET / एजेंट्स सर्वर द्वारा देखी गई प्रत्येक एजेंट पहचान की गणना करता है।
• GET /एजेंट/{key} प्रति-एजेंट विवरण दृश्य लौटाता है।
• GET /agents/{key}/records ऑडिट जो किसी दिए गए एजेंट द्वारा लिखे गए रिकॉर्ड को रिकॉर्ड करता है।
• GET /एजेंट/अनुदान सभी अनुदानों, उनकी क्षमताओं और उनके जीवनचक्र की स्थिति को सूचीबद्ध करता है।

यदि आप स्वास्थ्य देखभाल, वित्त, कानूनी, या उद्यम क्षेत्रों में ग्राहकों को एजेंटिक कार्यक्षमता भेजते हैं, तो यह वह सतह है जिसकी आपके ग्राहक अंततः मांग करेंगे।

इसे कैसे चालू करें

नियोटोमा ऑथ कीजेन --एलजी ईएस256
नियोटोमा ऑथ साइन-उदाहरण
नियोटोमा प्रामाणिक सत्र

इंस्पेक्टर या आरईएसटी एपीआई के माध्यम से नई पहचान के लिए एक अनुदान बनाएं, जो आपके एजेंट की ज़रूरतों के संचालन के लिए क्षमताओं का दायरा बढ़ाए। यदि आप पुराने एनवी-कॉन्फ़िगरेशन मॉडल से अपग्रेड कर रहे हैं, तो एक बार neotoma Agentsgrants import --owner-user-id <your_user_id> चलाएँ, फिर लीगेसी वेरिएबल्स को अनसेट करें।

प्रोग्रामेटिक हस्ताक्षर के लिए, @aauth/local-keys या समतुल्य AAuth लाइब्रेरी RFC 9421 HTTP संदेश हस्ताक्षर और एक aa-agent+jwt टोकन के साथ अनुरोधों पर हस्ताक्षर करती है। नियोटोमा क्लाइंट द्वारा हस्ताक्षरित कच्चे बाइट्स पर हस्ताक्षर की पुष्टि करता है।

AAuth के बिना लिखना अभी भी काम करता है। वे 'गुमनाम' श्रेणी में आते हैं। जो बिल्डर कठिन विफलता चाहते हैं, वे NEOTOMA_AAUTH_STRICT=1 फ़्लिप कर सकते हैं और NEOTOMA_STRICT_AAUTH_SUBS में विशिष्ट विषय जोड़ सकते हैं।

भी भेजा गया

v0.6.0 केवल AAuth नहीं है। एक ही रिलीज भूमि इकाई को अति-मर्ज किए गए रिकॉर्ड, फ्लीट स्नैपशॉट निर्यात प्लस ड्रिफ्ट टूलिंग, conversation_message और sender_kind के माध्यम से प्रथम श्रेणी के मल्टी-एजेंट वार्तालाप, और एक कड़े एपीआई परिधि के लिए विभाजित किया गया है। पूरा पूरक v0.6.0 रिलीज़ नोट्स में है।

स्थापित करें और अपग्रेड करें

एनपीएम इंस्टाल -जी नियोटोमा@[0.6.0](https://github.com/markmhendrickson/neotoma/releases/tag/v0.6.0)
नियोटोमा इनिट
नियोटोमा ऑथ कीजेन
नियोटोमा प्रामाणिक सत्र

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

पूर्ण इंस्टॉल: neotoma.io/install। रेपो: github.com/markmhendrickson/neotoma। रिलीज़ नोट्स: v0.6.0।