Autonome Coding-Agenten.
Kontrollierte Berechtigungen.
Prüfbare Freigaben.
MergeWarden macht aus einem Coding-Agenten einen kontrollierten Entwicklungsprozess: mit genehmigtem Plan, unabhängiger Prüfung, kriteriengebundener Abnahme und einer verbindlichen Schranke vor dem Merge.
Der Agent darf Arbeit vorschlagen und Code ändern. Er entscheidet nicht selbst, ob seine Arbeit freigegeben ist.
- Freigabe an konkreten Plan gebunden
- Zugangsdaten zum Git-Dienst außerhalb des Agenten (Broker-Modus)
- Pipeline prüft unabhängig neu
Der Lebenszyklus
Fünf Schritte, jeder mit eigener Pflicht
Plan
Der Agent schreibt einen Plan. Ein Mensch gibt ihn frei, bevor Code entsteht.
Implementierung
Der Agent arbeitet im Feature-Branch. Der Zustand des Laufs wird dort geführt, nicht im Agenten selbst, der sich jederzeit neu starten kann.
Review
Ein automatisiertes, regelbasiertes Review prüft Architektur, Sicherheit, Testqualität und mehr. Jeder Befund hat eine nachvollziehbare Herkunft.
Abnahme
Die im Ticket festgehaltenen Kriterien werden gegen den tatsächlichen Stand geprüft, nicht gegen eine Behauptung.
Schranke
Gemerged wird erst, wenn jede Pflicht erfüllt ist. Keine Ausnahme, die der Agent sich selbst geben kann.
Abgrenzung
Mehr als ein Review-Agent
| Fähigkeit | Reines MR-Review | MergeWarden |
|---|---|---|
| Prüft den Diff gegen Regeln | Ja, je nach System | Ja |
| Prüft den gesamten Entwicklungsablauf | Nicht notwendigerweise | Plan bis Abnahme und Schranke |
| Bindet Freigabe an einen konkreten Planstand | Nicht notwendigerweise | Ja |
| Behandelt Agentenzustand als nicht vertrauenswürdig | Nicht notwendigerweise | Explizites Architekturprinzip |
| Prüft Akzeptanzkriterien gegen den tatsächlichen Code | Nicht notwendigerweise | Eigener Abnahmeschritt |
| Bewertet unabhängig in der Pipeline neu | Abhängig von der Integration | Bestandteil des Konzepts |
| Hält Zugangsdaten zum Git-Dienst vom Agenten fern | Abhängig von der Architektur | Über den Broker-Modus |
„Ein Review-Agent bewertet eine Änderung. MergeWarden kontrolliert, unter welchen Bedingungen eine Änderung entstehen darf und wie sie geprüft, freigegeben und gemerged wird."
Das Prinzip
„Zustand kann die Pflicht nur erhöhen."
Jeder vom Agenten selbst gemeldete oder beeinflusste Zustand darf eine Anforderung niemals abschwächen, nur verschärfen. Ein Agent kann sich keine Freigabe erschleichen, indem er behauptet, etwas sei schon erledigt oder geprüft. Das ist die Vertrauensgrenze zwischen Agent und Freigabe.
Entscheidet Code, nicht das Modell:
- ob eine Freigabe gültig ist
- ob ein Phasenwechsel erlaubt ist
- ob der Plan jedes Kriterium abdeckt
- ob Tests bestanden sind, und ob dabei welche abgeschwächt wurden
- ob der Merge Request überhaupt angelegt werden darf
Lokal kann der Agent trotzdem einen Review-Fingerabdruck, ein Abnahme-Ergebnis oder einen Rücksprung-Zähler in den Zustand im Branch schreiben. Diese Felder schützen vor Versehen, nicht vor einem Agenten, der sie bewusst umgeht. Gegen diesen Fall hält erst die Pipeline, die jede Bedingung neu aus dem Stand des Git-Dienstes selbst berechnet, und die Code-Freigabe auf dem Host, die sich der Agent für seinen eigenen Merge Request nicht selbst geben kann.
Architektur
Vertrauensgrenzen
Der Agent erreicht den Git-Dienst im Broker-Modus nie direkt. Die Schranke öffnet erst, wenn menschliche Freigabe und unabhängige Pipeline-Prüfung beide vorliegen.
Angriff → Gegenmaßnahme
Sechs konkrete Fälle
Manipulierter Status oder gefälschte Evidenz
Der Agent behauptet, ein Kriterium sei erfüllt oder eine Prüfung sei erfolgt.
MergeWarden. Die Pipeline wertet maßgebliche Bedingungen unabhängig aus; der Agentenzustand kann erforderliche Kontrollen nicht abschwächen.
Plan nach der Freigabe geändert
Ein bereits genehmigter Plan passt nicht mehr zum aktuellen Inhalt.
MergeWarden. Die Planfreigabe ist an den bestätigten Planstand gebunden; eine Änderung macht die alte Freigabe ungültig.
Agent kompromittiert oder durch Prompt Injection beeinflusst
Der Agent versucht, über seine eigentliche Aufgabe hinaus auf privilegierte Aktionen zuzugreifen.
MergeWarden. Im Broker-Modus vermittelt der Runner definierte Operationen, statt Zugangsdaten zum Git-Dienst direkt an den Agenten zu übergeben.
Akzeptanzkriterium nur auf dem Papier erfüllt
Ein Plan ordnet einem Kriterium eine Lösung zu, die tatsächliche Implementierung erfüllt es aber nicht.
MergeWarden. Die Abnahme prüft das Kriterium gegen den tatsächlichen Stand, nicht allein gegen die Zuordnung im Plan.
Manipuliertes Ticket versucht, auf Zugangsdaten oder Netzwerk zuzugreifen
Ein präparierter Tickettext versucht, den Agenten zum Lesen von SSH-Schlüsseln, Cloud-Zugangsdaten oder beliebigen Netzwerkzielen zu bewegen.
MergeWarden. Ein Sicherheitsprofil sperrt Zugangsdaten-Dateien, Umgebungsvariablen nach Default-Deny und das Netzwerk auf eine Erlaubnisliste. Startet die Sandbox nicht, startet der Agent nicht.
Manipulierter Titel oder Beschreibung des Merge Requests
Ein Angreifer versucht, den automatisierten Prüfer über den Text des Merge Requests zu steuern.
MergeWarden. Titel, Branch-Name und Beschreibung werden nie in Skripte eingesetzt. Der Prüfer hat kein Bash, WebFetch oder WebSearch, nur Lesezugriff auf die Eingabe.
Für wen
Teams, die Agenten produktiv einsetzen, ohne blindes Vertrauen
MergeWarden ist für Teams, die KI-Coding-Agenten echte Aufgaben übernehmen lassen, aber nicht nur auf deren Einhaltung von Anweisungen vertrauen wollen. Die Schranken gelten unabhängig davon, welches Modell oder welcher Anbieter den Agenten antreibt.
agentenagnostischNutzen nach Rolle
Für jede Rolle ein anderer Grund
Entwickler:in
Der Agent arbeitet weitgehend eigenständig; du wirst nur eingebunden, wenn es wirklich zählt, bei der Planfreigabe und am Ende beim Freigabeschritt. Kein ständiges Mitlesen jedes Zwischenschritts nötig.
Entwicklungsleitung
Weniger Rückfragen und Korrekturschleifen, weil Regeln schon in der Planung gelten. Jeder Befund ist nachvollziehbar (Modell, Aufwand, Herkunft), keine undurchsichtige Bewertung.
IT-Sicherheit
Zugangsdaten zum Git-Dienst bleiben im Broker-Modus außerhalb des Agenten. Das Review-Ziel "Sicherheit" läuft immer und lässt sich nicht abschalten. Jede Freigabe ist an einen konkret geprüften Stand gebunden, nicht an eine Behauptung.
Plattformteam
Projektspezifisch erweiterbares Regelwerk, ohne eine eigene Kopie des gesamten Plugins pflegen zu müssen. Läuft auf GitLab und GitHub. Konfiguration lebt im Repo selbst, nicht in externer Infrastruktur.
Unternehmensleitung
Agenten arbeiten produktiv, ohne dass Freigabeprozesse aufgeweicht werden. Nachvollziehbare Spur durch Herkunft und Ticket-Bindung. Keine Abhängigkeit von einem einzelnen Modellanbieter.
Integrationsstatus
Was heute schon läuft
Das Vertrauensmodell ist agentenagnostisch. Jeder Agent, der einen Merge Request über den normalen Git-Ablauf öffnet, lässt sich an die Schranke binden. Verfügbar ist die Integration heute für Claude Code.
- GitLab-CI. Aktiv erprobt, die eigene Produktivpipeline von MergeWarden läuft darüber.
- GitHub Actions. Referenzvorlage vorhanden.
prepareund alle Reviewer liefen mit echtem Modell in echtem GitHub Actions korrekt durch. Der volle Durchlauf vonevaluate/gatebis zum tatsächlichen Blockieren eines Merges über die Branch-Protection ist noch offen. - Regelwerk. Projektspezifisch erweiterbar, eigene Review-Ziele und Freigaberegeln kommen einfach dazu, bestehende lassen sich ersetzen oder abschalten.
- Prüfer-Modell und -Aufwand. Projektseitig einstellbar.
Preise
Lizenzmodell
Gestaffelt nach Teamgröße und Anzahl der Repositories, nicht nach Pipeline-Läufen.
| OSS | Single | Team | Business | Enterprise | |
|---|---|---|---|---|---|
| Preis | kostenlos | ||||
| Umfang | Single-Lizenz pro Projekt | 1 Entwickler:in | bis 10 | bis 50 | individuell |
| Repositories | 1 öffentliches Open-Source-Projekt | bis 2 | bis 5 | bis 25 | unbegrenzt |
| Git-Dienst | GitHub oder GitLab | GitHub oder GitLab | GitHub oder GitLab | beide | beide |
| Support | Community | Community | priorisiert | SLA, Onboarding, Audit |
OSS gilt für ein öffentliches Repository unter einer anerkannten Open-Source-Lizenz. Laufzeit der übrigen Stufen: 12 Monate, automatische Verlängerung mit Kündigungsfrist. Die Modellkosten trägt der Kunde selbst über einen eigenen API-Zugang, MergeWarden verkauft die Kontrollschicht, nicht Rechenzeit. Vor Vertragsabschluss empfiehlt sich ein Pilotlauf von Ticket bis Merge Request, siehe Demo unten.
Demo
Was du in der Demo siehst
Ein echter Durchlauf an einem realen Ticket: ein genehmigter Plan, die Implementierung im Feature-Branch, ein Review-Lauf mit einem blockierenden Befund und die anschließende, erfolgreiche Freigabe, sobald alle Pflichten erfüllt sind. Die Demo dauert 45 bis 60 Minuten, du musst nichts vorbereiten, wir führen den Durchlauf vor.
FAQ
Noch Fragen?
Funktioniert das mit dem Coding-Agenten, den ich schon nutze?
MergeWarden läuft heute als Claude-Code-Plugin. Die Schranke, die Pipeline-Prüfungen und der Broker-Modus sind nicht an einen Hersteller gebunden. Jeder Agent, der einen Merge Request über den normalen Git-Ablauf öffnet, lässt sich auf dieselbe Weise an die Schranke binden. Unterstützung für andere Agenten-Laufzeiten ist eine Frage der Integration, nicht des Vertrauensmodells.
Wo läuft die Arbeit des Agenten tatsächlich, auf meinem Rechner oder woanders?
Dort, wo du den Runner betreibst: auf dem eigenen Rechner, in der eigenen CI oder auf einem
selbst betriebenen GitLab- oder GitHub-Runner. MergeWarden betreibt keinen gehosteten Dienst,
der den Code ausführt. Im Standardzugang hält der Agent selbst nie Zugangsdaten zum Git-Dienst,
ein eigener Broker-Prozess spricht stattdessen mit dem Git-Dienst. Diesen Broker-Modus gibt es
für GitHub und GitLab. Wer dem Agenten bewusst ein eigenes Token geben will, kann das mit
zugang = "direkt" explizit einstellen.
Führt die Pipeline meine Projekttests aus?
Nein, die agentische Prüfung checkt den Code des Merge Requests nie aus und führt ihn nicht aus, sie liest den Diff nur als Text. Klassische Unit-Tests sind davon unabhängig. Du kannst sie als ganz normalen CI-Job vor oder neben der agentischen Prüfung laufen lassen, zum Beispiel in derselben Pipeline. Die Schranke selbst prüft nicht, ob dieser Job grün ist, das trägst du selbst als Pflicht-Check in der Branch-Protection ein.
Was passiert, wenn der Review-Schritt nicht durchläuft, etwa bei einem Modellausfall oder einem Session-Limit?
Die Schranke verlangt dann standardmäßig ein menschliches Review, statt trotzdem zu mergen. Eine fehlende oder fehlgeschlagene Prüfung zählt als "nicht erfüllt", nicht als "übersprungen".
Ist das dasselbe wie ein Review-Bot oder ein Linter?
Ein Review-Bot fügt eine Prüfung hinzu. MergeWarden fügt eine Schranke vor dem Merge hinzu. Plan, Implementierung, Review und Abnahme laufen als feste Abfolge, und die eigenen Statusmeldungen des Agenten können die Anforderung vor dem Merge nur erhöhen, nie senken. Die sechs Angriffsfälle oben zeigen, was diese Grenze abdeckt und was nicht.