Multi-Agenten-Systeme für Codesicherheit und Review: Rollen, Risiken und Governance

Wann mehrere Agenten Codesicherheit und Review wirklich verbessern

Multi-Agenten-Systeme für Codesicherheit und Review helfen, wenn sie echte Unabhängigkeit erzeugen. Mehr parallele Agenten machen ein Review nicht automatisch gründlicher. Der Sicherheitsgewinn entsteht erst, wenn Rollen getrennt sind, jeder Agent eine klare Aufgabe hat, Belege sichtbar bleiben und ein Mensch die finale Merge-Verantwortung behält.

Für Code-Reviews ist das besonders wichtig. Ein Implementierungsagent optimiert auf Lösung und Geschwindigkeit. Ein Prüfagent muss anders arbeiten: Er sucht Randfälle, gefährliche Berechtigungen, unsichere Abhängigkeiten, Datenabflüsse, fehlende Tests und falsche Annahmen. Wenn beide Agenten denselben Kontext, dieselben Zwischenschlüsse und dieselben Werkzeuge ungefiltert teilen, entsteht schnell nur eine beschleunigte Einheitsmeinung.

Anthropic beschreibt in der aktuellen Forschung zu Multi-Agenten-Systemen, veröffentlicht am 13. August 2026, wie Leistung stark von Koordination abhängt und wie Kommunikation, geteilte Ressourcen und Konvergenz das Verhalten mehrerer Agenten prägen. Für Softwareteams ist das keine abstrakte Forschungsnotiz. Es betrifft Pull Requests, Security-Fixes, Abhängigkeitsupdates und produktive Deployments.

Unsere Produktlektion aus FoneClaw ist ähnlich: Autonomie wird erst nützlich, wenn sie begrenzt, prüfbar und abbrechbar bleibt. Bei Code-Agenten bedeutet das Diffs, Tests, Logs und Review-Kommentare. Bei Phone Agents bedeutet es sichtbare Telefonaktionen, Freigaben und Wiederherstellung. Wer Identität, Berechtigungen und Belege tiefer modellieren möchte, findet die passende Grundlage in Identität von KI-Agenten: Berechtigungen, Genehmigungen und Audit-Trails für Phone Agents, weil dieselben Nachweisfragen auch im Code-Review zählen.

Coordinator, Worker, Reviewer und menschliche Merge-Verantwortung

Eine robuste Topologie beginnt mit einem Coordinator. Diese Rolle schneidet die Aufgabe, definiert den Scope, hält den Threat Model fest und entscheidet, welche Agenten welche Werkzeuge sehen. Der Coordinator sollte nicht gleichzeitig stillschweigend jede Änderung absegnen. Seine Stärke liegt in Aufgabenführung, nicht in der Ersetzung von Review.

Worker-Agenten erledigen abgegrenzte Teile: eine Abhängigkeit aktualisieren, Tests ergänzen, einen Parser härten, eine Authentifizierungsgrenze prüfen oder Dokumentation anpassen. Jeder Worker braucht nur den Kontext, der für seine Aufgabe nötig ist. Bei Code ist das oft ein kleiner Worktree-Ausschnitt, ein Issue, ein Testziel und eine begrenzte Befehlsliste. Bei schwach geschnittenen Aufgaben entsteht dagegen ein klassisches Multi-Agent-Problem: mehrere Agenten arbeiten gleichzeitig am selben Zustand, überschreiben Annahmen oder produzieren Änderungen, die einzeln plausibel und zusammen riskant sind.

Der Reviewer braucht Distanz. Ein unabhängiger Prüfagent sollte nicht jeden Gedankengang des Implementierungsagenten übernehmen, bevor er den Diff selbst gesehen hat. Sonst verliert das Review seinen Wert. Besser ist ein zweiter Pfad: Der Reviewer bekommt Scope, Patch, Tests, relevante Logs, Sicherheitsanforderungen und bekannte Risiken, aber nicht die gesamte Überzeugungsarbeit des Implementierers. So bleibt Widerspruch möglich.

