KI-Sicherheits-Agents

Deine App hat Sicherheitslücken. Jede App hat welche. Die Frage ist, ob du sie findest, bevor deine Nutzer es tun.

So sieht eine Sicherheitslücke in der Praxis aus. Jemand meldet sich bei deiner App an. Schaut sich um. Ändert eine Zahl in der URL-Leiste. Plötzlich sieht er die privaten Daten eines anderen Nutzers: Rechnungsinfos, gespeicherte Dokumente, persönliche Nachrichten. Nicht weil er ein Hacker ist. Einfach weil nichts in deiner App ihn aufgehalten hat.

Genau das ist die Art von Fehler, mit der die meisten SaaS-Apps ausgeliefert werden. Kein Hollywood-Hack. Nur eine fehlende Regel: "Du kannst nur deine eigenen Daten sehen."

Dieser Post zeigt ein System, das solche Fehler automatisch aufspürt. Zwei Befehle. Acht KI-Agents. Phase 1 findet alles, was falsch aussieht. Phase 2 versucht tatsächlich einzubrechen und beweist, welche Probleme real sind. Nur bestätigte Fehler landen im abschließenden Bericht.

Die fünf Lücken, mit denen die meisten SaaS-Apps ausgeliefert werden

Das sind die häufigsten Sicherheitsprobleme in Apps von Solo-Foundern, Indie-Hackern und Vibe-Codern. Keine davon erfordert Hacking-Kenntnisse. Ein neugieriger Nutzer mit Browser-Devtools findet die meisten davon.

1. Nutzer können gegenseitig ihre Daten sehen

Du erstellst eine Datenbanktabelle für Nutzerdaten: Profile, Dokumente, Einstellungen. Standardmäßig interessiert es die meisten Datenbanken nicht, wer die Daten anfragt. Kommt eine Anfrage, werden die Daten geliefert.

Die Lösung ist eine Regel: "Gib nur Zeilen zurück, die der fragenden Person gehören." In Datenbanksprache nennt man das Row-Level-Security. Stell dir einen Filter vor, der automatisch "WHERE user_id = der angemeldete Nutzer" zu jeder Abfrage hinzufügt. Ohne das kann jeder angemeldete Nutzer die Daten aller anderen abrufen.

Das ist die häufigste Sicherheitslücke in SaaS-Apps. Jemand ändert eine ID in der URL oder öffnet die Devtools des Browsers, und sieht Dinge, die er nicht sehen sollte.

2. Jemand überspringt den Login und trifft direkt dein Backend

Deine App hat eine Login-Seite. Dahinter gibt es API-Endpunkte, die Daten abrufen und verändern. Das Frontend sendet immer den Login-Token mit. Also gehst du davon aus, dass jede Anfrage ein gültiges Token hat.

Aber jemand kann deine API-Endpunkte direkt aufrufen, ohne dein Frontend zu benutzen. Mit curl oder Postman. Prüft dein Backend nicht bei jeder Anfrage ein gültiges Login-Token, ist er drin. Kein Login nötig.

3. Geheime Schlüssel im Browser

Deine App spricht mit externen Diensten: Zahlungsanbieter, E-Mail-Anbieter, KI-APIs. Jeder Dienst gibt dir einen geheimen Schlüssel. Einige sind sicher im Browser, wie der Stripe Publishable Key. Andere nicht, wie der Stripe Secret Key, der E-Mail-API-Key oder der Datenbank-Admin-Key.

Landet ein geheimer Schlüssel im Frontend-Code, kann ihn jeder mit den Browser-Devtools finden und benutzen. E-Mails von deinem Account senden, Kreditkarten belasten oder mit vollen Admin-Rechten auf deine Datenbank zugreifen.

4. Deine API verrät mehr als nötig

Dein Nutzerprofil-Endpunkt gibt Nutzerdaten zurück, damit das Frontend sie anzeigen kann. Aber das Backend gibt alles in der Datenbankzeile zurück, nicht nur das, was das Frontend braucht. E-Mail, vollständiger Name, interne IDs, Abonnementstatus, vielleicht sogar Passwort-Hashes.

