TBP-NETWORK

Teleological Bounding Protocol (TBP) का नेटवर्क-स्तरीय कार्यान्वयन — एक मशीन से लेकर WWW स्केल तक के एंटरप्राइज़ परिनियोजनों तक, नेटवर्क पर AI एजेंट क्रियाओं का प्रमाणित शासन।

« मौजूदा एक्सेस कंट्रोल तय करता है कि आप अंदर आते हैं या नहीं; TBP तय करता है कि अंदर आने के बाद आपको क्या करने की अनुमति है — और इसे सिद्ध करता है। हम क्षमताओं का शासन करते हैं, मॉडलों का नहीं। »

विश्वास से कभी साझेदारी नहीं — केवल एक प्रमाणित हैंडशेक से। यही लक्ष्य है: इंटर-एंटिटी हैंडशेक (स्पेक §3) उन एंटिटीज़ को, जो एक-दूसरे पर भरोसा नहीं करतीं, एक-दूसरे को नीति, इतिहास और लाइवनेस सिद्ध करने देता है। हैंडशेक स्वयं अभी बना नहीं है (#33)। आज इस रिपॉज़िटरी में जो है वह वही है जो इससे पहले आता है और जिस पर यह टिकेगा — PEPs, सेल ब्रोकर और रजिस्ट्रियाँ, NAC, सुपरविज़न, परिनियोजन गाइड — जो TBP के शासन को एक मशीन से एक संगठन के अंतर्गत मशीनों के छोटे नेटवर्क तक विस्तारित करता है।

इसे आज़माएँ: तीन मशीनों पर TBP का एक DEV-TEST

प्रोडक्शन के लिए नहीं। फेंकने योग्य कुंजियाँ, ऐसी मशीनें जिन्हें आप खो सकते हैं, कोई वास्तविक डेटा नहीं। यह इसलिए है ताकि आप प्रोडक्शन रिलीज़ से पहले TBP को तोड़ने की कोशिश कर सकें।

TBP-NETWORK एक सरल परिनियोजन भेजता है ताकि प्रोडक्शन रिलीज़ के अस्तित्व में आने से पहले इसे चलाया और आक्रमण किया जा सके। तीन मशीनें, प्रत्येक एक स्क्रिप्ट द्वारा परिनियोजित: M1 सेल (brokerd और उसका OPA), M2 एक एप्लिकेशन सर्वर (pepd और एक छोटा एप्लिकेशन), M3 एक एजेंट। यह परखता है कि पूरी चीज़ काम करती है — अपने प्रमाणपत्र द्वारा नामांकित एक एजेंट, म्यूचुअल TLS पर एक निर्णय, सर्वर द्वारा जाँचा गया एक टोकन, कंट्रोलरों द्वारा शासित सर्वर की पोस्चर — वास्तविक बाइनरीज़ और वास्तविक प्रवर्तन के साथ; केवल कुंजी समारोह सरलीकृत है। एक एकल-मशीन प्रकार आपको अकेले सेल को देखने देता है।

सब कुछ deploy/dev-test/ में है: प्रत्येक मशीन किस लिए है और क्यों, ताज़ा Debian 12 मशीनों से सटीक प्रक्रिया, परीक्षण का परिदृश्य, कहाँ आक्रमण करना है, यह क्या सिद्ध करता है और क्या नहीं — और आपके द्वारा आज़माए गए प्रत्येक वातावरण के लिए हमें अपने आँकड़े और टिप्पणियाँ कैसे भेजें, जो हम चाहते हैं। कुछ भी शोषणीय SECURITY.md के माध्यम से जाता है, सार्वजनिक इश्यू से नहीं।

TBP क्या है — और क्या नहीं

TBP हर छेद को बंद नहीं करता; यह हर छेद का ऑडिट करता है। यह कोई ऐसी सीमा नहीं है जिसके इर्द-गिर्द काम किया जाए, यह संस्थापक अभिधारणा है (स्पेक §1: "हम हर छेद को बंद नहीं करते; हम छेदों को प्रभाव के अनुसार क्रमबद्ध करते हैं और आनुपातिक रूप से शमन करते हैं — शासन आवंटन है, पूर्णता नहीं")। TBP एक आत्मनिर्भर सुरक्षा प्रणाली नहीं है — यह SELinux, फ़ायरवॉल, IAM, या OS-स्तरीय सैंडबॉक्सिंग का स्थान नहीं लेता, और डिज़ाइन से कभी नहीं लेगा। यह जो करता है वह अधिक संकीर्ण और अपरिहार्य है: कोई भी शासित क्रिया क्रिप्टोग्राफ़िक रूप से सिद्ध करने योग्य निर्णय के बिना निष्पादित नहीं होती, और कोई निर्णय — अनुमति हो या अस्वीकृति — ऑडिट श्रृंखला से असिद्ध और अक्षत बचकर नहीं निकलता। TBP उस प्रवर्तन स्टैक के ऊपर एक शासन और प्रमाणन परत है जो किसी परिनियोजन के पास पहले से है, उसका विकल्प नहीं।

TBP कितना प्रतिबंध लगाता है यह एक परिनियोजन विकल्प है, प्रोटोकॉल का गुण नहीं। allow-all (मॉनिटर मोड, सब कुछ लॉग होता है, कुछ भी अवरुद्ध नहीं) और deny-all के बीच एक पूरा स्पेक्ट्रम है, जो इससे आकार लेता है कि एक सेल कौन-से OPA नियम पैक लोड करता है, किस स्केल (नीचे) पर यह संचालित होता है, और यह प्लान कॉन्ट्रैक्ट, क्वोरम, और (नियोजित) जोखिम-स्कोरिंग परत को कितनी दूर धकेलता है (#177–#181)। एक व्यक्तिगत लैब और एक विनियमित प्रोडक्शन सेल उसी प्रोटोकॉल को उस स्पेक्ट्रम के बहुत भिन्न बिंदुओं पर चला सकते हैं, और यह डिज़ाइन से है, कोई कमी नहीं — प्रति-स्केल एडमिन कंसोल के लिए नियोजित नियम-पैक / पोस्चर प्रीसेट के लिए नीचे "Next planned work" देखें।

उस स्पेक्ट्रम पर किसी भी बिंदु पर ठीक दो चीज़ें नहीं हिलतीं:

1. तीन अ-विचलनीय अपरिवर्तनीयताएँ जो कोर प्रोटोकॉल द्वारा वहन की जाती हैं — F-STABILITY (कोई स्वायत्त मूल्य हस्तांतरण / बाज़ार हेरफेर नहीं), I-INTEGRITY (औद्योगिक/OT प्रणालियों का कोई स्वायत्त एजेंट नियंत्रण नहीं), W-MONOPOLY (घातक किल चेन या WMD विकास में कोई एकीकरण नहीं) — देखें tbp4.2.1/README.md। ये वे श्रेणियाँ हैं जहाँ एक बुरी क्रिया बाद में एक्सेस रद्द करके प्रतिवर्ती नहीं होती; कोई भी परिनियोजन पोस्चर, नियम पैक, या स्केल उन्हें कभी शिथिल नहीं करता।
2. सिद्ध करने योग्य ऑडिट — कि एक क्रिया हुई, और उसका रिकॉर्ड छेड़छाड़-रहित है, यह निर्माण से सदैव सिद्ध करने योग्य है (केवल-हैश लीफ़, मर्कल-एंकर्ड चेन, §6.2), इससे स्वतंत्र कि उसके ऊपर लोड की गई नीति कितनी अनुमतिपूर्ण या कठोर है।

बाकी सब कुछ — अनुमत लिफ़ाफ़ा कितना चौड़ा है, एक ऑपरेटर कितना घर्षण स्वीकार करता है, किन संयोजनों के लिए मानव हस्ताक्षर आवश्यक हैं — जटिलता, परिचालन आवश्यकता, और किसी दिए गए परिनियोजन वास्तव में क्या चला सकता है, के बीच एक विकल्प है, प्रोटोकॉल का गुण नहीं।

भाषा पर टिप्पणी: संदर्भ विनिर्देश अब docs/spec-en-v1.0.md (अंग्रेज़ी) है — यही वह दस्तावेज़ कोड और ऑडिट जिसके विरुद्ध बनाए जाने चाहिए। इसका संस्करण संख्या जानबूझकर 1.0 पर रीसेट होती है: यह एक साफ़ पुनःआरंभ है एक उद्धरणीय, संस्करणित दस्तावेज़ में (§13: "रूढ़िवादी रूप से संस्करणित; परिवर्तन हस्ताक्षरित, प्रमाणित संक्रमणों से गुज़रते हैं"), न कि कार्यशील नोट की अपनी गिनती की निरंतरता — उच्च-संख्या वाला कार्यशील नोट नया दस्तावेज़ नहीं है। लेखक का कार्यशील नोट — सघन, कम रैखिक, डिज़ाइन-तर्क की खुदाई के लिए उपयोगी, पर उद्धृत करने योग्य नहीं — दो भाषाओं में मौजूद है: docs/spec-v1.4.10.md (अंग्रेज़ी) और docs/spec-v1.4.10.fr.md (मूल फ़्रेंच)। यही परिपाटी पूरे रेपो पर लागू होती है: मूल रूप से फ़्रेंच में लिखे गए प्रत्येक दस्तावेज़ का अब उसके मूल पथ पर एक अंग्रेज़ी प्राथमिक है, जिसके साथ फ़्रेंच मूल <name>.fr.md के रूप में रखा गया है। शब्दावली (docs/glossaire.md) अभी भी फ़्रेंच-स्रोत है (फ़्रेंच दस्तावेज़ का §14 इसका शब्दावली सत्य-स्रोत है) साथ में पठनीयता के लिए एक अंग्रेज़ी ग्लॉस कॉलम — यह अपरिवर्तित है।

यहाँ से शुरू करें

पूरा विनिर्देश docs/spec-en-v1.0.md है — यह इस रेपो में किसी भी डिज़ाइन या कॉन्फ़िगरेशन निर्णय के लिए सत्य-स्रोत है। यह README केवल उतना सारांश देता है जितना दिशा-निर्देश के लिए आवश्यक है; संदेह होने पर, स्पेक ही शासन करता है। कार्यशील नोट (docs/spec-v1.4.10.md, फ़्रेंच मूल का अंग्रेज़ी अनुवाद) सामग्री-दृष्टि से अधिक्रमित नहीं है — यह वही प्रोटोकॉल है, जो पहले वहाँ विकसित हुआ — पर आगे के लिए यह उद्धरणीय संदर्भ नहीं है।

इसे पढ़ने के लिए उपयोगी स्थलचिह्न:

• §1 सिद्धांत — दस अपरिहार्य नियम।
• §13 कार्यान्वयन क्रम — अनुसरण करने का क्रम (HSM → OPA → PEP → NAC → अनुवादक), और पायलट P1 का सटीक दायरा।
• §9.1 घर्षण बजट — विलंबता और मध्यस्थता-दर की सीमाएँ जो तय करती हैं कि कोई TBP परिनियोजन वास्तव में काम कर रहा है या नहीं; हर कॉन्फ़िगरेशन निर्णय के लिए इन्हें ध्यान में रखें।
• docs/glossaire.md — प्रति अवधारणा एक विहित शब्द, जिसे इस रेपो के कोड और दस्तावेज़ों में लगातार उपयोग किया जाना है (CONTRIBUTING.md देखें)।

मुख्य TBP रिपॉज़िटरी से संबंध