Download · Fehler melden · Feature-Anfrage · Mitwirken

Was AEGIS beobachtet

Die oben genannten Zahlen werden nicht manuell gepflegt: npm run counts:check leitet bei jedem CI-Lauf jeden dokumentierten Zähler aus dem Repository-Baum ab und lässt den Build fehlschlagen, wenn eine Zahl in der Dokumentation von der Realität abweicht.

Der Beleg-Graph

Was AEGIS von einem Prozess-Viewer unterscheidet, sind nicht die Sensoren — sondern dass jedes Ereignis an eine Agenten-Instanz gebunden ist, mit Belegen, die Sie prüfen können:

• Instanzidentität. Ein Agent wird über pid + OS-Geburtszeit (instanceId) identifiziert, sodass eine wiederverwendete PID eine neue Instanz ist, keine Fortsetzung der Historie der alten. Das Identitäts-Caching ist durch einen Zeugen abgesichert, und CI führt einen Injektionsbeweis aus (npm run verify:gate, 4 Mutanten), der rot wird, wenn eine Identität jemals aus einem veralteten Cache geliefert werden könnte.
• Zuordnung mit dokumentierten Belegen. Jeder Audit-Datensatz enthält pid, instanceId und ein attribution-Objekt mit einem von drei Status — confirmed, inferred oder unattributed — gestützt auf ein geschlossenes Register von Belegcodes. Wenn AEGIS nicht weiß, welcher Agent eine Datei berührt hat, sagt es unattributed; es erfindet niemals einen Besitzer.
• Manipulationssicheres Log. Audit-Ereignisse sind hash-verkettetes JSONL (Event Schema v1) mit täglicher Rotation, 30-tägiger Aufbewahrung und expliziten Verlustmarkierungen, wenn der Schreibpuffer überläuft.
• Gemessen, nicht behauptet. Der Identitätsmechanismus ist im Repository benchmarkt: Die Parität der Provider-Geburtszeiten war in beiden aufgezeichneten Läufen für jeden vergleichbaren Prozess exakt (542/542 und 419/419), und der Prozess-Snapshot-Seitencarrier kostet ~10 ms pro Scan, während der Fallback-Provider hunderte bis tausende kostet. Tabellen pro Lauf, Umgebungen und die genannten Lücken finden sich in docs/bench/.

Belege: src/main/process-identity.js · src/main/attribution.js · Korrektheits-Audit · Bench 2026-08-12 · Bench 2026-08-13

Monitor-first

AEGIS ist eine Kamera, kein Wächter. Es beobachtet und protokolliert — es blockiert Agenten heute nicht auf Betriebssystemebene. Es gibt keine Kernel-Hooks und keine automatische Durchsetzung. Prozesssteuerung (kill / suspend / resume) ist manuell und nur vom Benutzer ausgelöst. Aktives Blockieren steht auf der Roadmap, nicht in der aktuellen Version. Nutzen Sie AEGIS für Sichtbarkeit, Auditing und Anomalieerkennung — kombinieren Sie es mit Sandboxing, wenn Sie Durchsetzung benötigen.

Wie sich AEGIS von In-Agent-Überwachung unterscheidet

Die meisten Überwachungswerkzeuge für KI-Agenten instrumentieren den Agenten selbst — ein Claude-Code-Plugin, eine IDE-Erweiterung, ein SDK-Wrapper. Diese Platzierung hat einen strukturellen blinden Fleck: Ein Agent taucht nur auf, wenn er (oder sein Benutzer) den Hook installiert hat. Ein rohes python autogpt.py, ein unverpacktes Binary oder ein Werkzeug, das schlicht nicht kooperiert, ist für In-Agent-Instrumentierung unsichtbar.

AEGIS sitzt stattdessen auf der Betriebssystemebene: Es beobachtet Prozess-, Datei- und Netzwerkaktivität von außerhalb der Agenten, sodass das, was es sieht, nicht von der Kooperation des Agenten abhängt — nur von AEGIS' eigener Abdeckung (siehe bekannte Grenzen). Es ist nicht das einzige Werkzeug, das Agenten lokal beobachtet — AgentSight beispielsweise beobachtet auf Linux von der eBPF-Ebene aus — und Hook-basierte Werkzeuge sind komplementär statt konkurrierend: Hooks sehen Absichten (Prompts, Tool-Aufrufe) innerhalb der Agenten, die zugestimmt haben, während AEGIS Auswirkungen (Prozesse, Dateien, Verbindungen) für alles sieht, was auf dem Rechner läuft, verknüpft mit Agenteninstanzen, ohne Kooperation zu erfordern.

Bekannte Grenzen

Ein Monitor, den Sie nicht kalibrieren können, ist ein Monitor, dem Sie nicht vertrauen können. Daher werden die Grenzen hier genannt, statt später entdeckt zu werden. Die erneut verifizierten Erkenntnisse hinter dieser Liste, jeweils mit OPEN/CLOSED-Status, finden sich im Korrektheits-Audit; die Kurzfassung:

• Die Abdeckung basiert auf Signaturen und Heuristiken. Die Erkennung startet bei 110 Agenten (262 Prozessnamens-Signaturen) plus Heuristiken (WSL, IDE-Erweiterungen, lokale LLM-Probes). Ein Agenten-Binary, das auf keine davon passt, wird nicht erkannt.
• Polling hat einen blinden Fleck. Ein Prozess, der zwischen Scan-Ticks (~10 s) geboren wird und stirbt, wird nie beobachtet; die Bench-Seiten geben dies explizit an. Ereignisbasierte Erfassung über ETW steht auf der Roadmap, mit einer statischen Erkundung bereits in docs/recon/kernel-file-etw.md.
• Die Identität unter macOS/Linux ist eingeschränkt. Diese Plattformen liefern derzeit keine OS-Geburtszeit, sodass die Instanzidentität nur auf die PID zurückfällt und bei PID-Wiederverwendung unsicher ist. Die Token-Kostenverfolgung ist nur unter Windows verfügbar.
• UI-Ereignisfenster kürzen still ab. Der Renderer hält begrenzte Ereignisfenster, die von den Summen abweichen können, und es gibt noch kein Kürzungsbanner.
• Die Sensor-Gesundheit wird erfasst, aber noch nicht angezeigt. Der Hauptprozess zeichnet die Gesundheit pro Sensor für die Dateisystem- und Netzwerksensoren auf, aber die UI kann eine ruhige Maschine noch nicht von einem toten Sensor unterscheiden, und Prozess-Scan-Überläufe werden ohne Zähler übersprungen.
• Audit-Verlustmarkierungen benötigen einen erfolgreichen Flush. Wenn der Prozess getötet wird, während die Festplatte noch ausfällt, können entfernte Audit-Einträge ohne On-Disk-Markierung verloren gehen.

Was wir bewusst nicht behaupten

Zahlen erscheinen in dieser README nur, wenn sie aus dem Repository abgeleitet (und durch npm run counts:check erzwungen) oder mit einer dokumentierten Methode gemessen wurden. Einige Zahlen, nach denen gefragt wird, existieren noch nicht, daher nennen wir sie nicht:

• Startzeit. Es gibt keinen Startzeit-Benchmark; die alte Behauptung „unter zwei Sekunden" wurde entfernt, statt ungemessen zu bleiben.
• Erkennungs- oder Falsch-Positiv-Raten. Ein Szenario-Bench mit unabhängigem Orakel existiert (bench/, bewertet gegen Sysmon/Procmon), ist aber nur unter Windows, deckt ein Szenario ab und läuft nicht in CI — keine Grundlage für eine Rate.
• Overhead. AEGIS' eigene CPU/RAM-Kosten wurden nicht unter einer dokumentierten Methode gemessen.
• Benchmark-Beschleunigungs-Schlagzeilen. Das gemessene Snapshot-vs-Fallback-Verhältnis bewegte sich zwischen zwei Tagen auf derselben Maschine von 193× auf 51×; die belastbare Behauptung ist die schwächere — Snapshot ~10 ms, Fallback hunderte bis tausende ms — und nur diese Form wird hier zitiert.
• Konfidenzwerte pro Ereignis. Bewusst nicht im Produkt, bis ein Ground-Truth-Bench existiert.
• Testzahlen. Handkopierte Suite-Zahlen veralten still; die Suite gibt ihre eigenen Zahlen aus, und CI führt sie bei jedem Commit aus.

Warum unabhängige Überwachung

KI-Agenten laufen mit tiefem Zugriff auf Dateien, Anmeldedaten und Shell-Befehle. Das Risiko ist nicht hypothetisch: Kasperskys Bericht zum OpenClaw-Fall stellt fest, dass ein Sicherheits-Audit im Januar 2026 512 Schwachstellen, davon acht kritische, identifizierte, und argumentiert, dass das tiefere Problem architektonisch ist — privilegierter lokaler Zugriff kombiniert mit der Fähigkeit, extern zu kommunizieren (Kaspersky, 2026-02-10). Patchen behebt Fehler; es gibt Ihnen keine Sichtbarkeit darüber, was ein Agent tatsächlich auf Ihrem Rechner getan hat. Diese Sichtbarkeit ist die Ebene, die AEGIS hinzufügt.

Download

Windows-Installer

Ab v0.11.0-alpha enthalten Releases einen Windows-NSIS-Installer — laden Sie die .exe vom neuesten Release herunter. Releases ab v0.13.0-alpha enthalten außerdem ein signiertes Manifest, sodass ein Download offline gegen den in diesem Repository eingecheckten öffentlichen Schlüssel verifiziert werden kann — siehe Verifizieren eines AEGIS-Releases. Frühere Releases enthalten kein Manifest und können auf diese Weise nicht verifiziert werden.

