Synthesia setzt Agentenschwarm ein, um sein Produkt Syren in Echtzeit abzusichern

Ein Launch ohne Raum für Shift Left

Laut Synthesia wurde Syren so gebaut, wie heute viel Software entsteht: Ingenieure steuern Coding-Agenten. In den ersten Tagen gab es im Haupt-Repository rund 170 Pull Requests, alle von Agenten geschrieben und von Menschen gemergt. Ein Threat Model und ein Security-Review fehlten, während der Starttermin in den Worten des Unternehmens "in Stein gemeißelt" war.

Gianluca Brindisi, Application Security Engineer bei Synthesia, schreibt, der klassische Ansatz, Sicherheit nach links zu verlagern, funktioniere in diesem Umfeld nicht, denn es gebe kein Links, wohin man verlagern könnte, wenn sich das Design schneller ändert als ein Review-Zyklus. Das Security-Team musste deshalb arbeiten, während das System entstand. Das bedeutete: Hinweise in Echtzeit geben, Fixes direkt beisteuern, kontinuierlich in eine Testumgebung deployen, um schnell zu validieren, und jede Schutzmaßnahme beim Einbau feinjustieren.

Captains und Workers: So funktioniert die Agentenhierarchie

Synthesia hatte bereits darüber geschrieben, wie sich das Schwachstellenmanagement nach der Auslieferung skalieren lässt und wie sich Code-Security-Reviews vor dem Merge automatisieren lassen. Beides sind Pipelines mit festen Phasen. Hier sei es nach Angaben des Unternehmens darum gegangen, dem menschlichen Operator zu helfen, ein aktuelles und korrektes mentales Modell des Systems zu behalten, das es "meat context" nennt. Dafür nutzte man einen selbst entwickelten lokalen Agenten-Orchestrator, der Agenten in einer Hierarchie kleiner Teams anordnet.

Es gibt zwei Arten von Agenten:

• Captains: intelligente, langlaufende Agenten auf dem Host, die jeweils einen Arbeitsbereich verantworten. Sie können Slack, Linear und Observability-Tools lesen, die GitHub CLI nutzen, andere Agenten starten und, wenn erlaubt, Pull Requests öffnen. Der Operator, also der Security Engineer, der die Flotte steuert, kann jederzeit jedem Captain beitreten.
• Workers: Wegwerf-Agenten in einer Sandbox, die jeweils ein schriftliches Briefing erhalten und ein Ergebnis zurückliefern, etwa einen Bericht, Commits oder eine Validierung. Sie haben eine feste Netzwerk-Allowlist, keinen Zugriff auf interne Systeme, keine Push-Rechte und keinen Zugang zur Produktion. Ihr Captain prüft ihre Ergebnisse, bevor sie verwendet werden.

So entstehen zwei Vertrauensstufen: volle Autonomie dort, wo der Schaden begrenzt bleibt, und Aufsicht dort, wo ein Agent auf gemeinsam genutzten Systemen handeln kann. Feature-Flags, die Cloud-Konsole und ein eingeloggter Browser blieben für alle Agenten unerreichbar. Synthesia gibt außerdem an, das Modell jeweils passend zur Aufgabe zu dimensionieren, und da aktuelle Frontier-Modelle viele Cybersecurity-Aufgaben verweigern, habe man diese an Open-Modelle nahe der Frontier delegiert.

Von der Kontextsammlung zum Betrieb

Der erste gestartete Agent war ein Kontextsammler. Er beobachtete die Engineering-Aktivität und die Pull Requests des Produktteams, erstellte eine Karte des Systems mit Komponenten, Verantwortlichen und sich schnell ändernden Bereichen und benachrichtigte das Team, wenn etwas Sicherheitsrelevantes geschah. Synthesia zufolge markierte er im Lauf der Woche mehrere riskante Änderungen. Perfekt war er nicht, manche Meldungen übertrieben Probleme, doch das Verhältnis von Signal zu Rauschen verbesserte sich. Sobald das Team reagierte, lag die mediane Zeit von der Benachrichtigung bis zum Handeln bei etwa 13 Minuten.

Jeder noch unkartierte Bereich wird dann einem neuen Captain zugewiesen, zunächst mit einem kurzen Briefing, Datenflüsse zu kartieren und die aktuelle Implementierung zu prüfen. Dieser Captain entscheidet, wie er die Arbeit auf parallele Workers oder Sub-Captains aufteilt, welches Modell er nutzt, wie er Ergebnisse validiert und wie er einen Fix entwirft, umsetzt, ausrollt und überwacht. Der Prozess ist rekursiv, sodass Captains mit der Zeit eigene Teams aufbauen.

Synthesia beschreibt vier Reifestufen und sagt, ein Bereich könne alle in wenigen Tagen durchlaufen, auch vor und zurück:

• Verstehen: Agenten erklären Komponenten, zeichnen Architekturen und helfen, größere Probleme in der Testumgebung zu validieren.
• Design: Agenten fungieren als Sparringspartner für Threat Modeling und für die Frage, wie sich eine Schutzmaßnahme verhalten soll, auch dazu, wann sie offen oder geschlossen ausfällt. Eine Stunde davon nennt das Unternehmen "einige der wirkungsvollsten Zeit der Woche".
• Engineering: Der Captain schreibt einen Plan, Workers setzen ihn um, und der Captain prüft und öffnet einen Pull Request. Laut Synthesia konnte aus einer Design-Session am Nachmittag bis zum Abend eine gemergte Schutzmaßnahme werden.
• Betrieb: Agenten überwachen die Testumgebung, ermitteln die Ursachen von Fehlern, führen maßgeschneiderte Integrationstests aus, richten Alarme ein und halten Evals am Laufen.

Was das für Security-Teams bedeutet

Der Beitrag stellt den Ansatz als Antwort auf eine konkrete Lage dar: Produkte, die von Ingenieuren gebaut werden, die Coding-Agenten steuern, und bei denen Review-Zyklen nicht mithalten können. Synthesias Position lautet, dass Sicherheitsarbeit die Arbeitsweise der Entwickler spiegeln muss: Agenten übernehmen das Lesen und die Umsetzung, während ein menschlicher Operator das mentale Modell hält und die Entscheidungen trifft.

Das Unternehmen sagt zudem, es habe die Kosten des Ansatzes in Geld und in menschlicher Aufmerksamkeit gemessen. Der hier vorliegende Text bricht vor diesen Zahlen und vor dem Abschnitt zur Bewertung von Schutzmaßnahmen ab, weshalb sie in diesem Artikel nicht wiedergegeben werden. Der Beitrag weist darauf hin, dass die abzusichernden Systeme selbst zunehmend agentisch sind.