Ich hatte nicht vor, ein autonomes Sicherheitssystem zu bauen.
Ich brauchte eine Infrastruktur, die am Leben bleibt.
Meine Arbeit läuft über ein verteiltes Mesh aus Servern, Websites, APIs, Daten-Pipelines und Agenten. Vieles davon bediene ich aus der Ferne, oft über eine Telegram-Oberfläche auf meinem Telefon. Wenn etwas ausfiel, musste ich es sofort wissen. Wenn ich nicht am Rechner war, brauchte ich trotzdem eine Möglichkeit, das Problem zu verstehen und zu handeln.
Die erste Version von Aegis wurde um diesen Bedarf herum gebaut. Sie beobachtete das Mesh.
Dann änderte sich das Problem.
Ein System online zu halten, reichte nicht mehr. Das System musste erkennen, wann es angegriffen wurde, feindliches Verhalten von gewöhnlichem Traffic unterscheiden, Bedrohungen über mehrere Knoten hinweg eindämmen und das alles, ohne ein KI-Modell in einen unbeschränkten Root-Benutzer zu verwandeln.
So hat sich Aegis weiterentwickelt.
Heute ist Aegis ein begrenztes, beweisgesteuertes autonomes Verteidigungssystem, das über fünf Knoten und 51 Cloudflare-Zonen läuft. Es beobachtet den Bestand, untersucht verdächtige Aktivität, schlägt Maßnahmen vor, prüft Beweise, setzt Richtlinien durch, testet die eigenen Abwehrmechanismen, lernt aus Angriffen und berichtet, was geschehen ist.
Vor allem verwechselt es Intelligenz nicht mit Befugnis.
Aegis begann als Schicht für operative Lagekenntnis.
Es prüfte, ob Seiten erreichbar waren, ob TLS-Zertifikate auf den Ablauf zugingen, ob Canonical- und Indexierungsanweisungen weiterhin korrekt waren und ob eine Domain Cloudflare umgehen und ihren Origin direkt offenlegen konnte.
Die Benachrichtigungen waren bewusst leise angelegt. Aegis meldet einen Übergang, wenn etwas kaputtgeht, und einen weiteren, wenn es sich erholt. Es schickt nicht alle paar Minuten denselben Fehler, bis aus einer wichtigen Warnung Hintergrundrauschen wird.
Dieses einfache Modell begründete das erste Prinzip von Aegis: Nützliche Autonomie beginnt mit verlässlicher Beobachtung.
Wenn das System nicht genau beschreiben kann, was geschieht, hat es beim Handeln nichts verloren.
Die Entwicklung von der Überwachung zur Verteidigung wurde bei der Wiederherstellung einer kompromittierten WordPress-Installation notwendig.
Der Angreifer hatte zehn Backdoors in Plugin-Verzeichnissen platziert und Doorway-Seiten im Document Root angelegt. Die Implantate sahen bewusst gewöhnlich aus. PHP-Dateien waren in Asset- und Bildverzeichnissen verstaut, mit Namen, die an legitime Cache-Manager und Sicherheits-Helfer erinnerten.
Der WordPress-Core blieb unangetastet. Die Verzeichnisse wp-admin und wp-includes waren Byte für Byte identisch mit einer unberührten Installation.
Das war der geschickte Teil.
Viele WordPress-Integritätsprüfungen konzentrieren sich auf den Core, weil es für den Core eine bekannte Prüfsummen-Grundlage gibt. Plugin-Verzeichnisse sind komplizierter. Sie ändern sich häufig, enthalten Code von Dritten und sammeln oft Dateien an, die niemand wiedererkennt. Der Angreifer nutzte diese Uneindeutigkeit als Tarnung.
Die Datenbank überstand es. Hunderte Beiträge, Buchungen, Bestellungen und SEO-Beschreibungen blieben intakt, was die Wiederherstellung möglich machte. Aber der Vorfall legte die Grenze klassischer Überwachung offen. Eine Seite konnte HTTP 200 zurückgeben, ein gültiges Zertifikat vorweisen und gesund aussehen, während sie im Stillen mehrere Persistenzmechanismen enthielt.
Aegis musste den Unterschied zwischen Verfügbarkeit und Integrität lernen.
Es musste außerdem lernen, dass unterschiedliche Systeme unterschiedlich viel Misstrauen verdienen. Eine gehärtete Anwendung und eine zuvor kompromittierte WordPress-Installation sollten nicht allein der Symmetrie halber dieselbe Überwachung erhalten. Sicherheitsmaßnahmen sollten dem Risiko folgen.
Der WordPress-Host erhält inzwischen eine eigene Dateiintegritäts-Überwachung, Prüfungen des Plugin-Lebenszyklus, gezielte Manipulationserkennung und ein aggressiveres Bedrohungsprofil. Er wird als nicht vertrauenswürdiger Mieter innerhalb eines geschützten Bestands behandelt.
Der Rest des Mesh erbt sein Risiko nicht.
Aegis beobachtet den Live-Request-Traffic im gesamten Mesh über Nginx-Logs. Außerdem unterhält es Köder-Endpunkte für Pfade wie offengelegte Umgebungsdateien und Git-Konfiguration.
Normale Besucher haben keinen Grund, diese Ressourcen anzufordern. Scanner schon.
Wenn jemand einen Köder berührt, wird aus der Anfrage mehr als eine weitere Zeile in einem Zugriffsprotokoll. Sie wird zu strukturierten Beweisen. Quelle, Pfad, Antwort, Timing, User Agent, verwandte Anfragen und die bekannte Technik werden für die Auswertung gesichert.
Aegis unterstützt außerdem gezielte Prüfungen auf Abruf. Ich kann es bitten, eine URL zu untersuchen, eine Sicherheitsbewertung durchzuführen oder eine bestimmte IP und einen User Agent zu beurteilen. Damit wird dasselbe System, das ununterbrochen beobachtet, zur Untersuchungsschnittstelle, wenn etwas menschliche Aufmerksamkeit verdient.
Nicht jede Sicherheitsentscheidung erfordert dieselbe Art von Schlussfolgerung.
Aegis arbeitet deshalb mit zwei Geschwindigkeiten.
Die Reflexschicht behandelt Verhalten, für das es im Grunde keine legitime Deutung gibt. Anfragen nach sensiblen Dateien, bekannten Geheimnispfaden und ausdrücklichen Honeypot-Ressourcen können sofort eine deterministische Reaktion auslösen. Es ist nicht nötig, darauf zu warten, dass ein Sprachmodell erklärt, warum jemand /.git/config angefordert hat.
Die Urteilsschicht behandelt mehrdeutigen Traffic. Alle 30 Minuten gruppiert sie verdächtige Aktivität nach Quelle und bittet ein LLM, das Verhalten als schädlich oder harmlos einzustufen. Diese Schlussfolgerung stützt sich auf den eigenen Technik-Korpus von Aegis, aktuelle Threat Intelligence, Schweregraddaten und den Abhängigkeitsgraphen der geschützten Systeme.
Der Unterschied ist wichtig.
Schnelle deterministische Kontrollen übernehmen die offensichtlichen Fälle. Kontextbezogenes Schlussfolgern übernimmt Verhalten, das Deutung verlangt. Keines von beiden wird gezwungen, die Arbeit des anderen zu tun.
Die wichtigste Grenze in Aegis ist die Trennung zwischen Urteil und Durchsetzung.
Das LLM kann Aktivität untersuchen, Techniken benennen, Konfidenz zuweisen, seine Schlussfolgerung erklären und eine Sperre vorschlagen. Ausführen kann es die Sperre nicht.
Ein separater Executor mit Root-Rechten prüft den Vorschlag gegen deterministische Richtlinien. Er kontrolliert harte Allowlists für Infrastrukturadressen, Cloudflare-Bereiche, Mesh-Knoten und verifizierte Crawler. Er wendet außerdem Grenzen pro Durchlauf, Tageshöchstwerte, Abklingzeiten pro IP und weitere Kontrollen des Wirkungsradius an.
Mehrdeutiger Traffic kann nicht allein aufgrund einer Modellmeinung gesperrt werden. Ein Urteil muss mit einer deterministischen Bestätigung übereinstimmen, etwa einem Honeypot-Kontakt, wiederholten Fehlversuchen oder einem festgelegten Schwellenwert für das Anfragevolumen.
Erst dann kann die Durchsetzung erfolgen.
Bestätigte Sperren werden auf beiden Ebenen des Perimeters angewendet. Die Quelle wird lokal über fail2ban und am Edge über Cloudflare blockiert. Ein gemeinsames Sperr-Register verteilt die Entscheidung auf alle fünf Knoten, sodass ein auf einer Property erkannter Angreifer auf einer anderen keine neue Chance bekommt.
Jede Sperre wird protokolliert und ist umkehrbar.
Fällt die Urteilsschicht aus, endet die ermessensabhängige Durchsetzung, während die deterministischen Reflexschutzmechanismen aktiv bleiben. Ein Kill Switch kann die Durchsetzung vollständig entschärfen. Das System ist so ausgelegt, dass es sicher ausfällt, denn ein nicht verfügbares Modell sollte kein Vorwand für unkontrolliertes Handeln werden.
Kein Erkennungssystem ist glaubwürdig, weil es behauptet, perfekt zu sein.
Glaubwürdig wird es, wenn Fehler eingegrenzt werden.
Bei einem Live-Durchlauf zeigten zwei legitime Photon-Crawler ein Verhalten, das verdächtig genug war, um die Triage-Schicht von Aegis zu erreichen. Die Einstufung war falsch. Die Architektur verhinderte, dass aus diesem Fehler eine schädliche Handlung wurde.
Die Crawler erzeugten einen Log-Eintrag und eine Verbesserung der Erkennung. Sie wurden nicht zu zwei gesperrten Kunden.
Deshalb sind Bestätigungsschwellen, Allowlists, Shadow-Tests, Umkehrbarkeit und Grenzen des Wirkungsradius keine zweitrangigen Schutzmaßnahmen. Sie sind das Fundament, das autonomes Schlussfolgern im Produktivbetrieb brauchbar macht.
Ein intelligentes System wird sich manchmal irren. Ein sicheres System steuert, was ein Irrtum kosten darf.
Aegis verwirft feindlichen Traffic nicht, nachdem es ihn blockiert hat.
Jeder Honeypot-Treffer wird nach Technik verschlagwortet, nach Schweregrad eingeordnet und rund vier Monate in einem dauerhaften Korpus aufbewahrt. Mit der Zeit entsteht daraus eine Aufzeichnung dessen, was diese Infrastruktur tatsächlich angreift, statt einer allgemeinen Liste dessen, was Systeme irgendwo im Internet angreifen könnte.
Dieser Unterschied ist wertvoll.
Öffentliche Threat Intelligence beschreibt das weitere Umfeld. Der eigene Korpus von Aegis beschreibt den Druck, der auf genau dieses Mesh ausgeübt wird.
Neue Erkennungssignaturen werden im Shadow-Modus eingeführt. Sie halten fest, was sie gesperrt hätten, ohne zu handeln. Ich kann dann ihre Leistung prüfen, Fehlalarme erkennen und nur die Signaturen freigeben, die sauberes Verhalten zeigen.
Das System lernt fortlaufend, aber neues Wissen erhält nicht automatisch Befugnis.
Aegis bezieht planmäßig Informationen aus MITRE ATT&CK, MITRE ATLAS, CAPEC, dem Katalog Known Exploited Vulnerabilities der CISA, der National Vulnerability Database, Nuclei und dem IACR Cryptology ePrint Archive.
Feeds bloß einzusammeln würde Rauschen erzeugen. Aegis vergleicht jeden Abruf mit seinem vorherigen Stand und gleicht neue Informationen mit dem tatsächlichen Abhängigkeitsgraphen des Mesh ab.
Die tägliche Zusammenfassung konzentriert sich daher darauf, was sich geändert hat und was den Stack berührt.
Eine neue Schwachstelle in Software, die wir nicht betreiben, ist kein Notfall. Eine neu ausgenutzte Schwachstelle in einer Abhängigkeit, die einer unserer Dienste offenlegt, schon.
Weil das Mesh auch post-quantenkryptografische Arbeit trägt, verfolgt Aegis einschlägige Kryptoanalyse und neue Forschung in diesem Bereich. Dasselbe abhängigkeitsbewusste Modell gilt. Das Ziel ist nicht, alles zu kennen, was jeden Tag veröffentlicht wird. Es geht darum zu erkennen, was das Risiko der Systeme verändert, die wir tatsächlich betreiben.
Sobald angreiferkontrollierte Daten in ein LLM fließen, wird die Autonomieschicht Teil der Sicherheitsgrenze.
Ein bösartiger Anfragepfad, ein User Agent, eine Payload oder ein Log-Eintrag könnte Text enthalten, der das Modell manipulieren soll. Aegis prüft eingehende Daten deshalb auf Prompt Injection, Jailbreak-Versuche, Extraktionsversuche und andere Formen der Agentenmanipulation, sowohl in der Triage-Schicht als auch am LLM-Gateway.
Erkennung ist nützlich, aber Isolierung ist stärker.
Angreiferkontrollierte Inhalte bleiben nicht vertrauenswürdige Daten. Sie können keine Richtlinien umschreiben, sich keine Rechte verschaffen und dem Executor keine Anweisungen geben. Das Modell kann die Beweise deuten, aber die Beweise werden nicht dadurch zur Befugnis, dass sie Befehlsformen enthalten.
Das ist dasselbe Prinzip, das für den Rest von Aegis gilt. Schlussfolgern und Ausführen bleiben getrennt.
Jeden Morgen führt Aegis eine kontrollierte Red-Team-Bewertung über den gesamten Bestand durch.
Jede Property erhält eine Note sowie eine Zahl kritischer Probleme und Warnungen. Der Bericht zeigt Rückschritte, hebt geschwächte Kontrollen hervor und benennt, wo sich das Risiko zwischen Diensten unterscheidet.
Die Tests sind so angelegt, dass sie Abwehrmechanismen überprüfen, ohne selbst zur dauerhaften Angriffsfläche zu werden. Neue Prüfungen sind begrenzt, kontrolliert und werden entfernt, wenn ihr Zweck erfüllt ist.
So entsteht täglich eine Antwort auf eine Frage, die den meisten Infrastrukturteams schwerfällt:
Funktionieren die Schutzmaßnahmen, von denen wir glauben, dass es sie gibt, heute noch?
Eine Konfiguration kann abdriften. Ein Deployment kann einen Origin offenlegen. Ein Plugin kann inaktiv werden. Ein Zertifikat kann auf den Ablauf zugehen. Ein Security-Header kann verschwinden. Aegis geht nicht davon aus, dass der Zustand von gestern die Änderungen von heute überstanden hat.
Es prüft nach.
Ich bediene Aegis über eine entfernte Agentensitzung, die an Telegram angebunden ist, aber Telegram ist nur die Oberfläche. Der eigentliche Vorteil des Systems ist das gemeinsame operative Gedächtnis.
Warnungen, Untersuchungen, vorgeschlagene Maßnahmen, Freigaben, abgelehnte Entscheidungen, Testergebnisse und Korrekturen werden Teil desselben dauerhaften Kontexts. Der Agent wacht nicht bei jedem Vorfall ohne Zustand auf. Er weiß, wie sich das Mesh verhält, was es angegriffen hat, welche Maßnahmen funktioniert haben, wo Fehler passiert sind und wie ich mich entschieden habe zu reagieren.
Dieses Gedächtnis verbessert das Urteil, aber es erteilt keine Erlaubnis.
Das Gedächtnis beschreibt, was geschehen ist. Die Richtlinie entscheidet, was geschehen darf.
Diese Trennung erlaubt es dem System, mit der Zeit besser informiert zu werden, ohne dass angesammelter Kontext zu angesammelten Rechten wird.
Aegis läuft live über das gesamte Mesh, mit seiner primären Urteilsschicht in Helsinki und der Durchsetzung verteilt über Oregon, Singapur, Ashburn und Nürnberg. Ich bediene es von Falkenstein aus, oft über mein Telefon.
Die Architektur ist außerdem als aegis-intake-SDK für intake.dental verpackt.
Diese Verpackung ist wichtig, weil sie zeigt, dass Aegis nicht länger nur eine Sammlung von Skripten ist, die auf meine persönliche Infrastruktur zugeschnitten sind. Sein Kernmodell lässt sich übertragen:
Diese Prinzipien gelten über dieses Mesh hinaus.
Aegis begann als Möglichkeit zu wissen, wann etwas kaputtging.
Es wurde zu einer Möglichkeit zu verstehen, warum.
Dann wurde es zu einer Möglichkeit, einen Angriff zu erkennen, ihn über einen verteilten Bestand hinweg einzudämmen, aus dem Versuch zu lernen, zu überprüfen, ob die Abwehrmechanismen noch funktionieren, und jede getroffene Entscheidung zu erklären.
Das Ziel ist nicht, Menschen aus der Sicherheit zu entfernen. Das Ziel ist, menschliches Urteilsvermögen dort einzusetzen, wo es den größten Wert hat, und Maschinen die Verantwortung für fortlaufende Beobachtung, Korrelation, Tests und begrenzte Reaktion zu übertragen.
Aegis beobachtet, während ich arbeite. Es beobachtet, während ich schlafe. Es gerät nicht in Panik, vergisst nicht, ein Log zu prüfen, und ignoriert kein Zertifikat, weil eine andere Aufgabe dringend wurde.
Aber es besitzt auch keine unbeschränkte Macht.
So bewacht Aegis das Mesh.
Intelligenz darf vorschlagen. Beweise müssen bestätigen. Die Richtlinie erteilt Befugnis. Jede Handlung bleibt begrenzt, umkehrbar und prüfbar.