Skip to content
KitploitKITPLOIT
उपकरणएक्सप्लॉइटब्लॉग
Log in
जमा करें
उपकरणएक्सप्लॉइटब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

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

फ़ीडसंपर्कगोपनीयता© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
aegis-latent-core — AI सिस्टम के लिए स्व-होस्टेड एविडेंस गेटवे: fail-closed नीति, WAF, egress नियंत्रण, हस्ताक्षरित टिकाऊ MMR प्रमाण, और LLM प्रदाताओं में ऑफ़लाइन सत्यापन। | Kitploit
उपकरण/GitHubGitHub/juanlunaia/aegis-latent-core
क्रिप्टोग्राफीक्लाउड सुरक्षाखतरा खुफियाAPI सुरक्षाAI सुरक्षालॉग विश्लेषण
GitHubjuanlunaia/aegis-latent-core

aegis-latent-core

AI सिस्टम के लिए स्व-होस्टेड एविडेंस गेटवे: fail-closed नीति, WAF, egress नियंत्रण, हस्ताक्षरित टिकाऊ MMR प्रमाण, और LLM प्रदाताओं में ऑफ़लाइन सत्यापन।

रिपॉजिटरी देखें
1841015 दिन पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें
वेबसाइट

Aegis Latent Core

AI गवर्नेंस और क्रिप्टोग्राफिक एविडेंस गेटवे

Aegis Latent Core प्रत्येक शासित AI कॉल का हस्ताक्षरित, हैश-लिंक्ड प्रमाण प्रतिबद्ध करता है — इससे पहले कि प्रतिक्रिया कॉलर तक पहुँचे — और एक पोर्टेबल प्रमाण जारी करता है जिसे कोई तीसरा पक्ष गेटवे, हम, या आप पर भरोसा किए बिना सत्यापित करता है।

release CI Security coverage License

इस फ़ाइल में प्रत्येक भार-वहन करने वाले दावे के साथ एक लोकेटर और एक घोषित सीमा होती है; उस अनुशासन को लागू करने वाले गेट CI में चलते हैं।

वर्तमान रिलीज़: v5.0.1 — नवीनतम प्रकाशित रिलीज़ (चेकआउट किया गया स्रोत v5.0.2 है, एक Apache-2.0 स्रोत लक्ष्य जो प्रकाशित नहीं है), 2026-09-24 को प्रत्येक सतह पर प्रकाशित (PyPI aegis-latent-core 5.0.1 2026-09-26 को अनुसरण किया), उसी दिन वापस पढ़ा गया (Release Status §1.0a)। Sigstore-हस्ताक्षरित टैग gitsign verify-tag पास करता है; GitHub Release में 31 एसेट हैं और इसके SHA256SUMS में सूचीबद्ध सभी 15 फ़ाइलें अपने डाइजेस्ट पर पुनः-हैश होती हैं; PyPI aegis-latent-sdk 5.0.1 और npm aegis-latent-sdk 5.0.1 समान नाम के रिलीज़ एसेट के साथ बाइट-समान हैं; और GHCR गेटवे और डैशबोर्ड इमेज cosign verify पास करती हैं और उनके बिल्ड-प्रोवेनेंस अटेस्टेशन सत्यापित होते हैं, प्रत्येक सटीक प्रकाशन वर्कफ़्लो पहचान के विरुद्ध। गेटवे वितरण aegis-latent-core 2026-09-26 को PyPI पर 5.0.1 पर पहुँचा (publish_pypi_gateway.yml का रन 36224961909, 2026-09-29 को वापस पढ़ा गया, Release Status §1.0b); pip install aegis-latent-core 5.0.1 पर रिज़ॉल्व होता है, और इसका wheel और sdist रिलीज़ एसेट से बाइट-दर-बाइट मेल खाते हैं। GHCR इमेज और Release एसेट उपलब्ध बने रहते हैं। पिछली रिलीज़, v5.0.0, 2026-09-16 को उन्हीं सतहों पर प्रकाशित हुई थी (§1.0)। कोई 4.2.0 नहीं है; वह संख्या छोड़ दी गई थी।