Ein Nutzer ruft deine API auf und bekommt seine eigenen Daten. Okay. Aber die Antwort enthält 15 zusätzliche Felder, die das Frontend nie verwendet. Jetzt kennt er deine interne Datenstruktur. Schlimmer: Ist Lücke Nr. 1 ebenfalls vorhanden, kann er diese Informationen für jeden Nutzer im System abrufen.

Fehlermeldungen gehören auch dazu. Wenn etwas schiefläuft, gibt deine App vielleicht den rohen Datenbankfehler zurück: "column 'stripe_customer_id' does not exist in table 'users'." Das zeigt einem Angreifer genau, wie deine Datenbank aufgebaut ist.

5. Fehlende Browser-Sicherheitsregeln

Browser haben eingebaute Sicherheitsfunktionen, aber sie funktionieren nur, wenn deine App sie aktiviert. Das sind HTTP-Header, die dein Server mit jeder Antwort sendet. Sie teilen dem Browser mit:

• "Lass andere Websites meine App nicht in einem Frame einbetten" (verhindert Clickjacking)
• "Führe nur Scripts aus, die ich explizit genehmigt habe" (verhindert Code-Injection)
• "Akzeptiere nur Anfragen von meiner eigenen Domain" (verhindert Cross-Site-Angriffe)

Ohne diese Header ist deine App Angriffen ausgesetzt, die Browser eigentlich blockieren sollen. Die meisten Frameworks setzen sie standardmäßig nicht.

Warum Sicherheitsscanner nicht helfen

Es gibt Tools, die deinen Code auf Sicherheitsprobleme scannen. Das Problem: Sie flaggen alles, was falsch aussieht, auch wenn es in Ordnung ist.

Ein Beispiel. Deine App hat einen Hintergrundjob, der Zahlungen verarbeitet. Hintergrundjobs haben keinen angemeldeten Nutzer, also brauchen sie Admin-Level-Datenbankzugriff. Ein Scanner sieht "Admin-Datenbankzugriff" und markiert das als kritische Sicherheitslücke. Aber es ist korrekt. Der Hintergrundjob braucht diesen Zugriff. Kein Fehler, das ist die Art, wie das Feature funktioniert.

Das nennt sich False Positive. Der Scanner hat etwas markiert, das gefährlich aussieht, aber eigentlich in Ordnung ist.

Bei einem echten Scan passiert das ständig. Der Scanner meldet 87 Probleme. Du liest alle durch. 82 davon sind so designed. Die 5 echten Fehler sind in einem Haufen falscher Alarme vergraben, und ohne tiefes Wissen über deine Codebase kannst du nicht erkennen, was was ist.

Das Kernproblem: Sicherheitstools verstehen deine Geschäftslogik nicht. Sie wissen nicht, dass dein Hintergrundjob Admin-Zugriff braucht. Nicht, dass deine "ideas"-Tabelle absichtlich öffentlich ist. Nicht, dass dein Onboarding-Flow aus gutem Grund ein bestimmtes Auth-Muster verwendet. Sie sehen Muster, die gefährlich aussehen, und flaggen sie.

Die Zwei-Phasen-Lösung

Die Pipeline besteht aus zwei Claude Code Slash-Commands. Jeder startet ein Team von KI-Agents, die gleichzeitig arbeiten.

.claude/
  commands/
    security.md          # Phase 1: 5 Agents scannen deinen Code
    pentest.md           # Phase 2: 3 Agents versuchen einzubrechen
  agents/
    security-auditor.md  # Regeln, die alle Phase-1-Agents befolgen
dev/
  reports/
    security/            # Phase-1-Berichte
    pentest/             # Phase-2-Berichte

Phase 1 (Reporter): Fünf Agents lesen deinen Code und prüfen auf die fünf Lücken oben. Jeder Agent fokussiert sich auf einen Bereich. Sie haben Zugriff auf deine Live-Datenbank und prüfen, was tatsächlich deployed ist, nicht nur was der Code sagt. Output: ein Bericht, der alles auflistet, was falsch aussieht.

Phase 2 (Exploiter): Drei Agents versuchen tatsächlich in deine laufende App einzubrechen. Sie lesen den Phase-1-Bericht und versuchen jeden Fund auszunutzen. Sie senden echte Anfragen, probieren echte Angriffe und protokollieren, was passiert. Können sie nicht einbrechen, wird der Fund als False Positive markiert und entfernt. Output: ein validierter Bericht, bei dem jeder verbleibende Fund mit Beweis unterlegt ist.

