KI-Sicherheits-Agenten

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. Er schaut sich um. Er ä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. Sondern weil nichts in deiner App ihn aufgehalten hat.

Das ist genau die Art von Fehler, mit dem die meisten SaaS-Apps ausgeliefert werden. Kein Hack wie im Film. Einfach eine fehlende Regel, die besagt: "Du kannst nur deine eigenen Daten sehen."

Dieser Beitrag zeigt ein System, das solche Fehler automatisch aufspürt. Zwei Befehle. Acht KI-Agenten. 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, die von Solo-Foundern, Indie-Hackern und Vibe-Codern gebaut wurden. Keine davon erfordert Hacking-Kenntnisse. Ein neugieriger Nutzer mit Browser-Entwicklertools findet die meisten davon.

1. Nutzer können gegenseitig ihre Daten sehen

Du erstellst eine Datenbanktabelle für Nutzerdaten. Profile, Dokumente, Einstellungen, was auch immer. Standardmäßig interessiert es die meisten Datenbanken nicht, wer die Daten anfragt. Wenn jemand eine Anfrage stellt, liefert die Datenbank die Daten.

Die Lösung ist eine Regel: "Gib nur Zeilen zurück, die der Person gehören, die fragt." In Datenbanksprache nennt man das Row-Level-Security. Stell dir das wie 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. Ein Nutzer ändert eine ID in der URL oder öffnet die Entwicklertools des Browsers, und schon sieht er Dinge, die er nicht sehen sollte.

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

Deine App hat eine Login-Seite. Hinter dem Login gibt es API-Endpunkte, die Daten abrufen und verändern. Das Frontend sendet immer den Login-Token mit jeder Anfrage. 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. Er kann Tools wie curl oder Postman verwenden. Wenn dein Backend nicht bei jeder einzelnen Anfrage ein gültiges Login-Token prüft, ist er drin. Kein Login nötig.

3. Geheime Schlüssel im Browser

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

Wenn ein geheimer Schlüssel in deinem Frontend-Code landet, kann ihn jeder mit den Browser-Entwicklertools finden und benutzen. Er kann 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 die 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 zurück. Okay. Aber die Antwort enthält 15 zusätzliche Felder, die das Frontend nie verwendet. Jetzt kennt er deine interne Datenstruktur. Schlimmer noch: Wenn Lücke Nr. 1 ebenfalls vorhanden ist, kann er diese detaillierten Informationen für jeden Nutzer in deinem 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 Dinge mit wie:

• "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 markieren alles, was falsch aussieht, auch wenn es in Ordnung ist.

Hier 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. Es ist kein Fehler, sondern die Art, wie das Feature funktioniert.

Das nennt man einen falschen Treffer. 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 sie alle durch. 82 davon sind Dinge, die so designed sind. Die 5 echten Fehler sind in einem Haufen falscher Alarme vergraben, und ohne tiefes Wissen über deine Codebasis kannst du nicht erkennen, was was ist.

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

Die Zwei-Phasen-Lösung

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

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

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

Phase 2 (Exploiter): Drei Agenten 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. Wenn sie tatsächlich nicht einbrechen können, wird der Fund als falscher Treffer markiert und entfernt. Output: ein validierter Bericht, bei dem jeder verbleibende Fund mit Beweis unterlegt ist.

Der Filter zwischen den beiden Phasen ist es, was das funktionieren lässt. 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 deiner 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 auf Datenbankfunktionen mit mehr Rechten als nötig.

Input-Validierungs-Auditor

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

Login- und Sitzungs-Auditor

Prüft, ob dein Login-System solide ist. Gibt es Endpunkte, die einen Login erfordern sollten, es aber nicht tun? Kann jemand deine API mit einem gefälschten oder abgelaufenen Login-Token aufrufen und trotzdem reinkommen? Kann ein normaler Nutzer Admin-Only-Features durch Manipulation seines Tokens aufrufen? Gibt es irgendetwas, das jemanden daran hindert, Tausende von Passwörtern auszuprobieren?

Datenleck-Auditor

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

Konfigurations-Auditor

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

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

Der Schlüssel zu weniger falschen Treffern: Bewusstsein für Geschäftslogik

Das ist es, was diese Agenten von einem normalen Sicherheitsscanner unterscheidet.

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

Die Agentendefinition enthält einen Abschnitt namens "Dokumentierte Ausnahmen". Das ist eine Liste von Mustern, die die Agenten erkennen und überspringen sollen. Dinge wie:

• Hintergrundjobs, die Admin-Datenbankzugriff brauchen (es gibt keinen angemeldeten Nutzer, also ist Admin-Zugriff der einzige Weg)
• Tabellen, die öffentliche Daten speichern und absichtlich von allen lesbar sind
• Auth-Muster, die beim Signup zusätzliche Nutzerinfos abrufen (nötig für Dinge wie das Abrufen des Namens eines Nutzers von Google)
• Öffentliche API-Schlüssel, die im Browser sein sollen (wie dein Site-Key für Bot-Schutz)
• Tabellen, die von Drittanbietern verwaltet werden (dein Zahlungsanbieter synct Daten in seine eigenen Tabellen)