PyPI पर गेटवे के साथ पहला प्रकाशित संस्करण: v4.1.2, 2026-09-04 को वापस पढ़ा गया — हस्ताक्षरित एनोटेटेड टैग, 31 एसेट के साथ GitHub Release, PyPI aegis-latent-core 4.1.2, PyPI aegis-latent-sdk 4.1.2, npm aegis-latent-sdk 4.1.2, और GHCR गेटवे और डैशबोर्ड इमेज। 4.1.2 पहला संस्करण है जो PyPI से aegis-latent-core के रूप में इंस्टॉल करने योग्य है; इससे पहले गेटवे केवल स्रोत या GHCR से आता था। npm संस्करण सूची 4.1.1 को छोड़ देती है, जिसका प्रकाशन चरण विफल रहा। एक v4.1.0 रिलीज़ ऑब्जेक्ट भी मौजूद है लेकिन यह पाइपलाइन के बाहर बनाया गया था और इसमें कोई एसेट नहीं है; इसे अनदेखा करें। दो 4.1.2 PyPI गेटवे आर्टिफ़ैक्ट समान नाम के रिलीज़ एसेट से बाइट-भिन्न हैं — समान सामग्री, भिन्न बिल्ड होस्ट — इसलिए SHA256SUMS उन डाउनलोड को कवर नहीं करता; 5.0.1 PyPI गेटवे आर्टिफ़ैक्ट इसे मैच करते हैं। प्रोवेनेंस और रीडबैक के लिए Release Status देखें।


समस्या

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

एक विनियमित उद्योग में यह कागज़ी कार्रवाई की समस्या नहीं है — यह एक अस्तित्वगत समस्या है। नियामक, न्यायालय और लेखा परीक्षक प्रत्येक एक ही प्रश्न पूछते हैं, और "हमारे लॉग शायद ठीक हैं" वह उत्तर नहीं है जिसे वे स्वीकार करते हैं:

  1. जिस रिकॉर्ड को इच्छुक पक्ष बदल सकता था वह साक्ष्य नहीं है — यह केवल तब तक साक्ष्य के रूप में पढ़ा जाता है जब तक कोई संदेह करने का कारण रखने वाला एक प्रश्न नहीं पूछता।
  2. आप पहले से ही किसी के प्रति एक ऐसे रिकॉर्ड के ऋणी हैं जिसके पीछे आप खड़े हो सकें — EU AI Act Art. 12, HIPAA ऑडिट नियंत्रण, SEC 17a-4 का ऑडिट-ट्रेल विकल्प, MiFID II। वे आपके दायित्व हैं; यह सॉफ़्टवेयर उनके लिए एक इनपुट है, कभी भी उनका निर्वहन नहीं।
  3. समाधान ऐसे व्यक्ति द्वारा जाँचने योग्य होना चाहिए जो आप पर अविश्वास करता है, अन्यथा यह वही समस्या है जिसने बेहतर कपड़े पहन रखे हैं।