Der Filter zwischen den beiden Phasen macht das System nützlich. Phase 1 fängt alles Verdächtige. Phase 2 beweist, was real ist. Die falschen Alarme sterben in Phase 2, statt deine Zeit zu verschwenden.

Phase 1: fünf Reporter

Jeder Reporter ist ein KI-Agent, der sich auf eine Art von Sicherheitsproblem fokussiert. Sie laufen alle gleichzeitig.

Datenbank-Zugriffs-Auditor

Prüft, ob Nutzer gegenseitig ihre Daten sehen können. Verbindet sich mit der Live-Datenbank und schaut sich die tatsächlichen Zugriffsregeln an, nicht nur den Code. Findet Tabellen, in denen Nutzerdaten gespeichert sind, aber keine "Gib nur deine eigenen Zeilen zurück"-Regel existiert. Prüft auch Datenbankfunktionen mit mehr Rechten als nötig.

Input-Validierungs-Auditor

Prüft jeden Ort, an dem die App Nutzereingaben akzeptiert. Kann jemand Code in ein Formularfeld eingeben und ausführen lassen? Einen speziell gestalteten String senden, der die Datenbank dazu bringt, Befehle auszuführen? Eine Datei mit einem Namen wie ../../etc/passwd hochladen und Dateien lesen, die er nicht sollte? Dieser Agent testet all das.

Login- und Session-Auditor

Prüft, ob das Login-System solide ist. Gibt es Endpunkte, die einen Login erfordern sollten, es aber nicht tun? Kann jemand die API mit einem gefälschten oder abgelaufenen Token aufrufen und trotzdem reinkommen? Kann ein normaler Nutzer Admin-Features durch Manipulation seines Tokens aufrufen? Gibt es etwas, das Tausende von Passwortversuchen verhindert?

Datenleck-Auditor

Prüft, was die App preisgibt. Geben API-Antworten zusätzliche Felder zurück, die das Frontend nicht braucht? Zeigen Fehlermeldungen interne Datenbankdetails? Gibt es geheime Schlüssel im Frontend-JavaScript, die nicht dort sein sollten? Tauchen sensible Daten in URLs auf, wo Browser-Verlauf oder Server-Logs sie erfassen?

Konfigurations-Auditor

Prüft die Sicherheitseinstellungen der App. Sind die Browser-Sicherheits-Header aktiviert? Sagt die App den Browsern, Anfragen von beliebigen Websites zu akzeptieren, was sie nicht sollte? Sind Login-Cookies korrekt konfiguriert? Gibt es bekannte Sicherheitslücken in den Paketen, von denen die App abhängt?

Alle fünf laufen gleichzeitig. Jeder schickt Ergebnisse als Text zurück. Keiner ändert Code. Ein Orchestrator liest alles und fasst es zu einem einzigen Bericht zusammen.

Der Schlüssel zu weniger False Positives: Geschäftslogik verstehen

Das ist der Unterschied zwischen diesen Agents und einem normalen Sicherheitsscanner.

Jede Codebase hat Dinge, die falsch aussehen, aber korrekt sind. Die Agents müssen das im Voraus wissen. Sonst flaggen sie sie jedes Mal, genau wie jeder andere Scanner.

Die Agent-Definition enthält einen Abschnitt "Dokumentierte Ausnahmen": eine Liste von Mustern, die die Agents erkennen und überspringen sollen:

• Hintergrundjobs, die Admin-Datenbankzugriff brauchen (kein angemeldeter Nutzer, Admin-Zugriff ist der einzige Weg)
• Tabellen mit öffentlichen Daten, die absichtlich von allen lesbar sind
• Auth-Muster, die beim Signup zusätzliche Nutzerinfos abrufen, zum Beispiel den Namen von Google
• Öffentliche API-Keys, die im Browser sein sollen, wie der Site-Key für Bot-Schutz
• Tabellen, die von Drittanbietern verwaltet werden, zum Beispiel Zahlungsanbieter-Tabellen

Jede Ausnahme ist spezifisch: wann das Muster auftritt, warum es korrekt ist. Der Agent prüft seine Ausnahmeliste, bevor er einen Fund generiert. Matcht ein Muster, wird es übersprungen. Kein False Positive.