Die menschliche Merge-Rolle bleibt der letzte Gatekeeper. Ein Claude Code Multi-Agenten-System kann Arbeit vorbereiten, Befunde sammeln und Alternativen darstellen. Die Entscheidung, ob ein sicherheitsrelevanter Patch gemergt, zurückgestellt oder neu geschnitten wird, gehört einer verantwortlichen Person oder einem klar benannten Team. Für länger laufende Evaluationsschleifen ist unser Leitfaden Selbstverbessernde Phone Agents: Skill-Versionen, Tests und Rollback hilfreich, weil er zeigt, wie Tests, Versionierung und Rücknahme als Governance-Praxis zusammenwirken.

Koordinationsfehler, gemeinsame Ressourcen, Konformität und Kollusion

Anthropics Forschung macht vier Risiken greifbar, die Softwareteams bei Multi-Agenten-Governance ernst nehmen sollten. Das erste ist Koordinationsversagen. Agent A nimmt an, dass Agent B eine Prüfung übernimmt. Agent B nimmt an, dass der Coordinator den Konflikt später erkennt. Am Ende gibt es viele Aktivitäten, aber keinen klaren Besitzer für die Sicherheitsfrage. In Code-Reviews zeigt sich das als fehlender Test für genau den kritischen Pfad, als ungeklärte Migrationsfolge oder als Patch, der nur im lokalen Kontext funktioniert.

Das zweite Risiko sind gemeinsame Ressourcen. Shared Worktrees, globale Caches, Paketmanager, Datenbanken, Secrets, Browser-Sessions, CI-Queues und temporäre Dateien können Agenten gegenseitig beeinflussen. Ein Prüfagent, der denselben veränderten Zustand wie der Worker nutzt, bestätigt möglicherweise nur dessen Umgebung. Ein Agent, der Credentials für mehrere Aufgaben sieht, erweitert unbeabsichtigt die Angriffsfläche. Deshalb brauchen geteilte Ressourcen Eigentümer, Sperren, Logs und Rücksetzpunkte.

Das dritte Risiko ist Konformität. Mehrere Agenten können scheinbar unabhängig wirken und trotzdem schnell zur gleichen Schlussfolgerung driften. Kommunikation hilft beim Koordinieren, kann aber nützliche Varianz abbauen. Für Code-Sicherheit ist Varianz wertvoll: Ein Agent liest den Diff wie ein Maintainer, ein anderer wie ein Angreifer, ein dritter wie ein Betriebsteam. Wenn alle zuerst denselben optimistischen Plan sehen, sinkt die Chance, dass jemand die unangenehme Frage stellt.

Das vierte Risiko ist Kollusion im weiten Governance-Sinn: Agenten können durch Kommunikation Verhalten stabilisieren, das dem Prüfziel widerspricht. Das heißt nicht, dass jede Kommunikation gefährlich ist. Kommunikation löst echte Koordinationsprobleme. Sie wird riskant, wenn Reviewer ihre Unabhängigkeit verlieren, wenn Agenten gemeinsam einen schwachen Nachweis als ausreichend behandeln oder wenn ein System Konsens höher bewertet als Evidenz. Eine gute Sandbox hilft, aber sie ersetzt keine klare Berechtigungsgrenze. Den Unterschied zwischen Ausführungsgrenzen und Telefonberechtigungen vertieft KI-Agent-Sandbox und Telefonberechtigungen: Warum sichere Agenten Grenzen brauchen.

Ein unabhängiger Multi-Agent-Workflow für Code-Sicherheitsreviews

Ein operationaler Workflow beginnt vor der Implementierung. Der Coordinator formuliert Scope, Nicht-Ziele, relevante Datenflüsse, betroffene Berechtigungen, Abhängigkeiten, Rollback-Weg und Akzeptanztests. Bei sicherheitsrelevanten Änderungen gehört ein kurzer Threat Model dazu: Welche Assets sind betroffen, welche Angreiferannahme gilt, welche Fehlerklasse soll verhindert werden?

