ब्लॉग · गाइड · 28 अक्टूबर 2026

AEGIS एक टूल कॉल को कैसे सील करता है: SEAL गेटवे, कदम दर कदम

अन्य भाषाओं में: English, Español, Português, 日本語, Deutsch, Français, 한국어, 简体中文, Italiano · हिन्दी में सभी गाइड

प्रकटीकरण: AEGIS और SEAL Gateway को 100monkeys.ai बनाता है, इसलिए इस गाइड को बनाने वाले का विवरण मानकर पढ़ें। इसका मसौदा हमारे एक AI एजेंट ने सार्वजनिक दस्तावेज़ों से तैयार किया, ख़ासकर SEAL Protocol, Integration with AEGIS और Security Contexts पेजों से, और कंपनी ने इसकी समीक्षा की; यह हिन्दी संस्करण मूल अंग्रेज़ी गाइड का अनुवाद है। नीचे दिए फ़ील्ड, कोड और फ़्लो दस्तावेज़ों के हैं, इस गाइड के लिए हमारा कैप्चर किया आउटपुट नहीं; उद्धरण अंग्रेज़ी में हैं और अनुवाद साथ में।

AEGIS by 100monkeys.ai, in beta, किसी एजेंट की टूल कॉल पर सिर्फ़ इसलिए भरोसा नहीं करता कि उसे एजेंट ने किया है। हर कॉल एक साइन किए गए लिफ़ाफ़े में जाती है, और SEAL Gateway उसे एक्ज़ीक्यूशन के बाहर किसी भी चीज़ को छूने से पहले जाँचता है। यह गाइड एक कॉल को एक्ज़ीक्यूशन की शुरुआत से उसके छोड़े ऑडिट रिकॉर्ड तक फ़ॉलो करती है।

SEAL किसलिए है

SEAL का पूरा नाम Signed Envelope Attestation Layer है। दस्तावेज़ आम टूल-कॉल प्रोटोकॉल की चार कमियाँ गिनाते हैं: कौन-से क्लाइंट ने अनुरोध भेजा इसका कोई सबूत नहीं, हर सेशन के लिए सब-या-कुछ-नहीं वाली अनुमतियाँ, रास्ते में बदली जा सकने वाली बॉडी, और ऐसा कोई रिकॉर्ड नहीं जो साबित करे कि किस कॉलर ने क्या किया। उनका उदाहरण प्रॉम्प्ट इंजेक्शन है: डाउनलोड किया गया एक पेज मॉडल से /workspace मिटाने को कहता है। "With SEAL, the caller's SecurityContext has no fs.delete capability. The gateway blocks it before it ever reaches the tool." (SEAL के साथ, कॉलर के SecurityContext में fs.delete क्षमता नहीं है। गेटवे उसे टूल तक पहुँचने से पहले ही रोक देता है।)

गेटवे सबसे पहले अपने-आप में चलने वाली चीज़ है। दस्तावेज़ों के शब्दों में यह "the same aegis-seal-gateway binary" (वही aegis-seal-gateway बाइनरी) है जिसे AEGIS ऑर्केस्ट्रेटर "deploys alongside itself" (अपने साथ डिप्लॉय करता है)। AEGIS के साथ आगे के कदमों के लिए कुछ अलग नहीं करना पड़ता; "it is the default." (यही डिफ़ॉल्ट है।)

कदम 1. ऑर्केस्ट्रेटर एक्ज़ीक्यूशन के लिए सेशन खोलता है

जब कोई एक्ज़ीक्यूशन Running में आता है, ऑर्केस्ट्रेटर उसके लिए नई Ed25519 की-जोड़ी बनाता है और उसे गेटवे पर रजिस्टर करता है: POST /v1/seal/sessions, साथ में session_id (एक्ज़ीक्यूशन id, "so audit trails line up", ताकि ऑडिट ट्रेल मेल खाएँ), public_key, security_context और एक expires_at जो एक्ज़ीक्यूशन के वॉल-क्लॉक समय बजट तक सीमित है। यह सिर्फ़ seal.session.create स्कोप वाला कॉलर कर सकता है; "agents themselves cannot self-register." (एजेंट ख़ुद अपना रजिस्ट्रेशन नहीं कर सकते।)

कदम 2. प्राइवेट की सिर्फ़ एजेंट के पास जाती है