Diese Liste ist das Effektivste, was du schreiben kannst. Fang mit 5 bis 10 Einträgen an. Füge nach jedem Audit False Positives hinzu. Ab dem dritten Durchlauf filtern die Agents 90%+ des Rauschens heraus, bevor es dich erreicht.

Die Agents können sich auch mit der Live-Datenbank verbinden und prüfen, was tatsächlich deployed ist. Code sagt, was sein soll. Eine Live-Datenbankabfrage zeigt, was ist. Wenn ein Migrations-Skript Zugriffskontrollen hinzufügen sollte, aber still scheiterte, fängt die Live-Abfrage das auf. Das beseitigt eine ganze Kategorie von False Positives: Fälle, bei denen der Code okay aussieht, aber das Deployment nicht übereinstimmt.

Scoping: nur prüfen, was sich geändert hat

Fünf Agents über die gesamte Codebase jedes Mal laufen zu lassen ist teuer. Meistens reicht es, nur zu prüfen, was sich seit dem letzten Bericht geändert hat.

Der Befehl macht das automatisch. Er schaut auf das Datum des letzten Sicherheitsberichts, findet alle Dateien, die sich seitdem geändert haben, und schickt nur diese an die Agents. Hat sich nichts Sicherheitsrelevantes geändert, beendet er sich frühzeitig.

Vollständige Scans sind für den ersten Audit oder nach einem großen Refactoring. Alles andere ist auf die letzten Änderungen beschränkt.

Phase 2: drei Exploiter

Phase 2 liest den Phase-1-Bericht und versucht tatsächlich in die laufende App einzubrechen. Der Dev-Server muss laufen. Diese Agents stellen echte Anfragen und probieren echte Angriffe.

API-Exploiter

Ruft Backend-Endpunkte direkt auf. Versucht die Angriffe aus Lücke Nr. 1 (IDs ändern, um auf Daten anderer Nutzer zuzugreifen), Lücke Nr. 2 (Endpunkte ohne Login-Token aufrufen) und Lücke Nr. 3 (Sonderzeichen senden, die die Datenbank täuschen könnten). Protokolliert jede Anfrage und Antwort als Beweis.

Browser-Exploiter

Öffnet die App in einem Browser und versucht Angriffe aus Lücke Nr. 4 und Nr. 5. Gibt Code in Formularfelder ein, um zu sehen ob er ausgeführt wird. Prüft, ob die App in die Seite einer anderen Website eingebettet werden kann. Kopiert ein Login-Token, meldet sich ab und versucht mit dem alten Token einzuloggen.

Login-Exploiter

Fokussiert sich vollständig auf die Authentifizierung. Meldet sich als normaler Nutzer an und versucht Admin-Features aufzurufen. Versucht, das Login-Token zu modifizieren, um Nutzer-ID oder Berechtigungsebene zu ändern. Sendet 50 schnelle Login-Versuche, um zu sehen ob es Rate-Limiting gibt. Testet den Passwort-Reset-Flow auf wiederverwendbare Tokens.

Jeder Fund braucht Beweis. Die genaue gesendete Anfrage und die genaue zurückgekommene Antwort. Kann ein Agent nicht beweisen, dass der Angriff funktioniert hat, wird der Fund gestrichen. Deshalb beseitigt Phase 2 False Positives: Der Agent muss den Fehler tatsächlich ausnutzen, nicht nur sagen, dass er vielleicht existiert.

Der Filter in Aktion

Bei einem echten Audit einer produktiven SaaS-App sahen die Zahlen so aus:

Die 82 gestrichenen Funde waren Dinge wie: Admin-Datenbankzugriff in einem Hintergrundjob (korrekt), öffentliche Tabellen ohne Per-Nutzer-Zugriffsregeln (absichtlich öffentlich), ein bestimmtes Auth-Muster beim Signup (für das Feature nötig), ausführliche Fehlermeldungen, die nur im Entwicklungsmodus erscheinen (nicht in der Produktion).

Die 5 bestätigten Fehler waren real. Einer erlaubte jedem Nutzer, sich selbst Admin-Zugriff zu geben, indem er sein Profil aktualisierte. Ein anderer erlaubte jedem, unbegrenzte Credits dem eigenen Account hinzuzufügen. Ein dritter war ein Open-Redirect im Zahlungsflow, der Nutzer nach dem Checkout auf eine gefälschte Website schicken konnte. Jeder Fund kam mit der spezifischen Code-Änderung zum Beheben.

