Welcher Branch-Schutz gelten sollte, wenn Coding-Agenten Pull Requests öffnen

Was sich ändert, wenn ein Agent den Pull Request öffnet

Branch-Schutz wurde für Menschen entworfen: Eine Person schreibt, eine andere gibt frei. Agenten ändern drei Dinge. Der Autor ist ein Tool, das mit dem Token einer Person handelt, und es ist nicht offensichtlich, wer freigeben darf. Agenten pushen häufig, manchmal auch nach einer Freigabe. Und der Agent kann die Dateien ändern, die ihm und der CI sagen, wie sie sich verhalten sollen, darunter Anweisungsdateien und Workflows.

Anweisungen in AGENTS.md oder einem Playbook bitten den Agenten, sich korrekt zu verhalten. Repository-Einstellungen entscheiden, was gemergt werden kann. Dieser Beitrag behandelt diese Einstellungen auf GitHub. Das Review von Agenten-Code ist ein eigenes Thema, das unser Leitfaden zu KI-Code-Review abdeckt.

Eine Grundausstattung für Branches, auf die Agenten zielen

Auf GitHub sind das Einstellungen in einer Branch-Protection-Regel oder einem Ruleset für den Default-Branch und etwaige Release-Branches. Jede Zeile nennt, warum sie mit Agenten wichtiger wird.

• Pull Request mit mindestens einer Freigabe verlangen, damit jede Agenten-Änderung an einem Menschen vorbeikommt.
• Veraltete Freigaben verwerfen, wenn neue Commits den Diff ändern, weil Agenten nach Review-Kommentaren weiter pushen.
• Freigabe des letzten Pushs durch jemand anderen als die Person verlangen, die ihn gepusht hat.
• Review durch Code Owner verlangen, mit benannten Ownern für Agenten-Konfiguration und Workflows.
• Status-Checks für Build und Tests verlangen und, wo möglich, die erwartete Quell-App festlegen.
• Force-Pushes und das Löschen des Branches gesperrt lassen, was eine Protection-Regel standardmäßig tut.
• Do not allow bypassing aktivieren, denn standardmäßig sind Admins und Rollen mit Bypass-Recht ausgenommen.

Pflicht-Checks schwer fälschbar machen

GitHub dokumentiert, dass jede Person und jede Integration mit Schreibrecht den Zustand jedes Status-Checks in einem Repository setzen kann. Ein Agenten-Token mit Schreibzugriff könnte also grundsätzlich einen Pflicht-Check als bestanden melden. Legen Sie für jeden Pflicht-Check die GitHub App als erwartete Quelle fest, die ihn ausführt, damit ein Status von anderer Seite die Regel nicht erfüllt.

Zwei weitere Details zählen. Pflicht-Checks gelten als bestanden, wenn sie successful, skipped oder neutral melden. Ein Check, der auf Agenten-Branches übersprungen wird oder Befunde als neutral meldet, blockiert also nichts. Und Job-Namen sollten über alle Workflows eindeutig sein, weil Dubletten die Ergebnisse mehrdeutig machen und Merges blockieren können.

Festlegen, wer als Autor gilt

Behandeln Sie den Engineer, der einen Agenten gestartet hat, als Autor, damit jemand anderes freigibt. GitHub hat das in Copilot Cloud Agent eingebaut, und nur dort: Wer ihn um einen Pull Request gebeten hat, kann diesen nicht freigeben, der Agent pusht nur auf seinen eigenen copilot/-Branch oder den Branch des Pull Requests und kann weder freigeben noch mergen. Öffnet Copilot einen Pull Request unter seiner eigenen App-Identität, etwa aus einem gemeinsamen Slack-Thread, verlangen Rulesets standardmäßig eine zusätzliche Freigabe. GitHub kennzeichnet diese Einstellung als Public Preview.