Jede Ausnahme ist spezifisch: wann das Muster auftritt und warum es korrekt ist. Der Agent prüft seine Ausnahmeliste, bevor er einen Fund generiert. Wenn ein Muster übereinstimmt, überspringt er es. Kein falscher Alarm.

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

Die Agenten können sich auch mit deiner Live-Datenbank verbinden und prüfen, was tatsächlich deployed ist. Code sagt, was sein sollte. Eine Live-Datenbankabfrage zeigt, was ist. Wenn ein Migrations-Skript Zugriffskontrollen zu einer Tabelle hinzufügen sollte, aber still scheiterte, fängt die Live-Abfrage das auf. Das beseitigt eine ganze Kategorie von falschen Treffern: Dinge, bei denen der Code in Ordnung aussieht, aber das Deployment nicht übereinstimmt.

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

Fünf Agenten über deine gesamte Codebasis jedes Mal laufen zu lassen ist teuer. Meistens musst du nur prüfen, was sich seit dem letzten Bericht geändert hat.

Der Befehl erledigt das automatisch. Er schaut sich das Datum des letzten Sicherheitsberichts an, findet alle Dateien, die sich seitdem geändert haben, und schickt nur diese Dateien an die Agenten. Wenn sich nichts Sicherheitsrelevantes geändert hat, 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 deine laufende App einzubrechen. Der Dev-Server muss laufen. Diese Agenten stellen echte Anfragen und versuchen echte Angriffe.

API-Exploiter

Ruft deine Backend-Endpunkte direkt auf. Versucht die Angriffe aus Lücke Nr. 1 (IDs ändern, um auf die 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 deine 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 deine App in die Seite einer anderen Website eingebettet werden kann (was Nutzer dazu bringen könnte, auf Dinge zu klicken). Kopiert ein Login-Token, meldet sich ab und versucht mit dem alten Token einzuloggen, um zu sehen, ob es noch funktioniert.

Login-Exploiter

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

Jeder Fund braucht Beweis. Die genaue gesendete Anfrage und die genaue zurückgekommene Antwort. Wenn ein Agent keinen Beweis liefern kann, dass der Angriff funktioniert hat, wird der Fund gestrichen. Deshalb beseitigt Phase 2 falsche Treffer: 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 getöteten Funde waren Dinge wie: Admin-Datenbankzugriff in einem Hintergrundjob (korrekt), öffentliche Tabellen ohne Pro-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 seinem eigenen Account hinzuzufügen. Ein dritter war ein Open-Redirect im Zahlungsfluss, der Nutzer nach dem Checkout auf eine gefälschte Website schicken konnte. Jeder kam mit der spezifischen Code-Änderung, um ihn zu beheben.

Ohne Phase 2 bekommst du 87 Punkte und keine Ahnung, welche davon wichtig sind. Mit Phase 2 bekommst du 5 Punkte, die beweislich real sind, mit dem Angriffsbeweis.

Ausführen

Zwei Befehle:

/security

Phase 1. Fünf Agenten scannen gleichzeitig. Standardmäßig Änderungen seit dem letzten Bericht. Bericht wird in dev/reports/security/ gespeichert. Wenn es ernste Probleme findet, sagt es dir, Phase 2 zu starten.

/pentest

Phase 2. Liest den Phase-1-Bericht. Startet deinen Dev-Server, wenn er nicht schon läuft. Drei Agenten 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 Agenten brauchen diese Liste im Voraus. Fang mit den Mustern an, die du als korrekt kennst. Füge falsche Treffer aus jedem Durchlauf hinzu. Die Liste stabilisiert sich nach 2 oder 3 Audits.

Gib Agenten Zugriff auf die echte Datenbank, nicht nur den Code. Code sagt, was sein sollte. Die Live-Datenbank zeigt, was ist. Wenn die nicht übereinstimmen, hast du ein Problem, das der Code dir nicht sagen kann.

Trenn Finden von Beweisen. Phase-1-Agenten melden alles Verdächtige. Phase-2-Agenten versuchen es auszunutzen. Beide Jobs in einen Agenten zu stecken erzeugt einen Konflikt. Er meldet entweder zu viel (laut) oder zu wenig (übersieht Dinge). Zwei Phasen mit unterschiedlichen Jobs liefern bessere Ergebnisse.

Verlange Beweis, keine Meinungen. Frag einen Agenten nie "Ist das sicher?" Bitte ihn zu zeigen, welche Anfrage und Antwort beweist, 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 zu ändernde Zeile und was zu ändern ist. Ein Fund ohne Lösung ist ein Fund, der für immer in einem Ordner liegt.

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

Über Sicherheit hinaus

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

Code-Review. Phase-1-Agenten markieren potenzielle Probleme. Phase-2-Agenten schreiben fehlschlagende Tests, um zu beweisen, dass die Probleme real sind. Falsche Treffer werden genauso eliminiert.

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

Compliance. Phase-1-Agenten markieren Datenverarbeitungsmuster. Phase-2-Agenten verfolgen, wohin Daten tatsächlich fließen, um zu prüfen, ob die Markierungen 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. Agenten genug Kontext geben, um zu verstehen, warum Code existiert. Finden von Beweisen trennen. Das Rauschen filtern, bevor es dich erreicht.