Danach arbeitet der Implementierungsagent in einem eigenen Worktree oder Branch. Er darf schreiben, Tests ausführen und lokale Belege sammeln. Seine Ausgabe ist nicht nur Code, sondern ein Paket aus Diff, Testbefehlen, bekannten offenen Punkten und Annahmen. Ein guter Worker markiert, wo er unsicher ist. Diese Unsicherheit ist kein Makel; sie ist Material für das Review.

Der Prüfagent startet getrennt. Er bekommt den Patch, die Sicherheitsziele und die erwarteten Belege. Er prüft Diffs, Tests, Berechtigungen, Dependency-Änderungen, Secret-Exposition, Logging, Fehlerpfade, Migrationen und rückwärtskompatibles Verhalten. Er darf ablehnen, zusätzliche Tests verlangen oder den Scope zurück an den Coordinator geben. Ein KI-Agenten-Review ist erst nützlich, wenn der Prüfagent echte Autorität hat, nicht nur eine Zusammenfassung liefert.

Für besonders riskante Änderungen lohnt sich ein adversarialer zweiter Reviewer. Dieser Agent sucht nicht nach Eleganz, sondern nach Missbrauch: Prompt-Injection-Flächen, unsichere Deserialisierung, zu breite Tokens, fehlende Rate Limits, unerwartete Dateioperationen oder fehlerhafte Rollenprüfung. Die Ergebnisse beider Reviewer bleiben getrennt sichtbar. Erst danach entscheidet der Mensch über Merge, Nacharbeit oder Rollback. Bestehende Tests sind dabei notwendig, aber kein Sicherheitsbeweis. Sie zeigen nur, dass bestimmte erwartete Pfade laufen.

Aus FoneClaw-Sicht ist dieser Ablauf vertraut. Wir bauen Produktfunktionen so, dass Vorbereitung, Ausführung, Freigabe und Wiederherstellung unterscheidbar bleiben. Code-Review braucht dieselbe Disziplin: nicht alles in eine große Agentenantwort werfen, sondern Entscheidungen an den Stellen sichtbar machen, an denen Risiko entsteht.

Tools, Credentials, Worktrees, Warteschlangen und Budgets begrenzen

Containment beginnt mit einer Capability Snapshot: Welche Dateien, Befehle, Netzwerke, Secrets, Paketquellen, Datenbanken und externen Dienste darf ein Agent in dieser Aufgabe nutzen? Diese Liste sollte klein sein und zur Rolle passen. Ein Lese-Reviewer braucht andere Rechte als ein Implementierer. Ein Dependency-Agent braucht andere Grenzen als ein Agent, der Auth-Code anfässt.

Worktrees und Credentials sollten getrennt werden. Ein Agent, der eine riskante Bibliothek aktualisiert, sollte nicht gleichzeitig Produktions-Credentials, Release-Schlüssel oder offene Browser-Sessions sehen. Shared mutable state ist einer der praktischen Wege, wie Multi-Agenten-Systeme unerwartet unsicher werden. Deshalb gehören Locks, eindeutige Besitzer und saubere Reset-Punkte zur Review-Umgebung.

Queues und Budgets sind ebenfalls Sicherheitskontrollen. Zeit- und Tokenlimits verhindern endlose Schleifen. Task-Queues verhindern, dass mehrere Agenten denselben externen Effekt parallel auslösen. Ein Stop-Knopf ist wichtig, aber er macht bereits abgeschlossene externe Effekte nicht rückgängig. Eine gesendete Nachricht, ein veröffentlichter Release oder ein gelöschter Datensatz braucht eigene Rücknahme- oder Incident-Prozesse.

Bei FoneClaw haben wir aus Telefonaufgaben gelernt, dass Warteschlangen, sichtbare Zustände und Wiederholversuche produktrelevant sind. Ein Telefonagent muss wissen, welcher Auftrag läuft, welcher wartet und welcher gestoppt wurde. Die Mechanik hinter isolierten Telefonaufgaben vertieft KI-Agenten-Warteschlangen auf Android sicher nutzen. Für Code-Agenten gilt dasselbe Prinzip: Ein Task ist eine kontrollierte Einheit mit Besitzer, Budget, Werkzeugen, Belegen und Abschlusszustand.

Was diese Governance für Android Phone Agents bedeutet

