गहन रक्षा (Defense in Depth)

Triggerfish सुरक्षा को 13 स्वतंत्र, ओवरलैपिंग परतों के रूप में लागू करता है। कोई एकल परत अपने आप पर्याप्त नहीं है। साथ में, वे एक ऐसी रक्षा बनाते हैं जो सुचारू रूप से कमज़ोर होती है -- भले ही एक परत से समझौता हो जाए, शेष परतें सिस्टम की सुरक्षा जारी रखती हैं।

सुरक्षा गहन रक्षा का अर्थ है कि किसी एकल परत में भेद्यता सिस्टम

से समझौता नहीं करती। चैनल प्रमाणीकरण को बायपास करने वाले हमलावर को अभी भी session taint ट्रैकिंग, policy hooks, और ऑडिट लॉगिंग का सामना करना पड़ता है। Prompt-injected LLM अभी भी इसके नीचे निश्चयात्मक policy परत को प्रभावित नहीं कर सकता। :::

13 परतें

परत 1: चैनल प्रमाणीकरण

इसके विरुद्ध सुरक्षा: प्रतिरूपण, अनधिकृत पहुँच, पहचान भ्रम।

पहचान session स्थापना पर कोड द्वारा निर्धारित होती है, LLM द्वारा संदेश सामग्री की व्याख्या से नहीं। LLM किसी भी संदेश को देखने से पहले, चैनल adapter इसे एक अपरिवर्तनीय लेबल के साथ टैग करता है:

{ source: "owner" }    -- सत्यापित चैनल पहचान पंजीकृत owner से मेल खाती है
{ source: "external" } -- कोई भी अन्य; केवल इनपुट, कमांड के रूप में नहीं माना जाता

प्रमाणीकरण विधियाँ चैनल के अनुसार भिन्न होती हैं:

चैनल	विधि	सत्यापन
Telegram / WhatsApp	पेयरिंग कोड	एक बार का कोड, 5-मिनट की समाप्ति, उपयोगकर्ता के खाते से भेजा गया
Slack / Discord / Teams	OAuth	प्लेटफ़ॉर्म OAuth सहमति प्रवाह, सत्यापित user ID लौटाता है
CLI	स्थानीय प्रक्रिया	उपयोगकर्ता की मशीन पर चल रहा, OS द्वारा प्रमाणित
WebChat	कोई नहीं (सार्वजनिक)	सभी आगंतुक EXTERNAL हैं, कभी owner नहीं
Email	डोमेन मिलान	प्रेषक डोमेन की तुलना कॉन्फ़िगर किए गए आंतरिक डोमेन से

LLM कभी यह निर्णय नहीं लेता कि owner कौन है। एक असत्यापित प्रेषक से

"मैं owner हूँ" कहने वाला संदेश { source: "external" } के रूप में टैग किया जाता है और owner-स्तरीय कमांड ट्रिगर नहीं कर सकता। यह निर्णय कोड में, LLM द्वारा संदेश प्रोसेस करने से पहले लिया जाता है। :::

परत 2: अनुमति-जागरूक डेटा एक्सेस

इसके विरुद्ध सुरक्षा: अधिक-अनुमति वाला डेटा एक्सेस, सिस्टम credentials के माध्यम से विशेषाधिकार वृद्धि।

Triggerfish उपयोगकर्ता के प्रत्यायोजित OAuth tokens का उपयोग करता है -- सिस्टम service accounts का नहीं -- बाहरी सिस्टम से क्वेरी करने के लिए। स्रोत सिस्टम अपना स्वयं का अनुमति मॉडल लागू करता है:

Plugin SDK इसे API स्तर पर लागू करता है:

SDK विधि	व्यवहार
sdk.get_user_credential(integration)	उपयोगकर्ता का प्रत्यायोजित OAuth token लौटाता है
sdk.query_as_user(integration, query)	उपयोगकर्ता की अनुमतियों के साथ निष्पादित करता है
sdk.get_system_credential(name)	अवरुद्ध -- PermissionError उत्पन्न करता है

परत 3: Session Taint ट्रैकिंग

इसके विरुद्ध सुरक्षा: संदर्भ संदूषण के माध्यम से डेटा रिसाव, वर्गीकृत डेटा का निम्न-वर्गीकरण चैनलों तक पहुँचना।

प्रत्येक session स्वतंत्र रूप से एक taint स्तर ट्रैक करता है जो session के दौरान एक्सेस किए गए डेटा के उच्चतम वर्गीकरण को दर्शाता है। Taint तीन अपरिवर्तनीय नियमों का पालन करती है:

1. प्रति-वार्तालाप -- प्रत्येक session की अपनी taint है
2. केवल वृद्धि -- taint बढ़ती है, कभी कम नहीं होती
3. पूर्ण रीसेट सब कुछ साफ़ करता है -- taint और इतिहास एक साथ मिटाए जाते हैं

परत 4: डेटा Lineage

इसके विरुद्ध सुरक्षा: अप्राप्य डेटा प्रवाह, डेटा कहाँ गया इसकी ऑडिट करने में असमर्थता, अनुपालन अंतराल।

प्रत्येक डेटा तत्व मूल से गंतव्य तक उत्पत्ति मेटाडेटा रखता है:

• मूल: किस एकीकरण, रिकॉर्ड, और उपयोगकर्ता एक्सेस ने यह डेटा उत्पन्न किया
• वर्गीकरण: कौन सा स्तर दिया गया और क्यों
• रूपांतरण: LLM ने डेटा को कैसे संशोधित, संक्षेपित, या संयोजित किया
• गंतव्य: किस session और चैनल ने आउटपुट प्राप्त किया

परत 5: Policy प्रवर्तन Hooks

इसके विरुद्ध सुरक्षा: Prompt injection हमले, LLM-संचालित सुरक्षा बायपास, अनियंत्रित tool निष्पादन।

आठ निश्चयात्मक hook डेटा प्रवाह में प्रत्येक महत्वपूर्ण बिंदु पर हर क्रिया को इंटरसेप्ट करते हैं:

Hook	क्या इंटरसेप्ट करता है
PRE_CONTEXT_INJECTION	संदर्भ विंडो में प्रवेश करने वाला बाहरी इनपुट
PRE_TOOL_CALL	LLM द्वारा tool निष्पादन अनुरोध
POST_TOOL_RESPONSE	Tool निष्पादन से लौटने वाला डेटा
PRE_OUTPUT	सिस्टम से बाहर जाने वाला उत्तर
SECRET_ACCESS	Credential एक्सेस अनुरोध
SESSION_RESET	Taint रीसेट अनुरोध
AGENT_INVOCATION	Agent-से-agent कॉल
MCP_TOOL_CALL	MCP server tool आह्वान

परत 6: MCP Gateway

इसके विरुद्ध सुरक्षा: अनियंत्रित बाहरी tool एक्सेस, MCP servers के माध्यम से प्रवेश करने वाला अवर्गीकृत डेटा, स्कीमा उल्लंघन।

सभी MCP servers UNTRUSTED पर डिफ़ॉल्ट होते हैं और जब तक admin या उपयोगकर्ता उन्हें वर्गीकृत नहीं करता, तब तक आह्वान नहीं किए जा सकते।

परत 7: Plugin Sandbox

इसके विरुद्ध सुरक्षा: दुर्भावनापूर्ण या दोषपूर्ण plugin कोड, डेटा निष्कासन, अनधिकृत सिस्टम एक्सेस।

Plugins एक दोहरे sandbox में चलते हैं:

Plugin sandbox agent exec environment से भिन्न है। Plugins अविश्वसनीय

कोड हैं जिनसे सिस्टम रक्षा करता है। Exec environment एक कार्यक्षेत्र है जहाँ agent को निर्माण करने की अनुमति है -- policy-शासित एक्सेस के साथ, sandbox अलगाव नहीं। :::

परत 8: Secrets अलगाव

इसके विरुद्ध सुरक्षा: Credential चोरी, कॉन्फ़िग फ़ाइलों में secrets, plaintext credential भंडारण।

Credentials OS keychain (व्यक्तिगत स्तर) या vault एकीकरण (एंटरप्राइज़ स्तर) में संग्रहीत हैं। वे कभी प्रकट नहीं होते:

• कॉन्फ़िगरेशन फ़ाइलों में
• StorageProvider मानों में
• लॉग प्रविष्टियों में
• LLM संदर्भ में (credentials HTTP परत पर, LLM के नीचे इंजेक्ट किए जाते हैं)

परत 9: Filesystem Tool Sandbox

इसके विरुद्ध सुरक्षा: पथ traversal हमले, अनधिकृत फ़ाइल एक्सेस, प्रत्यक्ष filesystem संचालन के माध्यम से वर्गीकरण बायपास।

