rappidAI Ghost. Sicherheit im Hintergrund.
Eine integrierte Security-Runtime für autonome KI-Agenten. Ghost bündelt Isolation, Täuschung, Prompt-Injection-Signale, eng begrenzte Freigaben, Laufzeitgrenzen und Nachweise in einem einfachen Ausführungsablauf.
ghost run -- sh -c 'cat ~/.aws/credentials'
ghost inspect latest
ghost graph latest
ghost incidents latestv0.3.0 · Veröffentlicht · Experimentell · Apache-2.0
Ein Befehl. Mehrere Sicherheitsebenen.
Ghost führt Agenten in einer kontrollierten Laufzeitumgebung aus. Es prüft vorab die Umgebung, isoliert den Prozess und hält geschützte Ressourcen des Hosts außer Reichweite. Außerdem untersucht Ghost ausgewählte nicht vertrauenswürdige Anweisungsquellen, setzt Grenzen für Netzwerk und Ressourcen durch und zeichnet Nachweise für die spätere Prüfung auf.
Für Entwickler, Sicherheitsfachleute und Forschende, die wollen, dass autonome Agenten nützlich bleiben, ohne unbemerkt weitreichendes Vertrauen zu erben. Der Großteil der Komplexität bleibt hinter ghost run verborgen; ausführlichere Nachweise liefern bei Bedarf inspect, graph und incidents.
Zum EinstiegALLOW. DENY. SHADOW. ASK.
Die Durchsetzung zur Laufzeit ist deterministisch und überlässt die Autorisierung nie einem LLM. Der Prompt-Injection Guard liefert begrenzte Sicherheitssignale und Vertrauenskontext. Ein Erkennungsergebnis kann aber nie eine verbotene Operation sicher machen oder die Isolation abschalten.
ALLOW
Die erlaubte echte Ressource oder das exakt angegebene Ziel ist unter der aktiven Richtlinie verfügbar.
DENY
Der Zugriff wird verweigert. Harte Grenzen der Laufzeitumgebung, des Hosts und der Abschottung lassen sich nicht per Freigabe aufheben.
SHADOW
Ghost stellt kontrolliertes synthetisches Material bereit, während die zugehörige geschützte Ressource des Hosts isoliert bleibt.
ASK
Nur bei ausdrücklich konfigurierten Zielen kann Ghost einen einzelnen, exakt bestimmten Vorgang für eine eng gefasste Nutzerentscheidung anhalten. Ist keine Interaktion möglich oder ist sie fehlerhaft, gilt DENY.
Warum ein Köder mehr verraten kann als eine Ablehnung.
Angenommen, ein Prozess versucht, ~/.aws/credentials zu öffnen. Mit der Standardrichtlinie Shadow Home erhält er eine frisch erzeugte, synthetische Datei mit Zugangsdaten in /home/ghost – nicht die Zugangsdaten des Host-Nutzers. Ghost prüft die echte Datei nicht, kopiert sie nicht und leitet keine Werte aus ihr ab. Mit den synthetischen AWS-Werten, der funktionslosen Datei im Format eines SSH-Schlüssels und dem generischen .env-Köder ist keine Anmeldung bei echten Diensten möglich.
01
Vorbereiten
Session-eigene Köder anlegen und vor dem Start des Befehls bestätigen, dass der separate inotify-Sentinel sie überwacht.
02
Beobachten
DECOY_ACCESS aufzeichnen, wenn für eine ausdrücklich als Köder festgelegte Datei ein open/access-Ereignis beobachtet wird.
03
Abschotten
Mit on_decoy_access.network: deny die Abschottung melden und spätere Allow-Entscheidungen des Gateways über die Sentinel-Warteschlange absichern.
04
Prüfen
Über Ereignis-Zeitleiste, Herkunftsgraph und Vorfälle die belegte Abfolge samt Verweisen auf die Nachweise nachvollziehen.
Ein Zugriff auf einen Köder belegt ein Dateiereignis – weder eine böswillige Absicht noch den Abfluss von Zugangsdaten. Die Abschottung widerruft keine bereits autorisierten, aufgebauten Verbindungen.
v0.3.0 · 2026-09-21
Mit v0.3.0 wird Ghost zu einer integrierten Security-Runtime für Agenten.
Das Release behält den Ablauf mit zwei Befehlen bei und ergänzt darunter Kontext, Freigaben, Laufzeitschutz und belastbarere Nachweise. Die bestehende Isolation und Netzwerkgrenze aus v0.2 bleiben maßgeblich.
| Integrierter Prompt-Injection Guard | Vor PROCESS_START untersucht Ghost begrenzte, an Agenten gerichtete Stellen im Workspace wie AGENTS.md, Dokumentation und ausgewählte Skripte. Befunde bestehen aus minimierten Signalen zu Regel, Kategorie und Hash, nicht aus kopierten Dokumentinhalten. Falsch-positive wie falsch-negative Ergebnisse bleiben möglich. Grenzen der Implementierung nachlesen |
|---|---|
| Vertrauenskontext ohne erfundene Kausalität | Ausgewählte Quellen im Workspace werden deterministisch eingestuft und im Herkunftsnachweis als beobachteter oder abgeleiteter Kontext verknüpft. Ghost kann rekonstruieren, dass verdächtige Anweisungen späteren Aktivitäten vorausgingen – ohne zu behaupten, dass der Inhalt den Agenten zum Handeln gebracht hat. Grenzen der Implementierung nachlesen |
| ALLOW / DENY / SHADOW / ASK | Für exakt konfigurierte HTTP/HTTPS-Ziele kann eine Entscheidung zwischen ALLOW_ONCE, ALLOW_SESSION und DENY erforderlich sein. Eine Freigabe gilt nur innerhalb der Session und exakt für Schema, Host, Port und Methode; Abschottung und fest gesperrte Ziele haben immer Vorrang. Grenzen der Implementierung nachlesen |
| Integrierter Ressourcenschutz zur Laufzeit | Der Agent und alle untergeordneten Prozesse laufen mit verbindlichen Obergrenzen für Arbeitsspeicher, CPU, PIDs, temporären Speicher und Sessiondauer. In v0.3 gelten standardmäßig 2 GiB RAM, eine CPU, 256 Prozesse/Threads, 64 MiB /tmp und eine Frist von einer Stunde, mit begrenztem Beenden und Aufräumen. Grenzen der Implementierung nachlesen |
| Automatische Sicherheitsprüfung vorab und Zusammenfassungen | ghost run prüft vor PROCESS_START Docker, Identität, Richtlinie, Workspace und den zur Session gehörenden Zustand. Erfolgreiche Prüfungen laufen ohne Ausgabe; sicherheitsrelevante Sessions enden mit knappen Zusammenfassungen, die aus den gespeicherten Nachweisen abgeleitet sind. Grenzen der Implementierung nachlesen |
| Mit Angriffstests validiertes Release | Das abschließende Audit behob Randfälle bei Freigaben, Abschottung, HTTP-Framing, dem Abschluss der Nachweise, der Wiederherstellung und schnellen OOM-Abbrüchen von Kindprozessen. GhostBench umfasst jetzt 25 benannte Szenarien; das Release-Gate verzeichnete 25 PASS, 0 FAIL und 0 SKIP. Grenzen der Implementierung nachlesen |
Eine Laufzeitumgebung. Integrierter Sicherheitskontext.
Ghost führt Beobachtungen im Workspace, Richtlinienentscheidungen, Durchsetzung zur Laufzeit und Nachweise durch einen gemeinsamen Session-Lebenszyklus. Prompt-Befunde ergänzen den Kontext; Richtlinie und harte Laufzeitgrenzen bleiben maßgeblich. Aus gespeicherten Ereignissen entstehen Herkunftsnachweise, Vorfälle und Zusammenfassungen.
- Isolation
- In kurzlebigen Docker-Sessions sind der gewählte Workspace und ein synthetisches Home-Verzeichnis sichtbar, nicht aber das echte Home-Verzeichnis, der Docker-Socket oder die Ghost-Datenbank.
- Prompt- und Vertrauenskontext
- Ein begrenzter Guard prüft vor dem Start unterstützte Anweisungsquellen und speichert inhaltlich minimierte Befunde sowie deterministischen Vertrauenskontext. Er ist eine Signalebene, keine Instanz für Autorisierung.
- Richtlinien
- Eine strikte Validierung von ghost.yaml sorgt für deterministische ALLOW-, DENY- und SHADOW-Entscheidungen sowie bewusst eng gefasste ASK-Entscheidungen. Abschottung und hart verbotene Ziele haben Vorrang vor Freigaben.
- Täuschung
- Frisch erzeugte synthetische AWS-, SSH- und .env-Ressourcen bieten beobachtbare Alternativen, ohne echte Zugangsdaten zu lesen oder Werte daraus abzuleiten.
- Netzwerk und Abschottung
- Ausgehender HTTP/HTTPS-Verkehr mit exaktem Hostnamenabgleich läuft über ein Gateway pro Session. Es validiert die aufgelöste Adresse und prüft vor der Autorisierung erneut den aktuellen Stand der Abschottung.
- Laufzeitschutz
- Verbindliche, per cgroup durchgesetzte Obergrenzen für Arbeitsspeicher, CPU und PIDs, ein begrenztes /tmp, schreibgeschützte Root-Dateisysteme und eine Frist pro Session beschränken den Agenten und seine untergeordneten Prozesse.
- Nachweise
- SQLite speichert minimierte Session-Ereignisse und den Sicherheitszustand. Schlägt ein verpflichtender Nachweis fehl, blockiert Ghost (fail-closed), statt die Grenze unbemerkt aufzuweichen.
- Herkunft / Vorfälle
- Die deterministische Rekonstruktion unterscheidet Beobachtungen, abgeleitete Beziehungen und zeitliche Abfolge – ohne Absichten des Modells oder Kausalität zu erfinden.
- Menschliche Freigabe
- Bei ausdrücklich konfigurierten ASK-Zielen kann der Ablauf für eine eng gefasste Nutzerentscheidung anhalten; nicht interaktive, fehlerhafte oder abgelaufene Freigaben werden zu DENY.
- GhostBench
- 25 Szenarien im Release-Gate prüfen einzelne Eigenschaften sowie integrierte Ketten aus Prompt, SHADOW und Netzwerk, Freigabe, Timeout und Session-Isolation.
Ein Hostname allein reicht nicht.
HTTP ist auf Port 80 beschränkt, HTTPS CONNECT auf Port 443. Wer github.com erlaubt, erlaubt damit nicht automatisch api.github.com. Reine IP-Adressen, Wildcards, einteilige Namen und Namen für die lokale Nutzung wie host.docker.internal werden abgelehnt. Ausgehender IPv6-Verkehr zu Upstream-Servern wird nicht unterstützt und blockiert (fail-closed).
Optional: Nur den Abschnitt network in ghost.yaml ersetzen. Die Einstellung deny beibehalten, sofern kein begrenzter ausgehender Datenverkehr nötig ist.
network:
mode: allowlist
allow:
- github.com
ask:
- api.example.comDetails zu Namensauflösung und Abschottung
Jede zurückgegebene IPv4-Adresse muss die Validierung bestehen. Geprüft wird unter anderem auf nicht spezifizierte Adressen und das aktuelle Netz sowie auf private, Loopback-, Shared-, Link-Local-, Protokollzuweisungs-, Benchmarking-, Multicast- und reservierte Bereiche. Leere, fehlerhafte oder fehlgeschlagene DNS-Antworten werden ebenso abgelehnt wie Antworten, die erlaubte und verbotene Adressen mischen. Weil die Verbindung über die validierte numerische Adresse läuft, entfällt eine zweite Auflösung des Hostnamens. Jede neue Anfrage wird erneut geprüft. Ghost behauptet nicht, jede DNS-Rebinding-Technik oder jede Weiterleitung über einen freigegebenen Server auszuschließen.
Der Token/Ack-Fence bringt Anfragen in eine feste Reihenfolge zu Köderereignissen, die inotify bereits eingereiht hat. Eine wirklich gleichzeitige Anfrage, deren Barriere zuerst einsortiert wird, kann trotzdem noch erlaubt werden. Der Fence ist kein atomarer Widerruf auf Paketebene und kann weder eine bereits laufende HTTP-Antwort noch einen aufgebauten CONNECT-Tunnel beenden. Die interne Docker-Bridge bleibt eine lokale Verbindung; Dienste, die bewusst an diese Bridge gebunden sind, gehören zu den erreichbaren Zielen.
NetzwerksicherheitMit einem kontrollierten lokalen Lauf beginnen.
Mit Laufzeittests geprüfte Zielplattform des Release: Linux amd64 mit Docker Engine, funktionierender lokaler Docker-CLI samt Daemon und einer numerischen Host-UID/GID ungleich null. Binärdateien für Linux arm64 werden per Cross-Compiling erstellt und über Prüfsummen verifiziert. Für den Build aus dem Quellcode sind Git und Go 1.26.8 oder ein neueres unterstütztes Patch-Release nötig. Docker Desktop unter macOS ist für das Release nicht qualifiziert; die native Ausführung unter Windows wird nicht unterstützt.
01
1. Veröffentlichten Quellcode bauen
Der Tag wählt das veröffentlichte v0.3.0 statt des sich ständig ändernden Branches main. PATH wird für dieses Terminal gesetzt, damit die folgenden Befehle die soeben gebaute Binärdatei verwenden. Die geprüfte Revision des Release ist unten verlinkt.
git clone --branch v0.3.0 --depth 1 https://github.com/rappidAI-Research/rappid-ghost.git cd rappid-ghost go build -o bin/ghost ./cmd/ghost export PATH="$PWD/bin:$PATH" ghost version02
2. Ein frisches Demo-Projekt anlegen
Diese Befehle legen auf derselben Ebene das Verzeichnis ghost-demo an. ghost init erzeugt ghost.yaml, .ghost/ghost.db und .ghost/sessions/, ohne eine vorhandene Konfiguration zu überschreiben. .ghost/ gehört nicht in Git. Für ein echtes Projekt wird init stattdessen im Verzeichnis dieses Projekts ausgeführt.
mkdir -p ../ghost-demo cd ../ghost-demo ghost init ghost run -- echo "hello from ghost"03
3. Auf einen Köder zugreifen und Nachweise prüfen
Im Demo-Verzeichnis ausführen. Der Befehl cat liefert synthetische Inhalte. inspect zeigt die Zeitleiste der Session; graph und incidents rekonstruieren belegte Zusammenhänge. Beide akzeptieren auch --json. Das Trennzeichen -- ist für run erforderlich.
ghost run -- sh -c 'cat ~/.aws/credentials' ghost inspect latest ghost graph latest ghost incidents latest
Unter Linux geht es auch ohne Go: Das Release enthält Binärdateien für amd64 und arm64. Die heruntergeladene Binärdatei vor der Ausführung mit SHA256SUMS abgleichen.
Das fest vorgegebene Alpine-Image von Ghost ist bewusst minimal: Auf dem Host installierte Python-, Node- oder Agentenpakete sind darin nicht automatisch vorhanden. Fehlende Befehle schlagen fehl und werden nie ersatzweise auf dem Host ausgeführt. Der eingebundene Workspace ist für den Agenten bewusst sichtbar, und angehängte Programmausgabe wird nicht bereinigt. Secrets gehören deshalb nur dann dorthin, wenn der Agent darauf zugreifen soll.
GhostBench · v0.3.0
25 Szenarien. Integrierte Sicherheitsketten.
GhostBench ist eine reproduzierbare Testsuite für Sicherheitseigenschaften, kein Sicherheits-Score. Im Release-Gate von v0.3.0 liefen alle 25 verpflichtenden Szenarien unter Linux amd64 mit Docker erfolgreich durch – einschließlich integrierter Ketten aus Prompt, SHADOW und Netzwerk, aus Freigabe und Abschottung, mit Laufzeit-Timeout und über Session-Grenzen hinweg.
Dokumentiertes Ergebnis für v0.3.0 · 21. September 2026
PASS: 25 · FAIL: 0 · SKIP: 0
v0.3 deckt unter anderem ab: feindselige Prompt-Signale mit SHADOW-Zugriff und anschließender Netzwerksperre, Kontrolle von Fehlalarmen bei defensiver Dokumentation, fail-closed-Verhalten von ASK ohne Interaktion, Isolation einmaliger und gleichzeitiger Freigaben, Vorrang der Abschottung vor zwischengespeicherten Freigaben, Aufräumen nach einem Laufzeit-Timeout sowie integrierte Isolation zwischen Sessions.
ghost bench
ghost bench --require-all
ghost bench --scenario dynamic-containment--require-all endet sowohl bei FAIL als auch bei SKIP mit einem Fehlerstatus. Ohne Docker werden Docker-abhängige Fälle als SKIP gewertet, nicht als PASS. Die Demo dynamic-containment nutzt einen harmlosen lokalen HTTP-Testdienst in Docker; sie sendet keine Zugangsdaten an externe Dienste.
Alle 25 Szenario-IDs
- host-home-isolation
- shadow-credentials
- deny-sensitive-resource
- network-deny
- network-allowlist
- direct-egress-bypass
- dynamic-containment
- session-isolation
- fail-closed-runtime
- safe-baseline
- private-destination-blocked
- environment-isolation
- container-confinement
- concurrent-containment
- interrupted-session-recovery
- prompt-injection-detected
- prompt-guard-false-positive
- untrusted-content-provenance
- prompt-shadow-context
- approval-unavailable
- approval-once
- approval-containment-precedence
- concurrent-approval-once
- cross-session-security-isolation
- session-timeout
Was Ghost nicht garantiert.
| Docker bleibt Teil der Vertrauensbasis | Docker, sein Daemon, die OCI-Runtime, das fest vorgegebene Image und der Host-Kernel bleiben Teil der Trusted Computing Base. Ghost garantiert keinen Schutz vor jedem Container-Ausbruch und jeder Kernel-Schwachstelle. |
|---|---|
| Prompt-Befunde sind heuristisch | Der integrierte Guard kann Angriffe übersehen oder harmlose Texte markieren. Er versteht keine Absichten eines Modells und gewährt nie Zugriff, indem er Inhalte für sicher erklärt. |
| Belege zeigen keine Kausalität | Der Herkunftsnachweis unterscheidet beobachtete Ereignisse, abgeleitete Exposition und zeitliche FOLLOWED_BY-Beziehungen. Ghost beweist weder, dass verdächtige Inhalte späteres Verhalten verursacht haben, noch dass Daten abgeflossen sind. |
| Netzwerk- und Ressourcenkontrollen sind bewusst begrenzt | Ghost untersucht keine TLS-Inhalte, leitet kein allgemeines TCP/UDP über einen Proxy, unterstützt keinen ausgehenden IPv6-Verkehr zu Upstream-Servern, setzt kein Byte-Kontingent für Workspace und Nachweisspeicher durch und bietet keine hostweite, übergreifende Zulassungskontrolle (Admission Control). Bestehende Verbindungen werden nicht rückwirkend widerrufen. |
| Grenzen bei Host und Ausgaben bleiben wichtig | Im Lese-/Schreibmodus sind Änderungen am Workspace bewusst erlaubt, und angehängte Programmausgabe wird nicht bereinigt. Harte Ausfälle von Host oder Daemon können das Aufräumen oder das Erfassen von Nachweisen unterbrechen. 25 bestandene Szenarien belegen benannte Eigenschaften, keinen umfassenden Schutz vor Angriffen. |
Quellcode prüfen. Release ausprobieren.
v0.3.0 · 2184a0e87b7dca161267f5fe596a2dd5d56d189d
Dokumentation, Binärdateien, Prüfsummen und das Ergebnis der 25 Szenarien unten beziehen sich fest auf das veröffentlichte v0.3.0 und den auditierten Release-Commit. Ghost bleibt experimentell; die verlinkte Dokumentation zu Sicherheits- und Bedrohungsmodell legt die genauen Grenzen fest.
Release Notes zu v0.3.0