Ohne Phase 2 bekommst du 87 Punkte und keine Ahnung welche davon wichtig sind. Mit Phase 2 bekommst du 5 bewiesene Funde mit dem Angriffsbeweis.

Ausführen

Zwei Befehle:

/security

Phase 1. Fünf Agents scannen gleichzeitig. Standardmäßig Änderungen seit dem letzten Bericht. Bericht wird in dev/reports/security/ gespeichert. Bei ernsten Problemen sagt es dir, Phase 2 zu starten.

/pentest

Phase 2. Liest den Phase-1-Bericht. Startet den Dev-Server, wenn er nicht läuft. Drei Agents versuchen gleichzeitig einzubrechen. Validierter Bericht wird in dev/reports/pentest/ gespeichert.

Regeln für den eigenen Aufbau

Das Muster funktioniert mit jeder Datenbank, jedem Framework, jedem Auth-Anbieter. Das macht es funktionieren.

Schreib deine Ausnahmeliste vor dem ersten Scan. Jede App hat Dinge, die falsch aussehen, aber in Ordnung sind. Die Agents brauchen diese Liste im Voraus. Fang mit den Mustern an, die du als korrekt kennst. Füge False Positives aus jedem Durchlauf hinzu. Die Liste stabilisiert sich nach 2 oder 3 Audits.

Gib Agents Zugriff auf die echte Datenbank, nicht nur den Code. Code sagt, was sein soll. Die Live-Datenbank zeigt, was ist. Stimmen die nicht überein, hast du ein Problem, das der Code dir nicht sagen kann.

Trenne Finden von Beweisen. Phase-1-Agents melden alles Verdächtige. Phase-2-Agents versuchen es auszunutzen. Beide Jobs in einen Agent zu stecken erzeugt einen Konflikt. Er meldet entweder zu viel oder übersieht Dinge. Zwei Phasen mit verschiedenen Jobs liefern bessere Ergebnisse.

Verlange Beweis, keine Meinungen. Frag einen Agent nie "Ist das sicher?" Bitte ihn, Anfrage und Antwort zu zeigen, die beweisen, dass der Angriff funktioniert hat. Beweise erzwingen echte Überprüfung. Meinungen laden zu Abkürzungen ein.

Jeder Fund braucht eine Lösung. Nicht "erwäge, deine Sicherheit zu verbessern." Die spezifische Zeile, die zu ändern ist, und was zu ändern ist. Ein Fund ohne Lösung liegt für immer in einem Ordner.

Füge hinzu, was funktioniert hat. Der Phase-2-Bericht soll Angriffe auflisten, die fehlgeschlagen sind. Injection blockiert. Script-Ausführung blockiert. Cross-Site-Anfragen blockiert. Zu wissen, wogegen sich die App verteidigt, ist genauso wertvoll wie zu wissen, wogegen nicht.

Über Security hinaus

Das Zwei-Phasen-Muster, alles finden und dann beweisen was real ist, funktioniert für mehr als Security.

Code Review. Phase-1-Agents flaggen potenzielle Probleme. Phase-2-Agents schreiben fehlschlagende Tests, um zu beweisen, dass die Probleme real sind. False Positives werden genauso eliminiert.

Performance. Phase-1-Agents identifizieren langsame Datenbankabfragen und große Datei-Bundles. Phase-2-Agents führen echte Benchmarks durch. Eine "langsame Abfrage", die 2 Millisekunden bei echten Daten braucht, ist kein echtes Problem.

Compliance. Phase-1-Agents flaggen Datenverarbeitungsmuster. Phase-2-Agents verfolgen, wohin Daten tatsächlich fließen, um zu prüfen ob die Flags relevant sind. Eine Funktion, die anonyme Analysedaten verarbeitet, braucht keine Datenschutz-Zustimmungsbehandlung, auch wenn das Muster ähnlich aussieht wie eine, die das tut.

Jedes Mal dieselbe Kernidee. Agents genug Kontext geben, um zu verstehen, warum Code existiert. Finden von Beweisen trennen. Das Rauschen filtern, bevor es dich erreicht.