Andere Agenten pushen mit der Identität, die Sie ihnen geben: ein persönliches Token, ein Bot-Konto oder eine GitHub App. Prüfen Sie, dass sie keine Admin-Rolle hat, auf keiner Bypass-Liste steht und keine Rulesets ändern kann. Sehen Sie sich dann an, wen die Regel zum letzten Push tatsächlich ausschließt. Erscheinen Commits unter dem Konto des Engineers, schließt sie diesen Engineer aus. Pusht der Agent als Bot oder App, schließt sie nur den Bot aus, und der Engineer, der den Lauf gestartet hat, kann weiterhin freigeben. Lassen Sie in diesem Fall das System, das den Agenten startet, festhalten, wer ihn gestartet hat, und ergänzen Sie einen Pflicht-Check, gemeldet von einer App unter Ihrer Kontrolle, der fehlschlägt, solange die Freigabe dieser Person die einzige ist.

Die Dateien schützen, die den Agenten steuern

GitHubs Leitfaden zu Schutzmaßnahmen für Copilot empfiehlt, Agenten- und MCP-Konfigurationsdateien mit CODEOWNERS und verpflichtendem Code-Owner-Review zu schützen. Dasselbe gilt für CI-Workflows und für CODEOWNERS selbst. Pull Requests verwenden die CODEOWNERS-Datei aus dem Basis-Branch, deshalb kann ein Agent im selben Pull Request seine eigenen Reviewer nicht ändern.

/AGENTS.md                         @example-org/platform
/CLAUDE.md                         @example-org/platform
/.claude/                          @example-org/platform
/.cursor/rules/                    @example-org/platform
/.github/copilot-instructions.md   @example-org/platform
/.github/workflows/                @example-org/platform
/.github/CODEOWNERS                @example-org/platform

Rulesets können außerdem Freigaben bestimmter Teams verlangen, wenn ein Pull Request bestimmte Pfade berührt, etwa das Security-Team bei Authentifizierungscode. So entsteht eine pfadbasierte Regel, ohne sich allein auf die Reihenfolge in CODEOWNERS zu verlassen.

Die Einstellungen in einem Test-Repository prüfen

Einstellungen verändern sich und überlagern sich. Mehrere Rulesets auf einem Branch werden zusammengeführt, und es gilt jeweils die strengste Version einer Regel, zusätzlich zu einer etwaigen Branch-Protection-Regel. Die Konfiguration nur zu lesen reicht nicht, deshalb testen wir sie mit der echten Identität des Agenten in einem Wegwerf-Repository, das die Produktionsregeln übernimmt:

1. 1

   Auf den geschützten Branch pushen

   Ein direkter Push mit dem Token des Agenten muss scheitern.

2. 2

   Die Arbeit des eigenen Agenten freigeben

   Der Engineer, der den Lauf gestartet hat, gibt dessen Pull Request frei, und der Merge muss blockiert bleiben. Copilot setzt das selbst durch; bei anderen Agenten gilt es nur, wenn Ihr Check auf den Initiator eingerichtet ist.

3. 3

   Nach der Freigabe pushen

   Ein neuer Agenten-Commit nach der Freigabe muss eine erneute Freigabe erfordern.

4. 4

   Einen Status fälschen

   Einen Pflicht-Check über die Commit-Status-API mit dem Token des Agenten auf success zu setzen, darf den Merge nicht freigeben.

5. 5

   Eine Steuerdatei ändern

   Markieren Sie den Test-Pull-Request als bereit zum Review, da Code Owner bei Entwürfen nicht angefragt werden. Eine Änderung an AGENTS.md oder einem Workflow muss dann das Plattform-Team anfragen, und der Merge muss blockiert bleiben, bis jemand von dort freigibt.

Wiederholen Sie den Test, wenn Sie einen Agenten hinzufügen, seine Identität ändern oder Rulesets bearbeiten. Solche Einstellungen gehören dazu, wenn wir mit Plattform-Teams Coding-Agenten einführen.