Aus dem Quellcode (alle Plattformen)```bash

git clone https://github.com/antropos17/Aegis.git cd Aegis npm install npm start

Der Dev-Server enthält die Demo-Szenario-Engine — vite.config.js aktiviert sie immer dann, wenn der Befehl serve lautet, sodass das simulierte Dashboard ohne separaten Build-Schritt und ohne Electron gerendert wird. Für einen statischen, teilbaren Build (kein Dev-Server, kein Electron) führen Sie npm run build:demo aus und servieren das resultierende dist/demo-Verzeichnis mit einem beliebigen statischen Dateiserver (der Build verwendet relative Asset-Pfade, sodass jeder Host funktioniert).

Der Demo-Modus führt eine Szenario-Engine aus, die vier Bedrohungsphasen durchläuft — ruhig → erhöht → kritisch → zurückgesetzt — mit bis zu 12 simulierten KI-Agenten (Claude Code, Copilot, Cursor und mehr). Dateizugriffsereignisse, Netzwerkverbindungen, Anomalie-Scores und Risikobewertungen werden in Echtzeit generiert, sodass jede Registerkarte und jedes Feature voll funktionsfähig ist.

Nutzen Sie es, um AEGIS vor der Bereitstellung zu evaluieren, die Benutzeroberfläche Ihrem Team zu demonstrieren oder neue Funktionen zu entwickeln, ohne eine Live-Windows-Umgebung zu benötigen.

Versionshistorie

Funktionen

Erkennung — 110 Agenten (262 Prozessnamen-Signaturen), Auflösung der Elternkette, Überwachung sensibler Pfade und Agent-Konfigurationen, agentenbezogene Risikobewertung mit Vertrauensgraden (A+ bis F), lokale LLM-Erkennung, Markierung falsch positiver Ergebnisse

Analyse — Verhaltens-Baselines mit gleitenden Durchschnitten, mehrdimensionale Anomalieerkennung, KI-Bedrohungsbewertung über die Anthropic-API (optional), druckbare HTML-Bedrohungsberichte

Dashboard — Bento-Grid-Dashboard: RiskRing-Anzeige, TrustBadge, Aktivitätsfeed mit Filtern, Sitzungszeitachse mit Zuordnungs-Tooltips, erweiterbare Agent-Karten, Schutzvoreinstellungen (Paranoid/Streng/Ausgeglichen/Entwickler), Befehlspalette (Ctrl+K), Tastaturkürzel (Ctrl+1-5), dunkles/helles Design, Toast-Benachrichtigungen, OOM-Schutz

Export — JSON-, CSV-, HTML-Berichte, ZIP-Archiv mit einem Klick, hash-verkettetes JSONL-Auditprotokoll (tägliche Rotation, 30-Tage-Aufbewahrung)

i18n — Internationalisierung mit einer englischen Basis (en.json); Community-Übersetzungen willkommen

CLI — --scan-json für Skripting, --version, --help

YAML-Regelsätze

• 73 Erkennungsregeln in 8 Kategorien (KI-Konfiguration, Geheimnisse, SSH, Cloud, Browser, Devtools, Krypto, Zertifikate)
• Validierung gegen rules/_schema.json; das Bearbeiten eines Regelsatzes lädt ihn ohne Neustart neu
• Erweiterbar durch Hinzufügen einer .yaml zu rules/. Regel-IDs müssen eindeutig sein — eine doppelte ID wird übersprungen, nicht überschrieben. Eine neu hinzugefügte Datei wird beim nächsten Neuladen oder Neustart übernommen, da der Watcher auf Änderungen in vorhandenen Top-Level-Dateien reagiert

Screenshots

Aufgenommen aus dem Demo-Build (npm run build:demo), 2026-08-21.

Architektur```

┌───────────────┐ ┌────────────────┐ ┌───────────────┐ ┌───────────────┐ │ Process │ │ File │ │ Network │ │ LLM Runtime │ │ Snapshot │ │ Watcher │ │ Monitor │ │ Detector │ │ (sidecar with │ │ (chokidar + │ │ (TCP + rDNS + │ │ (Ollama / LM │ │ CIM fallback)│ │ handle / RM) │ │ verdicts) │ │ Studio) │ └──────┬────────┘ └──────┬─────────┘ └──────┬────────┘ └──────┬────────┘ └──────────────┬───┴───────────────────┴──────────────────┘ ▼ ┌───────────────────────────────┐ │ Identity & Attribution │ │ instanceId = pid + birth time │ │ evidence codes, no guessing │ └──────┬────────────────┬───────┘ ▼ ▼ ┌──────────────────┐ ┌─────────────────────┐ │ Baselines + │ │ Audit Logger │ │ Anomaly (4-axis) │ │ (Event Schema v1, │ │ Risk Engine │ │ hash-chained JSONL) │ └──────┬───────────┘ └──────┬──────────────┘ ▼ ▼ ┌──────────────┐ ┌──────────────────┐ ┌───────────────┐ │ Dashboard │ │ Exports │ │ CLI │ │ (Svelte IPC) │ │ (JSON/CSV/HTML/ │ │ (--scan-json │ │ │ │ ZIP) │ │ --version) │ └──────────────┘ └──────────────────┘ └───────────────┘

Per-sensor health records live in the main process; surfacing them in the UI is on the roadmap.