Die Analogie zu Phone Agents ist Governance, nicht Architekturbehauptung. Ein Claude Code Multi-Agenten-System ist ein Code-Workflow. FoneClaw ist unser Android Phone Agent für unterstützte, kontrollierte Telefonaufgaben. Die gemeinsame Lektion liegt in Verantwortung, Begrenzung und Sichtbarkeit.

Telefonwirkungen sind empfindlich, weil sie persönliche Kommunikation, Kalender, Standort, Geräteeinstellungen, Apps und Benachrichtigungen berühren können. Darum bauen wir FoneClaw um sichtbare Freigaben, Aufgabenisolierung, Stoppen, Wiederholen und Berechtigungswiederherstellung. Wenn eine Aktion unterstützt ist, soll der Nutzer sehen, was vorbereitet wird. Wenn eine Berechtigung fehlt, führt FoneClaw in einen verständlichen Wiederherstellungspfad. Wenn ein Schritt riskant oder unklar ist, bleibt der Nutzer in der Entscheidung.

Auch Capability Snapshots sind für Telefonaufgaben wertvoll. Ein Agent sollte nicht aus einer erfolgreichen Aktion ableiten, dass er dauerhaft alles darf. Unterstützte Tools, App-Zustand, Android-Berechtigungen und Nutzerfreigaben bilden den aktuellen Handlungsspielraum. Auf der deutschen FoneClaw-Funktionsseite pflegen wir die aktuellen unterstützten Fähigkeiten; die deutsche FoneClaw-Downloadseite hält Installations- und Verfügbarkeitsinformationen aktuell.

Aus unserer Builder-Perspektive ist Multi-Agenten-Governance deshalb kein Spezialthema für Forschungslabore. Sie zeigt, wie man jede agentische Ausführung entwirft: Wer besitzt die Aufgabe, welche Ressource wird berührt, welche Zustimmung ist nötig, welcher Beleg bleibt sichtbar und wie kommt der Nutzer nach einem Fehler wieder weiter? Genau diese Fragen leiten auch unsere Approval-UX. Für das Produktdenken hinter Freigabe und Vertrauen passt KI-Agent-Freigaben auf dem Telefon: Vertrauen durch sichtbare Begründung als weiterführende Einordnung.

Release-Checkliste für Multi-Agent-Code-Reviews

Vor dem Lauf: Benennen Sie Coordinator, Worker, Reviewer und menschliche Merge-Verantwortung. Fixieren Sie Scope, Threat Model, erlaubte Tools, betroffene Ressourcen, Budgets, Stop-Bedingungen und Rollback-Weg. Legen Sie fest, welche Belege am Ende vorliegen müssen.

Während des Laufs: Halten Sie Worktrees, Credentials und Queues getrennt. Lassen Sie Implementierer und Reviewer nicht unnötig früh konvergieren. Kommunikation soll Koordination ermöglichen, aber unabhängige Befunde erhalten. Jeder Agent braucht einen klaren Abschlusszustand: erledigt, blockiert, abgelehnt oder eskaliert.

Vor dem Merge: Prüfen Sie Diff, Tests, Sicherheitsannahmen, Berechtigungen, Dependencies, Secrets, Logs, Migrationspfade und Monitoring. Der Reviewer darf Nacharbeit verlangen. Der Mensch entscheidet, ob der Patch reif ist, ob ein engerer Scope nötig wird oder ob ein Rollback vorbereitet werden muss.

Nach einem Incident: Rekonstruieren Sie nicht nur den fehlerhaften Code, sondern auch den Agentenablauf. Welche Ressource war geteilt? Welche Annahme wurde übernommen? Welche Prüfung fehlte? Welche Stop-Bedingung kam zu spät? Diese Nacharbeit macht Multi-Agenten-Governance besser, ohne zu behaupten, dass eine Checkliste Sicherheit garantiert.

Quellen: Dieser Artikel nutzt Anthropic Research zu Multi-Agenten-Systemen, veröffentlicht am 13. August 2026 und für diesen Artikel am 16. August 2026 geprüft, sowie die aktuellen FoneClaw-Seiten zu Funktionen und Download.