GPT-6 Astra fand Fragen, die mein erster Security-Review übersehen hatte
Das Nützlichste, was GPT-6 Astra bisher für mich getan hat, war nicht, Code zu schreiben. Es hat sich Security-Arbeit angesehen, die ich bereits für sorgfältig geprüft hielt — und mir andere Fragen gestellt, die ich beantworten musste.
Ich habe angefangen, Astra zusammen mit Fable 5.1 für klar abgegrenzte Prüfungen in boostN einzusetzen: RLS-Policies der Datenbank, Autorisierungsabläufe in APIs und die Stellen, an denen die Mandantentrennung brechen kann. Mir ging es nicht darum, einen Sieger zu küren. Ich wollte für dasselbe begrenzte Problem einen zweiten, unabhängigen Reviewer.
Überrascht hat mich die Präzision. Astra fand wiederholt Annahmen, Pfade und Randfälle, die Fable im ersten Durchgang nicht angesprochen hatte. Fables Reviews waren oft solide. Astra machte sie nicht überflüssig, sondern nützlicher, weil es sie aus einem anderen Blickwinkel hinterfragte.
Das ist kein Benchmark und keine Behauptung, Astra werde jede Schwachstelle finden. Es ist ein Erfahrungsbericht aus der Arbeit an meinen eigenen Systemen. Nach mehreren Durchläufen sehe ich das Modell aber nicht mehr nur als interessanten Release, den man beobachten sollte. Für strukturierte Security-Checks ist es zu einem Werkzeug geworden, das ich aktiv als zweites Paar Augen einsetzen will.
Meine wichtigste Erkenntnis
1. Astra ist das nützlichste Modell, das ich bisher für Security-Arbeit getestet habe. Ich habe es für RLS-Policies, API-Autorisierung und Mandantentrennung eingesetzt, aber das sind nur Beispiele. Genauso nützlich ist es, um Angriffshypothesen zu formulieren, unbekannte Codepfade zu untersuchen, kleine Prüfwerkzeuge zu bauen und aus einer vagen Risikofrage einen fokussierten, testbaren Check zu machen. Ich bin kein Cybersecurity-Spezialist. Das ist deshalb keine Aussage über das Niveau eines professionellen Audits, sondern eine praktische Beobachtung aus meiner Arbeit mit dem Modell.
2. Es versteht ungeschliffene Briefings aus dem Arbeitsalltag. Bei vielen Modellen muss ich nach der ersten Antwort noch erklären, worum es bei einer Aufgabe eigentlich geht. Astra ist das erste Nicht-Claude-Modell, das diese Absicht auch aus unperfektem Input zuverlässig erfasst: einer groben Sprachtranskription, Satzfragmenten oder einem Briefing mit fehlendem Kontext. Damit ist es auch außerhalb von Security-Arbeit nützlich — um Konzepte zu durchdenken, eine Idee in einen Plan zu überführen und einen unfertigen Gedanken bis zu einem brauchbaren Ergebnis weiterzuführen. Warum das wichtig ist →
Es versteht die Aufgabe, bevor ich sie zu Ende erklärt habe
Das ist der zweite Punkt, der für mich heraussticht. Bei vielen Modellen — Gemini oder selbst GPT-6 Sol auf der höchsten Einstellung — habe ich oft noch das Gefühl, die eigentliche Aufgabe zweimal erklären zu müssen. Die erste Antwort kann technisch plausibel sein und trotzdem die tatsächliche Absicht verfehlen, eine Einschränkung aus dem Projektkontext übersehen oder nicht erfassen, warum ein Detail wichtig ist.
Claude war dafür in meiner Arbeit bisher der Maßstab. Angefangen habe ich mit Opus 4.6 und war beeindruckt, wie gut es verstand, was ich meinte — nicht nur die Wörter, die ich eingegeben hatte. Diese Fähigkeit wurde bis zum aktuellen Opus 5 immer besser, und Fable beherrscht sie ebenfalls: Ich kann ihm eine grobe Sprachtranskription mit Satzfragmenten, Fehlern und fehlendem Kontext geben, und in vielleicht 95 Prozent der Fälle erkennt es trotzdem die richtige Aufgabe und unternimmt die passenden nächsten Schritte.
Astra ist das erste Modell außerhalb dieser Claude-Gruppe, das für mich dasselbe Niveau erreicht hat. Es kann mit einem unperfekten Briefing arbeiten, die nützliche Frage daraus ableiten und auf das beabsichtigte Ergebnis fokussiert bleiben, ohne eine lange zweite Erklärung zu brauchen. Das ist kein Benchmark-Ergebnis. Es ist ein praktischer Unterschied, den du bemerkst, wenn der Input aus einem echten Arbeitstag stammt und nicht aus einem sorgfältig formulierten Prompt.
Der Test war bewusst eng begrenzt
„Prüfe die Sicherheit der gesamten Anwendung“ ist weder für ein Modell noch für einen Menschen eine brauchbare Aufgabe. Das Ergebnis ist ein langes, plausibel klingendes Dokument und wenig Gewissheit.
Die nützlichen Fragen waren konkret:
- Kann ein Nutzer über diesen API-Ablauf eine Mandantengrenze überschreiten?
- Schützen diese RLS-Policies Lesezugriffe, Schreibzugriffe und indirekte Zugriffe gleichermaßen?
- Hält diese Berechtigungsprüfung auch dann noch, wenn eine Anfrage über einen weniger offensichtlichen Weg kommt?
- Welche Annahmen in diesem Authentifizierungsablauf müssen im Code belegt werden, statt sie aus dem Happy Path abzuleiten?
Dieser Umfang ist entscheidend. Er gibt dem Review ein Ziel, macht die Antwort überprüfbar und hinterlässt eine nachvollziehbare Spur, wenn etwas manuell kontrolliert werden muss.
Zuerst zwei unabhängige Reviews, dann der Cross-Review
Ich zeige dem zweiten Modell anfangs nicht die Antwort des ersten. Sonst wäre der zweite Review weniger unabhängig; gerade eine überzeugend klingende erste Erklärung kann ein Modell ungewollt in eine bestimmte Richtung lenken.
Stattdessen erhalten Fable 5.1 und Astra dasselbe Briefing und bearbeiten es getrennt voneinander. Beide können den relevanten Code, die Policies, die API-Oberfläche und den Projektkontext untersuchen. Beide schreiben ihre Erkenntnisse in dieselbe Ergebnisaufgabe — aber keines beginnt mit der Schlussfolgerung des anderen Modells.
Erst dann folgt der zweite Durchgang. Jedes Modell erhält die Analyse des anderen und soll mehr tun, als sie nur zusammenzufassen:
- Erkenntnisse bestätigen, die durch den Code belegt sind;
- Erkenntnisse hinterfragen, die auf einer Annahme beruhen;
- einen fehlenden Angriffspfad oder Testfall ergänzen;
- die Punkte benennen, die weiterhin eine menschliche Entscheidung oder manuelle Prüfung brauchen.
Das Ergebnis ist nicht, dass ein Modell selbstbewusster klingt als das andere. Es ist ein Review, in dem Übereinstimmungen, Widersprüche und Belege sichtbar werden.
Was Astra in der Praxis verändert hat
Das Muster, das ich beobachte, besteht nicht darin, dass Astra einen dramatisch längeren Bericht schreibt. Es bleibt eher so lange bei einer engen Frage, bis die Bedingungen drumherum klar sind.
Bei einer Autorisierungsprüfung kann das bedeuten, die Regel selbst von den Annahmen zu trennen, auf denen sie beruht: Welche Identität erreicht die Policy? Wo wird diese Identität festgestellt? Umgeht eine privilegierte Route die erwartete Prüfung? Und gilt dieselbe Einschränkung für Schreibzugriffe genauso wie für Lesezugriffe? Genau diese Lücken übersieht man leicht, wenn ein Review nur dem vorgesehenen Nutzerablauf folgt.
Fable bleibt in diesem Prozess wertvoll. Es liefert oft ein starkes erstes Gesamtbild und hilft dabei, Erkenntnisse in konkrete Maßnahmen zu übersetzen. Astra hat sich seinen Platz verdient, weil es eine wirklich unabhängige Perspektive ergänzt und nicht nur dieselbe Antwort etwas anders formuliert.
Warum der Ablauf in boostN praktisch ist
Manuell wäre dieser Ablauf mühsam. Du müsstest getrennte Prompts aufsetzen, die Ergebnisse des ersten Durchgangs aufbewahren, sie an die anderen Reviewer verteilen, nachhalten, welches Modell welche Aussage infrage gestellt hat, und schließlich mehrere Unterhaltungen in einen brauchbaren Bericht überführen.
boostN ist dafür gebaut, diesen Ablauf wiederholbar zu machen.
Ich definiere den Test einmal, wähle die Modelle aus und gebe allen dieselbe Aufgabe. Ihre unabhängigen Analysen landen in einer gemeinsamen Ergebniskarte, statt in getrennten Chats zu verschwinden. Von dort starte ich den Cross-Review: Jedes Modell prüft die Erkenntnisse der anderen anhand der ursprünglichen Aufgabe und der verfügbaren Belege.
Darum geht es bei diesem Workflow. Nicht darum, mehr Modellmeinungen zu sammeln, sondern unabhängige Analysen und gegenseitige Prüfung als einen strukturierten Prozess einfach ausführbar zu machen.
Das Endergebnis kann dann zwischen bestätigten und strittigen Erkenntnissen, Belegen, empfohlenen Korrekturen und den Punkten unterscheiden, die ein tieferes menschliches Audit brauchen. Das ist wesentlich nützlicher als eine einzelne Antwort mit dem Etikett „Security-Review“.
Zeit und Kosten
Eine gründliche Prüfung braucht trotzdem Zeit. Wie viel, hängt von der Größe des Systems und dem Dokumentationsumfang des Abschlussberichts ab. In meinem aktuellen Nutzungsfenster von ungefähr fünf Stunden schaffe ich normalerweise zwei oder drei fokussierte Reviews dieser Art. Bei einem besonders verworrenen Bereich kann eine einzige vollständige Analyse die richtige Grenze sein.
In einem typischen Produkt gibt es nicht unendlich viele Hochrisikobereiche. RLS, API-Autorisierung, Mandantengrenzen, Rollenwechsel, Dateizugriffe und einige wichtige Workflows decken einen großen Teil des ersten Durchgangs ab. Selbst wenn ich nur einen dieser Bereiche pro Tag prüfe, können die wichtigsten Oberflächen innerhalb einer Woche unabhängig geprüft und einem Cross-Review unterzogen sein.
Für einen Monatspreis von 25 Euro ist das ein bemerkenswerter Hebel. Es ist nicht mit der Beauftragung eines Cybersecurity-Spezialisten vergleichbar. Ein Spezialist bringt breitere Erfahrung, tieferes adversariales Urteilsvermögen und eine Verantwortung mit, die ein Modell nicht übernehmen kann. Ein Modell kann ein System auch nicht als sicher zertifizieren.
Für einen disziplinierten Basischeck — und um zu entscheiden, wo die Zeit eines Spezialisten tatsächlich gebraucht wird — ist das aber bereits sehr gut.
Diese Grenze ist wichtig
Ich nutze diesen Workflow, um Fragen zu finden und zu priorisieren, nicht um ein System für sicher zu erklären. Hochrisikosysteme, ein vermuteter Sicherheitsvorfall oder ein Compliance-kritischer Release brauchen weiterhin passende menschliche Security-Expertise.
Mein Fazit
Ich würde Astra nicht ohne klaren Auftrag und eindeutige Grenzen auf ein Produktivsystem loslassen. Ich würde es für das genaue Gegenteil einsetzen: den begrenzten Review einer bekannten Oberfläche, zusammen mit einem zweiten Modell, einem dokumentierten Ergebnis und einer Person, die für die endgültige Entscheidung verantwortlich ist.
Darin war es für mich unerwartet stark. Nicht als Ersatz für Security-Expertise, sondern als praktischer Weg, ernsthafte Security-Prüfungen im ersten Durchgang gründlicher zu machen — und deutlich einfacher zu wiederholen.