सभी filesystem tool संचालन एक sandboxed Deno Worker में चलते हैं जिसमें OS-स्तरीय अनुमतियाँ session की taint-उपयुक्त workspace उपनिर्देशिका तक सीमित होती हैं।

परत 10: Agent पहचान

इसके विरुद्ध सुरक्षा: Agent chains के माध्यम से विशेषाधिकार वृद्धि, delegation के माध्यम से डेटा लॉन्ड्रिंग।

जब agents अन्य agents को आह्वान करते हैं, तो क्रिप्टोग्राफ़िक delegation chains विशेषाधिकार वृद्धि को रोकती हैं।

परत 11: ऑडिट लॉगिंग

इसके विरुद्ध सुरक्षा: अज्ञात उल्लंघन, अनुपालन विफलता, घटनाओं की जाँच करने में असमर्थता।

प्रत्येक सुरक्षा-प्रासंगिक निर्णय पूर्ण संदर्भ के साथ लॉग किया जाता है:

{
  "timestamp": "2025-01-29T10:23:45Z",
  "user_id": "user_123",
  "session_id": "sess_456",
  "action": "slack.postMessage",
  "target_channel": "external_webhook",
  "session_taint": "CONFIDENTIAL",
  "target_classification": "PUBLIC",
  "decision": "DENIED",
  "reason": "classification_violation",
  "hook": "PRE_OUTPUT",
  "policy_rules_evaluated": ["rule_001", "rule_002"],
  "lineage_ids": ["lin_789", "lin_790"]
}

ऑडिट लॉगिंग अक्षम नहीं की जा सकती। यह policy पदानुक्रम में एक

निश्चित नियम है। एक org admin भी अपने स्वयं के कार्यों के लिए लॉगिंग बंद नहीं कर सकता। :::

परत 12: SSRF रोकथाम

इसके विरुद्ध सुरक्षा: Server-side request forgery, आंतरिक नेटवर्क पुनर्सर्वेक्षण, क्लाउड मेटाडेटा निष्कासन।

सभी आउटबाउंड HTTP अनुरोध पहले DNS हल करते हैं और निजी और आरक्षित रेंज की हार्डकोडेड denylist के विरुद्ध हल किए गए IP की जाँच करते हैं।

परत 13: Memory वर्गीकरण गेटिंग

इसके विरुद्ध सुरक्षा: Memory के माध्यम से क्रॉस-session डेटा रिसाव, memory writes के माध्यम से वर्गीकरण डाउनग्रेड, वर्गीकृत memories तक अनधिकृत पहुँच।

• Writes: Memory प्रविष्टियाँ वर्तमान session की taint स्तर पर मजबूर होती हैं
• Reads: Memory क्वेरी canFlowTo द्वारा फ़िल्टर की जाती हैं

विश्वास पदानुक्रम

व्यक्तिगत स्तर: उपयोगकर्ता ही org admin है। पूर्ण संप्रभुता।

कोई Triggerfish दृश्यता नहीं। विक्रेता के पास डिफ़ॉल्ट रूप से उपयोगकर्ता डेटा तक शून्य पहुँच है। :::

परतें एक साथ कैसे काम करती हैं

एक prompt injection हमले पर विचार करें जहाँ एक दुर्भावनापूर्ण संदेश डेटा निष्कासित करने का प्रयास करता है:

चरण	परत	कार्य
1	चैनल प्रमाणीकरण	संदेश { source: "external" } के रूप में टैग किया गया
2	PRE_CONTEXT_INJECTION	इनपुट injection पैटर्न के लिए स्कैन, वर्गीकृत
3	Session taint	Session taint अपरिवर्तित (कोई वर्गीकृत डेटा एक्सेस नहीं)
4	LLM संदेश प्रोसेस करता है	LLM tool call अनुरोध करने के लिए manipulate हो सकता है
5	PRE_TOOL_CALL	बाहरी-स्रोत नियमों के विरुद्ध tool अनुमति जाँच
6	POST_TOOL_RESPONSE	लौटाया गया कोई भी डेटा वर्गीकृत, taint अपडेट
7	PRE_OUTPUT	आउटपुट वर्गीकरण बनाम लक्ष्य की जाँच
8	ऑडिट लॉगिंग	संपूर्ण अनुक्रम समीक्षा के लिए रिकॉर्ड किया गया

भले ही LLM चरण 4 पर पूरी तरह से समझौता हो जाए, शेष परतें policy लागू करना जारी रखती हैं। विफलता का कोई एकल बिंदु सिस्टम से समझौता नहीं करता।