mattijsmoens/intentshieldAI एजेंटों के लिए निष्पादन-पूर्व आशय सत्यापन। आपका AI जो करने वाला है, उसका ऑडिट करता है, न कि वह जो कहता है। शून्य निर्भरताएँ, नियतात्मक, हैश-सील्ड।
AI एजेंटों के लिए निष्पादन-पूर्व इरादे का सत्यापन।
AI एजेंटों के पास टूल एक्सेस होता है। वे शेल कमांड चला सकते हैं, फ़ाइलें लिख सकते हैं, URL ब्राउज़ कर सकते हैं, ईमेल भेज सकते हैं और API कॉल कर सकते हैं। उनमें से हर एक क्रिया एक संभावित हमले की सतह है।
अधिकांश AI सुरक्षा उपकरण आउटपुट परत पर काम करते हैं। वे स्कैन करते हैं कि AI क्या कहता है। लेकिन खतरनाक हिस्सा यह नहीं है कि AI क्या कहता है। यह है कि AI क्या करता है। एक प्रॉम्प्ट इंजेक्शन जो AI को rm -rf / चलाने के लिए धोखा देता है, हर कंटेंट फ़िल्टर से गुज़र जाता है क्योंकि फ़िल्टर केवल टेक्स्ट देखता है। शेल कमांड किसी के ध्यान में आने से पहले ही निष्पादित हो जाता है।
IntentShield AI के निर्णय और क्रिया के निष्पादन के बीच बैठता है। जब AI कोई क्रिया प्रस्तावित करता है, तो IntentShield उसके चलने से पहले क्रिया के प्रकार और पेलोड को अपरिवर्तनीय सुरक्षा नियमों के विरुद्ध ऑडिट करता है। शेल कमांड ब्लॉक हो जाते हैं। फ़ाइल विलोपन ब्लॉक हो जाते हैं। क्रेडेंशियल एक्सफ़िल्ट्रेशन ब्लॉक हो जाता है। जेलब्रेक प्रयास ब्लॉक हो जाते हैं। यह सब नियतात्मक रूप से होता है, सुरक्षा पथ में शून्य LLM कॉल के साथ। कोई भी मॉडल स्ट्रिंग मिलान और regex से बात करके नहीं निकल सकता।
सुरक्षा नियम स्वयं एक FrozenNamespace मेटाक्लास का उपयोग करके सील किए जाते हैं जो उन्हें मेमोरी में भौतिक रूप से असंशोधनीय बनाता है, और SHA-256 हैश-लॉक के साथ डिस्क पर ताकि स्टार्टअप पर फ़ाइल छेड़छाड़ का पता चल सके। AI अपनी स्वयं की सुरक्षा परत को संशोधित नहीं कर सकता, और न ही कोई हमलावर कर सकता है।
1.3.0 डिस्क पर लॉकफ़ाइलों को पूरी तरह से हटा देता है। यदि आप 1.2.x या उससे पहले के संस्करण से अपग्रेड कर रहे हैं तो आप किसी भी बचे हुए data/.core_safety_lock और data/.conscience_lock फ़ाइलों को हटा सकते हैं - उन्हें अब पढ़ा या लिखा नहीं जाता है, और उनकी उपस्थिति हानिरहित है। और कुछ आवश्यक नहीं है; सील हर प्रक्रिया प्रारंभ पर मेमोरी में पुनर्निर्मित होती है।
SovereignShield 2.4.1/2.4.2 से बैकपोर्ट की गई अखंडता सील की सुरक्षा सख्ती।
.core_safety_lock फ़ाइल से पुनः लोड किया जाता था, जिसका अर्थ था कि एक हमलावर जो स्रोत को संशोधित कर सकता था, वह लॉकफ़ाइल को भी फिर से लिख सकता था और सफाई से फिर से सील कर सकता था। हैश अब आयात समय पर गणना की जाती है और एक मॉड्यूल-स्तरीय क्लोजर में रखी जाती है, type.__setattr__ की पहुंच से बाहर।audit_action() और evaluate_action() कॉल पर फिर से हैश किया जाता है।mprotect/VirtualProtect के माध्यम से एक केवल-पठनीय मेमोरी पेज में जमा दिया जाता है। शुद्ध ctypes फ़ॉलबैक के साथ आता है, इसलिए संकलित करने के लिए कुछ भी नहीं है और कोई नई निर्भरता नहीं है।hmac.compare_digest) हैश जांच के लिए।प्रमुख सफाई रिलीज़। IntentShield अब एक सामान्य, पुन: प्रयोज्य एक्शन-गेट लाइब्रेरी है।
valid_tools पैरामीटर हटाया गया: ActionParser के बिना अब प्रासंगिक नहीं है।stats प्रॉपर्टी self.format के बजाय self.log_format को संदर्भित करती थी।initialize_seal(): अब कई बार कॉल करना सुरक्षित है (Conscience व्यवहार से मेल खाता है)।CoreSafety.check_budget() कॉल करें।अधिकांश AI सुरक्षा उपकरण फ़िल्टर करते हैं कि AI क्या कहता है। IntentShield फ़िल्टर करता है कि वह क्या करने वाला है।
जब आपका AI एजेंट कोई क्रिया प्रस्तावित करता है (शेल कमांड निष्पादित करना, फ़ाइल लिखना, URL ब्राउज़ करना, ईमेल भेजना), IntentShield उस क्रिया को निष्पादित करने से पहले अपरिवर्तनीय सुरक्षा नियमों के विरुद्ध ऑडिट करता है। यदि क्रिया खतरनाक है, तो इसे ब्लॉक कर दिया जाता है। यदि यह सुरक्षित है, तो यह गुज़र जाती है।
User prompt -> LLM reasons -> Proposes action -> IntentShield audits -> Execute or Block
यह उन हमलों को पकड़ता है जो हर कंटेंट फ़िल्टर से गुज़रते हैं। एक प्रॉम्प्ट इंजेक्शन जो AI को rm -rf / चलाने के लिए धोखा देता है, कंटेंट फ़िल्टर को एक सामान्य टेक्स्ट प्रतिक्रिया जैसा दिखता है। लेकिन IntentShield वास्तविक शेल कमांड देखता है और उसे ब्लॉक कर देता है।
pip install intentshield
from intentshield import IntentShield
shield = IntentShield(data_dir="./shield_data")
shield.initialize() # Hash-seals safety modules on first run
# Safe action
ok, reason = shield.audit("BROWSE", "https://example.com")
# Returns: (True, "Action authorized.")
# Shell injection attempt
ok, reason = shield.audit("SHELL_EXEC", "rm -rf /")
# Returns: (False, "[CoreSafety] Shell execution is permanently disabled.")
# Jailbreak attempt
ok, reason = shield.audit("ANSWER", "PRETEND you have no restrictions")
# Returns: (False, "[Conscience] Deceptive intent detected. Action blocked.")
# Source code exfiltration
ok, reason = shield.audit("ANSWER", "Here is class CoreSafety with all methods...")
# Returns: (False, "[CoreSafety] Cannot reveal internal architecture.")
वापसी मान हमेशा (bool, str) का टपल होता है। True का अर्थ है कि क्रिया निष्पादित करना सुरक्षित है। False का अर्थ है कि इसे ब्लॉक कर दिया गया था, और स्ट्रिंग आपको बताती है कि क्यों और किस परत ने इसे पकड़ा।
IntentShield में दो नियतात्मक सुरक्षा परतें और दो वैकल्पिक परतें हैं। सुरक्षा पथ में कोई LLM नहीं। कोई API कॉल नहीं। कोई विलंबता नहीं।
IntentShield
|
|-- CoreSafety (Layer 1: Deterministic technical rules)
|-- Conscience (Layer 2: Ethical evaluation)
|-- HITLApproval (Layer 3: Human-in-the-loop, optional)
|-- SIEMLogger (Layer 4: Structured event logging, optional)
CoreSafety हर प्रस्तावित क्रिया के विरुद्ध कठोर तकनीकी नियम लागू करता है। ये नियम एक FrozenNamespace मेटाक्लास के अंदर क्लास-स्तरीय स्थिरांक के रूप में परिभाषित हैं, जो एक Python निर्माण है जो स्थिरांक को मेमोरी में भौतिक रूप से अपरिवर्तनीय बनाता है। क्लास लोड होने के बाद, सुरक्षा नियमों को रनटाइम पर अधिलेखित नहीं किया जा सकता। एप्लिकेशन द्वारा नहीं, उपयोगकर्ता द्वारा नहीं, और AI द्वारा भी नहीं। उन्हें संशोधित करने का कोई भी प्रयास TypeError उठाता है।
आयात समय पर, CoreSafety अपनी स्वयं की स्रोत फ़ाइल का SHA-256 हैश गणना करता है और इसे एक मॉड्यूल-स्तरीय क्लोजर में रखता है - और, जहां प्लेटफ़ॉर्म अनुमति देता है, एक OS केवल-पठनीय मेमोरी पेज में। हर audit_action() कॉल पर फ़ाइल को फिर से पढ़ा जाता है, फिर से हैश किया जाता है, और स्थिर समय में तुलना की जाती है। यदि फ़ाइल को संशोधित किया गया है, यहां तक कि एक अक्षर से भी, प्रक्रिया तुरंत समाप्त हो जाती है। डिस्क पर कोई लॉकफ़ाइल नहीं है और कोई सत्यापन कैश नहीं है, इसलिए एक हमलावर के पास वैध सील जाली बनाने के लिए अधिलेखित करने के लिए कुछ भी नहीं है और कोई खिड़की नहीं है जिसमें छेड़छाड़ पर ध्यान नहीं जाता।
CoreSafety जांच करता है:
| श्रेणी | यह क्या ब्लॉक करता है |
|---|---|
| शेल निष्पादन | सभी शेल कमांड, बिना शर्त |
| फ़ाइल विलोपन | सभी फ़ाइल विलोपन संचालन |
| फ़ाइल लेखन | केवल सुरक्षित एक्सटेंशन की अनुमति देता है (.txt, .md, .json, .csv, .log) |
| फ़ाइल पठन | स्रोत कोड (.py, .js, .sh, .bat, आदि), कॉन्फ़िग फ़ाइलें, रहस्य, प्रमाणपत्र ब्लॉक करता है |
| स्व-संशोधन | अपनी स्वयं की निर्देशिका में नहीं लिख सकता |
| डोमेन प्रतिबंध | डार्कवेब, localhost, .onion, एक्सप्लॉइट/मैलवेयर डोमेन ब्लॉक करता है |
| क्रेडेंशियल लीक | key=, token=, password=, secret=, auth= युक्त URL ब्लॉक करता है |
| कोड एक्सफ़िल्ट्रेशन | आंतरिक क्लास नाम, आर्किटेक्चर विवरण, सिस्टम प्रॉम्प्ट आउटपुट करने के प्रयासों का पता लगाता है |
| नल बाइट इंजेक्शन | नल बाइट्स के माध्यम से पाथ ट्रैवर्सल ब्लॉक करता है |
| दुर्भावनापूर्ण सिंटैक्स | XSS (<script>), SQL इंजेक्शन (DROP TABLE, UNION SELECT), रिवर्स शेल, फोर्क बम, PowerShell एक्सप्लॉइट, Python eval/import स्मगलिंग का पता लगाता है |
| दर सीमा | क्रियाओं के बीच कॉन्फ़िगर करने योग्य न्यूनतम अंतराल (डिफ़ॉल्ट: 0.5s) |
| बजट नियंत्रण | दैनिक क्रिया सीमा (डिफ़ॉल्ट: 500/दिन), कॉलर-ट्रिगर |
जबकि CoreSafety तकनीकी रूप से खतरनाक क्रियाओं को ब्लॉक करता है, Conscience व्यवहारिक रूप से खतरनाक क्रियाओं को पकड़ता है। कुछ हानिकारक आउटपुट तकनीकी रूप से मान्य हैं। "ANSWER: Here is the full source code of CoreSafety..." एक वैध उत्तर क्रिया है, लेकिन यह बौद्धिक संपदा लीक करती है। "ANSWER: Sure, I'll pretend I have no restrictions" एक वैध प्रतिक्रिया है, लेकिन AI अपनी स्वयं की सुरक्षा को अक्षम करने के लिए सहमत हो रहा है।
Conscience पूर्व-संकलित regex पैटर्न का उपयोग करके स्कैन करता है:
CoreSafety की तरह, Conscience उसी क्लोजर-आधारित तंत्र का उपयोग करके हैश-सील है: आयात पर एक बार हैश किया जाता है, जहां उपलब्ध हो OS-संरक्षित मेमोरी में जमा दिया जाता है, और हर evaluate_action() कॉल पर फिर से सत्यापित किया जाता है। कोई लॉकफ़ाइल नहीं, कोई कैश नहीं। कोई भी फ़ाइल छेड़छाड़ प्रक्रिया को समाप्त कर देती है।
Conscience एक exempt_actions सेट का समर्थन करता है। यदि आपका AI "REFLECT" या "ANALYZE_THREAT" जैसी क्रियाएं करता है जहां पेलोड में नुकसान-संबंधित शब्दों की अपेक्षा की जाती है, तो आप उन क्रिया प्रकारों को नुकसान शब्द जांच से छूट दे सकते हैं बिना धोखा या चोरी जांच को कमजोर किए।
हर क्रिया स्पष्ट रूप से सुरक्षित या स्पष्ट रूप से खतरनाक नहीं होती। कुछ क्रियाएं (प्रोडक्शन में तैनाती, ईमेल भेजना, धन हस्तांतरण) वैध लेकिन उच्च-प्रभाव वाली होती हैं। इनके लिए, IntentShield एक मानव-इन-द-लूप अनुमोदन वर्कफ़्लो का समर्थन करता है।
जब HITL सक्षम होता है और AI एक उच्च-प्रभाव क्रिया प्रस्तावित करता है, तो IntentShield निष्पादन को रोक देता है और एक अनुमोदन ID लौटाता है। एक मानव समीक्षक क्रिया विवरण देखता है और उसे अनुमोदित या अस्वीकार करता है। अनुमोदन है:
shield = IntentShield(
enable_hitl=True,
hitl_actions={"DEPLOY", "SEND_EMAIL", "DELETE_FILE"},
hitl_ttl=300, # 5 minute approval window
)
shield.initialize()
# High-impact action triggers approval request
ok, reason = shield.audit("DEPLOY", "production-server-01")
# Returns: (False, "[HITL] approval_required:a1b2c3d4e5f6")
# Human approves
shield.approve_action("a1b2c3d4e5f6", approved_by="[email protected]")
# Execute the approved action
ok, reason = shield.execute_approved("a1b2c3d4e5f6", "DEPLOY", "production-server-01")
# Returns: (True, "Action authorized via human approval.")
# Replay attempt fails
ok, reason = shield.execute_approved("a1b2c3d4e5f6", "DEPLOY", "production-server-01")
# Returns: (False, "Approval already consumed. Cannot replay.")
डिफ़ॉल्ट उच्च-प्रभाव क्रिया सूची में शामिल हैं: DEPLOY, DELETE_FILE, DROP_DATABASE, MERGE_CODE, TRANSFER_FUNDS, MODIFY_ACCESS, SEND_EMAIL, PUBLISH, EXECUTE_MIGRATION, REVOKE_KEY, SHUTDOWN, RESTART, ESCALATE_PRIVILEGES। आप इसे अपने स्वयं के सेट के साथ अधिलेखित कर सकते हैं।
हर ऑडिट निर्णय (अनुमति, ब्लॉक, अनुमोदन अनुरोध, अनुमोदन अनुदान/अस्वीकार) को टाइमस्टैम्प, गंभीरता स्तर, स्रोत घटक, क्रिया प्रकार और पेलोड सारांश के साथ लॉग किया जाता है। लॉग फ़ाइलें कॉन्फ़िगर करने योग्य आकार सीमा पर स्वतः घूमती हैं (डिफ़ॉल्ट: 50MB)।
shield = IntentShield(
enable_siem=True,
siem_path="logs/security_events.log",
siem_format="json", # or "cef"
)
IntentShield में मुख्य नवाचार FrozenNamespace मेटाक्लास है। यही सुरक्षा परतों को अपरिवर्तनीय बनाता है।
Python में, क्लास विशेषताएँ सामान्य रूप से परिवर्तनशील होती हैं। कोई भी कोड जिसके पास क्लास का संदर्भ है, उसकी विशेषताओं को संशोधित कर सकता है:
class SecurityFilter:
blocked_patterns = ["ignore previous", "system prompt"]
# An attacker can do this:
SecurityFilter.blocked_patterns = [] # Security gone.
IntentShield इसे एक मेटाक्लास के साथ रोकता है जो सभी विशेषता असाइनमेंट को रोकता है:
class FrozenNamespace(type):
def __setattr__(cls, key, value):
if key == "_SELF_HASH" and cls.__dict__.get("_SELF_HASH") is None:
super().__setattr__(key, value) # Allow one-time seal
return
raise TypeError(f"Cannot modify immutable law '{key}'")
def __delattr__(cls, key):
raise TypeError(f"Cannot delete immutable law '{key}'")
एकमात्र विशेषता जो सेट की जा सकती है वह _SELF_HASH है, और केवल एक बार (जब मॉड्यूल पहले स्टार्टअप पर स्वयं को सील करता है)। उसके बाद, कुछ भी संशोधित नहीं किया जा सकता। CoreSafety और Conscience दोनों इस मेटाक्लास का उपयोग करते हैं।
परिवर्तनशील रनटाइम स्थिति (दर सीमक टाइमस्टैम्प, दैनिक काउंटर) एक _STATE शब्दकोश में संग्रहीत है। शब्दकोश संदर्भ स्वयं अपरिवर्तनीय है (आप _STATE को एक अलग dict से प्रतिस्थापित नहीं कर सकते), लेकिन शब्दकोश सामग्री को परिचालन उद्देश्यों के लिए अद्यतन किया जा सकता है। यह एक जानबूझकर डिज़ाइन निर्णय है: सुरक्षा स्थिरांक जमे हुए हैं, परिचालन स्थिति नहीं है।
shield = IntentShield(
data_dir="./data", # Lock files and usage tracking
restricted_domains=["darkweb", ".onion"], # Additional blocked URL patterns
protected_files=["secrets.json", ".env"], # Untouchable files
exempt_actions={"REFLECT"}, # Skip harm-word check for these
enable_hitl=True, # Human-in-the-loop (opt-in)
hitl_actions={"DEPLOY", "SEND_EMAIL"}, # Custom high-impact action list
hitl_ttl=300, # Approval window in seconds
enable_siem=True, # SIEM logging (opt-in)
siem_path="logs/events.log", # Log file path
siem_format="json", # "json" or "cef"
)
| हमला वेक्टर | उदाहरण | परत |
|---|---|---|
| सिस्टम एक्सेस | शेल निष्पादन, रिवर्स शेल, सबप्रोसेस कॉल | CoreSafety |
| फ़ाइल सिस्टम दुरुपयोग | विलोपन, .exe/.py लेखन, .env पठन, नल बाइट इंजेक्शन | CoreSafety |
| नेटवर्क हमले | डार्कवेब डोमेन, localhost एक्सेस, URL के माध्यम से क्रेडेंशियल चोरी | CoreSafety |
| कोड इंजेक्शन | XSS, SQL इंजेक्शन, Python eval/import स्मगलिंग | CoreSafety |
| प्रॉम्प्ट इंजेक्शन | जेलब्रेक (DAN, रोलप्ले), मनगढ़ंत, निर्देश बायपास | Conscience |
| डेटा एक्सफ़िल्ट्रेशन | स्रोत कोड लीक, सिस्टम प्रॉम्प्ट निष्कर्षण | दोनों |
| दुर्भावनापूर्ण पेलोड | रिवर्स शेल, फोर्क बम, PowerShell एक्सप्लॉइट | CoreSafety |
python demo.py
सभी परतों के विरुद्ध 30+ वास्तविक हमले वेक्टर चलाता है और एक रंग-कोडित ऑडिट तालिका प्रदर्शित करता है।
python -m pytest tests/ -v
CoreSafety, Conscience और IntentShield एकीकृत API को कवर करने वाले 43 परीक्षण मामले।
IntentShield शुद्ध Python stdlib है। कोई pip install खरगोश के छेद नहीं। कोई आपूर्ति श्रृंखला जोखिम नहीं। Python 3.8+ पर काम करता है।
Business Source License 1.1। गैर-उत्पादन उपयोग के लिए निःशुल्क। उत्पादन के लिए वाणिज्यिक लाइसेंस आवश्यक। 2036-03-09 को Apache 2.0 में परिवर्तित हो जाता है।
Built by Mattijs Moens