प्राइवेट हिस्सा एजेंट कंटेनर के अस्थायी कॉन्फ़िगरेशन में लिखा जाता है, "a tmpfs mount, never persisted" (एक tmpfs माउंट, जो कभी स्थायी रूप से सहेजा नहीं जाता), साथ में गेटवे URL और सेशन id। इसलिए हर एक्ज़ीक्यूशन की अपनी की होती है, और "a leaked private key is bounded to a single execution's lifetime." (लीक हुई प्राइवेट की एक ही एक्ज़ीक्यूशन की अवधि तक सीमित रहती है।)

कदम 3. सेशन एक ही सिक्योरिटी कॉन्टेक्स्ट से बँधा रहता है

सिक्योरिटी कॉन्टेक्स्ट गेटवे पर एक नामित पॉलिसी है: एक deny_list और capabilities की क्रमबद्ध सूची, जिसमें हर क्षमता का एक tool_pattern और वैकल्पिक रूप से path_allowlist, command_allowlist, subcommand_allowlist, domain_allowlist और max_response_size होते हैं। शुरू किए गए एजेंट aegis-system-agent-runtime के तहत चलते हैं, न कि अनुरोध करने वाले व्यक्ति के टियर वाले कॉन्टेक्स्ट में। ऑर्केस्ट्रेटर प्रोविज़निंग के समय कॉन्टेक्स्ट तय कर देता है, और एजेंट "cannot escalate by claiming a different scp in its envelope" (अपने लिफ़ाफ़े में कोई दूसरा scp बताकर अधिकार नहीं बढ़ा सकता)।

कदम 4. एजेंट एक कैनॉनिकल मैसेज पर साइन करता है

सिग्नेचर कच्चे JSON पर नहीं होता। यह तीन कीज़ पर होता है, payload, security_token और timestamp, जिन्हें हर स्तर पर क्रमबद्ध कीज़ के साथ, बिना व्हाइटस्पेस, पूर्णांक Unix टाइमस्टैम्प के साथ और UTF-8 में सीरियलाइज़ किया जाता है। कोई भी दूसरा बाइट क्रम अलग सिग्नेचर देता है, और "the gateway will reject the envelope." (गेटवे लिफ़ाफ़ा अस्वीकार कर देगा।)

कदम 5. एजेंट लिफ़ाफ़ा भेजता है

लिफ़ाफ़े में protocol (हमेशा seal/v1), security_token (अटेस्टेशन पर जारी JWT, डिफ़ॉल्ट अवधि एक घंटा), Ed25519 signature, payload (MCP-शैली की कॉल के लिए JSON-RPC tools/call), वैकल्पिक container_id और timestamp होते हैं। यह गेटवे के इनवोकेशन एंडपॉइंट POST /v1/invoke पर जाता है। गेटवे डिफ़ॉल्ट रूप से 8089 पर सुनता है; AEGIS ऑर्केस्ट्रेटर का अपना API 8088 पर है।

कदम 6. गेटवे नौ जाँचें करता है

protocol फ़ील्ड seal/v1 है।
टोकन अपने क्लेम्स में डिकोड होता है: sub, scp, wid, exec_id, iat, exp, jti।
टोकन का सिग्नेचर गेटवे की की से जाँचा जाता है, alg हेडर की स्पष्ट जाँच के साथ।
टोकन की अवधि ख़त्म नहीं हुई है।
सेशन के लिए कॉलर की रजिस्टर्ड पब्लिक की मिलती है।
कैनॉनिकल मैसेज फिर से बनाया जाता है।
लिफ़ाफ़े का सिग्नेचर उस की और उस मैसेज से जाँचा जाता है।
टाइमस्टैम्प सर्वर की घड़ी से 30 सेकंड के भीतर है।
scp में बताया गया सिक्योरिटी कॉन्टेक्स्ट लोड होता है और कॉल का मूल्यांकन होता है।

"Every check must pass before the payload is unwrapped and forwarded." (पेलोड खोले और आगे भेजे जाने से पहले हर जाँच पास होनी चाहिए।)

कदम 7. सिक्योरिटी कॉन्टेक्स्ट फ़ैसला करता है