Aegis समाधान

  • केवल-जोड़ने योग्य, छेड़छाड़-स्पष्ट MMR। प्रत्येक रिकॉर्ड एक Merkle Mountain Range में एक लीफ है। एक पोर्टेबल इन्क्लूज़न प्रूफ़ (O(log n), कोई ज़ीरो-नॉलेज दावा नहीं) किसी तीसरे पक्ष को एक प्रकट किए गए रिकॉर्ड को उस रूट के विरुद्ध सत्यापित करने देता है जिसे उसने स्वतंत्र रूप से प्राप्त किया। verify_integrity() पढ़ने पर छेड़छाड़ का पता लगाता है; छेड़छाड़ पता लगाई जाती है, रोकी नहीं जाती — नीचे दी गई सीमाएँ देखें।
  • क्रिप्टोग्राफिक सीलिंग। प्रत्येक रिकॉर्ड को एक चेन लिंक में हैश किया जाता है और हस्ताक्षरित किया जाता है — डिफ़ॉल्ट रूप से HMAC, जहाँ कॉन्फ़िगर किया गया हो वहाँ Ed25519 (RFC 8032) या ML-DSA-65 (FIPS 204), एंटरप्राइज़ सर्वर में HSM पथ के साथ। वैकल्पिक प्रति-विषय श्रेडिंग (AES-256-GCM कुंजी विनाश) सिफरटेक्स्ट धारक के दृश्य से प्लेनटेक्स्ट को मिटा देती है MMR रूट या पहले जारी किए गए प्रूफ़ को बदले बिना।
  • ज़ीरो-ट्रस्ट सत्यापन। प्रूफ़ ऑफ़लाइन सत्यापित होते हैं: एक 313-पंक्ति का शुद्ध-Python सत्यापनकर्ता, समान सेमांटिक्स वाला एक TypeScript जुड़वाँ, और शून्य नेटवर्क कॉल। गेटवे, विक्रेता, या रिकॉर्ड प्रकट करने वाले ऑपरेटर पर कोई भरोसा नहीं — केवल उस रूट पर जिसे आपने ऐसे चैनल के माध्यम से प्राप्त किया जिसे प्रकटकर्ता नियंत्रित नहीं करता।
  • नियामक इनपुट। MiFID II Art. 16(6)/16(7) और MiFIR Art. 25(1) रिकॉर्ड-कीपिंग फ़्रेमिंग (टिकाऊ, प्रक्रिया-के-भीतर क्रमबद्ध रिकॉर्ड; कोई ऑर्डर नहीं — RTS 24 — और कोई क्लॉक ट्रेसबिलिटी नहीं — RTS 25); EU AI Act Art. 12 लॉगिंग इनपुट (प्रतिक्रिया-से-पहले प्रतिबद्धता, छेड़छाड़ का पता लगाना, सत्यापन योग्य इन्क्लूज़न); HIPAA Safe-Harbor-शैली पैटर्न रिडैक्शन; ISO/IEC 27037-शैली एक्सट्रैक्ट। ये तकनीकी इनपुट हैं, अनुपालन नहीं। कोई प्रमाणन मौजूद नहीं है, कोई प्रगति में नहीं है, और क्या कोई दायित्व पूरा होता है यह आपके और आपके मूल्यांकनकर्ता के लिए एक निर्धारण है (CLM-039 LEGAL-REVIEW-REQUIRED है)।

→ स्वयं सिद्ध करें — Python की बारह पंक्तियाँ, हमारे सर्वरों पर कोई कॉल नहीं, तीन मामले जिनमें से दो विफल होने चाहिए।

pip install aegis-latent-sdk aegis-latent-core   # verifier + gateway, both 5.0.1 on PyPI
python tools/sales/prove_it/prove_it.py --demo   # accepts one record, rejects two forgeries
python -m examples.demo                          # gateway + mock upstream, tamper detected

दोनों कमांड इस रिपॉज़िटरी के चेकआउट से चलते हैं; प्रत्येक क्या दिखाता है और क्या नहीं दिखाता।


एक नज़र में आर्किटेक्चर

 caller ──────────►  Aegis gateway  ──────────────────────────►  upstream provider
                        │  admission: auth · scope · bounds
                        │  WAF · rate limiting · session checks
                        │
                        │  (policy passed) forward
                        │  ◄─────────────── response ─────────
                        │
                        │  redact → hash → sign → WAL append + fsync → MMR leaf
                        │  (refused requests: the refusal is committed to the
                        │   same signed chain before the error returns)
                        │
 caller ◄──────────  response + X-Aegis-Evidence-Status
                        + X-Aegis-Request-ID + X-Aegis-MMR-* proof headers

नॉन-स्ट्रीमिंग। एविडेंस रिकॉर्ड कॉलर द्वारा प्रतिक्रिया देखे जाने से पहले प्रतिबद्ध किया जाता है।

टूल डाउनलोड करें