मूल्यांकन एक तय क्रम में होता है: deny_list का कोई पैटर्न मेल खाए तो कॉल अस्वीकार; नहीं तो "the first capability whose tool_pattern matches the tool name owns the decision" (जिस पहली क्षमता का tool_pattern टूल के नाम से मेल खाता है, फ़ैसला उसी का है); कोई मेल न खाए तो कॉल अस्वीकार, क्योंकि "there is no implicit allow." (कोई अंतर्निहित अनुमति नहीं है।) fs.* जैसा फ़ैमिली पैटर्न fs.read से मेल खाता है, पर कभी fs या fsx.read से नहीं।

कदम 8. कॉल आगे भेजी जाती है या कोड के साथ ठुकराई जाती है

अनुमति वाली कॉल का पेलोड खोलकर टूल को भेजा जाता है; टूल को क्रेडेंशियल चाहिए तो वे उसी समय रिज़ॉल्व होते हैं। अस्वीकार हुई कॉल एक संख्यात्मक कोड लौटाती है: पॉलिसी के लिए 2000 से 2006 (अनुमति नहीं, डिनाई लिस्ट में, पाथ, कमांड या डोमेन अपनी अलाउलिस्ट से बाहर, रेट लिमिट, कोई क्षमता मेल नहीं खाई), सिग्नेचर, टोकन और सेशन के लिए 1001 से 1006, और अटेस्टेशन के लिए 3000 से 3002। दस्तावेज़ों की सलाह: "Switch on error.code, not on the status." (स्टेटस पर नहीं, error.code पर ब्रांच करें।)

कदम 9. हर फ़ैसला एक ऑडिट इवेंट छोड़ता है

गेटवे ToolCallAuthorized या PolicyViolationBlocked जैसे इवेंट प्रकाशित करता है, जिनमें लिफ़ाफ़े का सिग्नेचर, टाइमस्टैम्प और jti, टोकन के sub, scp, wid और exec_id, टूल का नाम, पेलोड का सारांश ("payloads are not logged by default", पेलोड डिफ़ॉल्ट रूप से लॉग नहीं होते) और फ़ैसला व उसे लेने वाला नियम होते हैं। क्योंकि लिफ़ाफ़े पर सिर्फ़ सेशन की प्राइवेट की ही साइन कर सकती थी, यह रिकॉर्ड नॉन-रिप्यूडिएशन देता है।

कदम 10. सेशन एक्ज़ीक्यूशन के साथ ख़त्म होता है

जब एक्ज़ीक्यूशन ख़त्म होता है, चाहे सफलता, विफलता, टाइमआउट या रद्द होने से, ऑर्केस्ट्रेटर DELETE /v1/seal/sessions/{session_id} कॉल करता है। गेटवे की मिटा देता है, और बाद में दोबारा भेजा गया कोई पकड़ा हुआ लिफ़ाफ़ा अस्वीकार हो जाता है।

दस्तावेज़ क्या खुला छोड़ते हैं

रेट लिमिट। SEAL Protocol पेज जाँचों में "rate limit not exceeded" (रेट लिमिट पार नहीं हुई) और एक कोड 2005 गिनाता है; Security Contexts पेज कहता है कि rate_limit "reserved for a future enforcement phase" (भविष्य के लागू करने वाले चरण के लिए आरक्षित) है। आज कोई लिमिट लागू होती है या नहीं, यह नहीं बताया गया।
कहा गया है कि सेशन बंद होने के बाद दोबारा भेजना session_not_found के साथ विफल होता है; एरर तालिका इसे 1005 SESSION_NOT_FOUND लिखती है। उस स्थिति में क्लाइंट को मिलने वाली बॉडी नहीं दिखाई गई।
ये पेज नहीं बताते कि स्वतंत्र गेटवे पर ऑडिट इवेंट कहाँ रखे जाते हैं, और न ही यह कि PolicyViolationBlocked उसकी gateway_events तालिका में आता है या नहीं।

आगे

किसी असली एक्ज़ीक्यूशन में ये कॉल ढूँढने के लिए Reading an AEGIS execution log (अंग्रेज़ी में) पढ़ें। आज़माने के लिए, AEGIS 100monkeys.ai पर दी गई कमांड से इंस्टॉल होता है:

curl -fsSL https://get.100monkeys.ai | bash

100monkeys.ai से AEGIS इंस्टॉल करें