Schutzmechanismen im Repository

Schutzmechanismen im Repository

0:00 Bisher haben wir vor allem lokal gearbeitet. Das war richtig, denn dort entstehen die Probleme und dort sind sie am billigsten zu lösen. Aber alles, was wir bisher eingerichtet haben, hat eine gemeinsame Eigenschaft: Es lässt sich abschalten. Ein Hook wird übersprungen, eine Vorlage ignoriert. Für den letzten Teil dieses Seminars wechseln wir deshalb die Seite.

0:21 Wir gehen dorthin, wo Regeln nicht mehr freundliche Empfehlungen sind, sondern technisch durchgesetzt werden — auf den Server. Und wir klären eine Frage, die unbequem ist: Was darf ein Agent eigentlich, der unter Ihrem Zugang läuft?

Grenzen, die auch für Agenten gelten

0:35 Drei Themen und ein Rückblick. Zuerst die Grundlage: warum Zugriffsrechte das eigentliche Risiko sind und welche zwei Muster seit Jahrzehnten dagegen helfen. Dann Branch Protection — die Regeln, die jeder große Git-Anbieter anbietet und die die wenigsten vollständig nutzen. Danach die Zugangstoken, mit denen ein Agent überhaupt erst auf das entfernte Repository kommt.

0:56 Und zum Schluss sehen wir uns an, was in sechs Modulen entstanden ist und womit Sie am besten anfangen. Vier Ergebnisse. Sie verstehen, warum ein Agent alle Rechte seines Auftraggebers erbt — und warum das keine Frage des Vertrauens ist, sondern eine der Technik. Sie setzen Branch Protection gezielt gegen unkontrollierte Änderungen ein. Sie schneiden Zugangstoken nach dem Prinzip der geringsten Rechte zu.

1:21 Und Sie können abwägen, wann ein eigenes Konto für den Agenten sinnvoll ist und wann es nur Kosten verursacht. Das meiste davon sind Einstellungen, keine Projekte. Der Aufwand ist gering, die Wirkung erheblich.

Warum Repository-Schutz

1:34 Beginnen wir mit dem Grundproblem. Es hat einen Namen, und der klingt harmloser, als er ist: Identitätsübernahme. Wer einem Agenten Zugriff gibt, gibt ihm nicht ein bisschen Zugriff. Ein Agent, den Sie autorisieren, erbt genau Ihre Zugriffe. Er kann jeden Befehl ausführen, den Sie ausführen könnten, und jede Ressource erreichen, die Sie erreichen.

1:56 Stellen Sie sich vor, Sie geben jemandem Ihren Schlüsselbund, um ein Paket in den Flur zu stellen. Sie haben nicht den Flurschlüssel übergeben, sondern alle. Ob das gutgeht, hängt danach nicht mehr an Ihrer Absicht. Genau so ist es hier. Das Risiko liegt nicht in der Bösartigkeit eines Modells — es liegt im Umfang der geliehenen Rechte.

2:17 Vier Punkte, und der erste ist der grundlegende: Ein Agent unterscheidet nicht zwischen erlaubt und beabsichtigt. Was technisch möglich ist, kommt für ihn in Frage. Daraus folgt der zweite: Anweisungen im Prompt sind eine Bitte, keine Schranke. Sie helfen meistens, aber sie halten nichts auf. Der dritte betrifft Sie persönlich — fehlerhafte Aktionen laufen unter Ihrem Namen und Ihrer Verantwortung.

2:40 Und der vierte ist der Grund, warum wir überhaupt darüber sprechen: Es gibt dokumentierte Fälle, in denen Agenten trotz gegenteiliger Anweisung Produktionsdaten gelöscht haben. Das sind keine Gedankenspiele. Zwei Muster, und beide sind deutlich älter als jedes Sprachmodell. Der Mensch in der Schleife bedeutet: Risikoreiche Aktionen brauchen eine Freigabe von jemandem, der nicht selbst gehandelt hat.

3:04 Das Prinzip der geringsten Rechte bedeutet: nur so viel Zugriff, wie die Aufgabe erfordert. Beides ist Sicherheitshandwerk aus Jahrzehnten, und beides ist in jedem Git-Anbieter bereits eingebaut. Das ist die gute Nachricht dieses Moduls. Wir müssen nichts erfinden. Wir müssen nur anwenden, was ohnehin da ist — nur eben konsequenter als früher, weil die Zahl der Handelnden gestiegen ist.

3:28 Fünf Schritte, und die ersten drei kosten praktisch nichts. Risikoreiche Aktionen benennen — löschen, überschreiben, freigeben. Kritische Branches durch Regeln absichern. Freigabe an eine zweite Person binden. Das sind Konfigurationen, keine Projekte; ein Nachmittag genügt. Erst die letzten beiden Schritte haben Substanz: Zugangstoken zuschneiden und entscheiden, ob der Agent ein eigenes Konto bekommt.

3:54 Das ist eine Frage mit Kostenfolge, und deshalb eine, die man nicht nebenbei trifft. Eine Übung, die unangenehm werden darf. Schreiben Sie auf, worauf ein Agent auf Ihrem Arbeitsplatz im aktuellen Zustand zugreifen könnte: welche Repositories, welche Umgebungen, welche Datenbanken. Nicht, worauf er zugreifen soll — worauf er könnte.

4:15 Bei den meisten von uns ist die Liste länger als erwartet, weil sich über Jahre Zugänge angesammelt haben, an die niemand mehr denkt. Der Hinweis sagt es knapp: Die unangenehmen Einträge sind die interessanten. Genau dort lohnt sich der nächste Schritt. Vier Irrtümer. Sicherheitsanweisungen in den Prompt schreiben und für wirksam halten — der bequemste Fehler von allen, weil er sich wie Sorgfalt anfühlt.

4:39 Dem Agenten dieselben Rechte geben wie sich selbst, aus Bequemlichkeit; auch das fühlt sich harmlos an, weil es ja der eigene Zugang ist. Schutz erst nach dem ersten Zwischenfall einrichten — dann allerdings unter Zeitdruck und mit Publikum. Und der vierte, der sich durch dieses ganze Seminar zieht: lokale Absicherung mit verbindlicher Absicherung verwechseln.

Branch Protection

5:00 Kommen wir zu den Regeln auf dem Server. Es gab sie lange, bevor Agenten Code schrieben, und sie sind seither nicht besser geworden — nur wichtiger. Wir sehen uns an, welche davon gegen unkontrollierte Änderungen tatsächlich helfen. Branch Protection sind Regeln, die der Git-Anbieter auf einem Branch erzwingt. Ihr Kern ist ein Gedanke aus der Buchhaltung, und dort heißt er Vier-Augen-Prinzip: Niemand soll allein genug Rechte haben, um einen Vorgang von Anfang bis Ende durchzuwinken.

5:29 Übertragen auf unsere Situation heißt das: Wer Code schreibt, gibt ihn nicht selbst frei. Und weil ein Agent unter Ihrem Zugang läuft, gilt das für ihn genauso. Er ist in dieser Logik keine zweite Person — er ist Sie. Die Anbieter bieten Dutzende Einstellungen, deshalb hier vier Gruppen zur Orientierung. Integrität regelt, wer einen Branch anlegen, ändern und löschen darf.

5:52 Historie sorgt für Nachvollziehbarkeit — lineare Historie, signierte Commits; der zweite Punkt wird gern übersehen, dabei kann ohne Signatur jeder Ihren Namen in seine Konfiguration schreiben. Prüfungen binden Scans, Stil und Testabdeckung ein. Und Dateibezug ist die unterschätzte Gruppe: Sie können Regeln auf bestimmte Pfade beschränken. Das brauchen wir gleich noch.

6:15 Vier Regeln, die zusammengehören. Die eigene Änderung nicht selbst freigeben — bei manchen Anbietern ohnehin nicht abschaltbar. Mindestens eine Freigabe verlangen, und das ist der Punkt, an dem viele Konfigurationen ins Leere laufen: Ohne eine Mindestanzahl greift die erste Regel nämlich nicht. Freigaben zurücksetzen, sobald neue Commits hinzukommen; sonst gilt eine Zustimmung für Code, den niemand gesehen hat. Und für sensible Pfade eine feste Prüfergruppe hinterlegen.

6:43 Diese vier zusammen ergeben ein belastbares Verfahren. Einzeln ergeben sie ein Gefühl. Wenn Sie nur fünf Dinge einstellen, dann diese. Selbstfreigabe ausschließen und mindestens einen Prüfer verlangen — das Paar, über das wir gerade gesprochen haben. Dann der Schritt, der speziell für Agenten gilt: Anweisungsdatei und Pipeline-Konfiguration unter Pfadschutz stellen und dafür eine Gruppe ohne Agentenzugang als Prüfer setzen.

7:08 Der Grund steht in der Fußzeile und ist der wichtigste Satz dieses Kapitels: So kann ein Agent seine eigenen Leitplanken nicht ändern. Dazu Force Push und Branch-Löschung sperren. Und optional ein automatisiertes Review als Pflichtprüfer. Drei Zeilen, drei Rollen — und beachten Sie die Formulierung in der ersten. Dort steht "die Entwicklerin", nicht "die KI", und zwar auch dann, wenn der Code vom Agenten stammt.

7:33 Das ist keine sprachliche Feinheit, sondern die Grundlage der ganzen Konstruktion: Der Agent handelt unter einer menschlichen Identität, also zählt er zu dieser Zeile. Die zweite Zeile verlangt eine andere Person, die dritte den Betrieb oder eine geprüfte Automatisierung. Die Fußzeile sagt, worauf es ankommt: Die drei Zeilen dürfen nicht in einer Hand zusammenfallen.

7:55 So fühlt sich der Schutz an, wenn er greift: Der direkte Push auf den Hauptbranch wird abgewiesen, mit einer klaren Meldung. Und dann geht es weiter wie immer — ein Branch, ein Push, ein Pull Request. Worauf es ankommt, ist der Ton dieser Erfahrung. Es passiert nichts Dramatisches, nichts geht verloren, niemand wird ausgesperrt. Der Weg über den Branch bleibt offen; gesperrt ist nur die Abkürzung.

8:18 Genau deshalb funktioniert diese Art von Schutz auch sozial: Sie behindert die Arbeit nicht, sie verlangt nur den vorgesehenen Weg. Kombinieren Sie die Regeln so, dass eine Änderung den Hauptbranch nur über eine fremde Freigabe erreicht. Zwei Nachweise gehören dazu: Ein direkter Push wird abgewiesen, und ein selbst erstellter Pull Request lässt sich nicht selbst freigeben.

8:41 Der zweite Test ist der wichtigere, weil er das eigentliche Ziel prüft. Und der Hinweis ist ernst gemeint: Probieren Sie das am eigenen Konto aus. Es gibt angenehmere Gespräche, als einer Kollegin zu erklären, warum sie gerade nicht mehr in den Hauptbranch kommt. Vier Punkte. Selbstfreigabe sperren, aber keinen Prüfer verlangen — die Regel ohne Wirkung, die wir schon hatten.

9:03 Zu zweit die Trennung umgehen, indem einer am Pull Request mitschreibt und der andere freigibt; manche Anbieter lassen sich das ausdrücklich abschalten. Freigaben nach neuen Commits bestehen lassen. Und der vierte, der speziell hierher gehört: Anweisungsdateien ungeschützt lassen. Sie sehen aus wie Dokumentation, sie steuern aber Verhalten. Behandeln Sie sie wie eine Pipeline-Konfiguration, dann liegen Sie richtig.

Zugänge für Agenten trennen

9:29 Branch Protection regelt, was mit dem Code passiert. Jetzt geht es eine Ebene tiefer: Womit kommt ein Agent überhaupt an das entfernte Repository? Und wie viel gibt man ihm dabei mit? Ein Zugangstoken ist der Schlüssel, mit dem ein Agent auf das entfernte Repository zugreift. Beim Erzeugen legen Sie drei Dinge fest: wie lange er gilt, für welche Repositories, und was er dort darf. Diese drei Angaben sind die gesamte Kontrolle, die Sie haben.

9:57 Danach handelt der Agent in diesem Rahmen — und zwar ohne Rückfrage. Es gibt keine Zwischeninstanz, die noch einmal nachhakt, ob eine Aktion wirklich gemeint war. Was der Token erlaubt, passiert, wenn das Modell es für richtig hält. Bei der Token-Erstellung erschlägt einen die Liste der Berechtigungen. Drei davon sind für Coding-Agenten relevant.

10:18 Inhalte umfassen Dateien und Ordner — und zusätzlich Commits und Branches, was mehr ist, als der Name vermuten lässt. Pull Requests umfassen die Anfragen samt Kommentaren und Freigaben. Und Verwaltung umfasst Einstellungen, Mitgliedschaften und, das sollte man wissen, die Löschung des Repositories. Merken Sie sich vor allem die dritte Zeile.

10:38 Verwaltungsrechte sind für das Schreiben von Code fast nie nötig, und sie sind die einzigen mit katastrophalem Potenzial. Drei Zuschnitte als Orientierung, und die interessante Spalte ist die linke. Ein unbefristeter Token mit allen Rechten auf alle Repositories ist nicht nur wegen eines möglicherweise übermotivierten Agenten gefährlich — er ist vor allem ein sehr wertvolles Ziel, falls er kompromittiert wird.

11:02 Die mittlere Spalte ist der Gegenpol; sie ist sinnvoll, wenn der Agent rein lokal arbeitet und Sie alles Entfernte selbst erledigen. Die rechte Spalte ist der Alltagsschnitt: befristet, auf die relevanten Repositories begrenzt, mit Schreibrechten, wo sie gebraucht werden. Und mit einer Voraussetzung, die in der Fußzeile steht — geschützte Branches.

11:22 Eine Alternative, die größere Organisationen zunehmend wählen: ein eigenes Konto für den Agenten. Der Reiz liegt in der Vereinfachung. Der Zugriff hängt dann allein an der Gruppenmitgliedschaft und nicht zusätzlich an den Rechten eines Tokens — Sie pflegen eine Ebene statt zweier. Das lässt sich über die Organisation hinweg vereinheitlichen, und der Token darf länger gelten, weil die Gruppe die Grenzen zieht.

11:46 Der Preis steht im letzten Punkt: eine zusätzliche Lizenz, und weniger Sichtbarkeit. Wenn Commits unter einem Agentennamen laufen, fällt ungewöhnliches Verhalten später auf. Reduzieren Sie für einen konkreten Einsatz die Rechte auf das begründbare Minimum. Das Wort begründbar ist dabei der Kern der Übung: Zu jeder erteilten Berechtigung gehört ein Satz, warum sie nötig ist.

12:08 Wem zu einer Berechtigung nichts einfällt, der braucht sie nicht. Dazu eine begrenzte Laufzeit und die benötigten Repositories einzeln benannt, nicht pauschal. Und der Hinweis, den ich Ihnen besonders ans Herz lege: Verwaltungsrechte sind fast nie nötig. Im Zweifel weglassen und nachrüsten, wenn tatsächlich etwas fehlt.

12:28 Vier Punkte, und der erste ist der häufigste überhaupt: ein unbefristeter Token mit allen Rechten, weil es beim Einrichten schneller geht. Diese Abkürzung überlebt erfahrungsgemäß Jahre. Token im Repository ablegen statt in der Konfiguration des Werkzeugs — damit ist er in der Historie, und dort bleibt er auch nach dem Löschen.

12:47 Ein Agentenkonto anlegen und dann die Gruppenrechte großzügig setzen; damit verschieben Sie das Problem nur eine Ebene weiter. Und der letzte: die Verantwortung für den Code an das Agentenkonto abgeben. Sie bleibt bei einem Menschen.

Rückblick auf das Seminar

13:01 Damit sind wir am Ende der Technik angekommen. Bleibt der Blick zurück: Was ist in diesen sechs Modulen entstanden, wie hängt es zusammen, und womit fangen Sie am Montag an? Der Bogen dieses Seminars führt von der Historie über die Parallelität und die Qualität bis zu den Grenzen. Und er ist nicht zufällig so geschnitten: Jedes Modul hat eine der Stellen besetzt, die wir gleich zu Beginn im Weg vom Prompt zur Produktion markiert haben.

13:26 Was mit vier Punkten auf einer Übersicht anfing, ist jetzt mit Werkzeugen gefüllt. Deshalb lohnt es sich, zum Schluss noch einmal auf diese Landkarte zu schauen — sie zeigt nicht nur, was wir gemacht haben, sondern auch, wo bei Ihnen noch Lücken sind. Sechs Module, sechs Ergebnisse. Was die Tabelle nicht zeigt, ist die Bewegung darin: Die ersten vier Zeilen spielen auf Ihrem Rechner, die letzten beiden auf dem Server.

13:51 Diese Reihenfolge war Absicht. Alles, was Sie lokal lösen, ist schnell, billig und braucht niemandes Zustimmung. Alles, was auf dem Server passiert, ist langsamer einzuführen, aber verbindlich. Die Fußzeile fasst es zusammen: Lokal beginnt die Absicherung, verbindlich wird sie erst entfernt. Wer nur das eine tut, hat entweder keine Wirkung oder keinen Nachweis.

14:13 Für den Einstieg vier Empfehlungen nach Aufwand sortiert. Eine Commit-Vorlage kostet zehn Minuten und wirkt ab dem nächsten Commit. Ein Pre-Commit-Hook spart jede Woche Wartezeit auf die Pipeline — die Rechnung geht meist schon in der ersten Woche auf. Die Selbstfreigabe zu sperren ist eine Einstellung, kein Projekt; das schafft man in der Mittagspause.

14:34 Alles Weitere — Worktrees, Attribution, eigene Konten — lohnt sich, sobald mehrere Agenten im Spiel sind. Vorher wäre es Vorratshaltung, und die hat noch nie jemandem geholfen. Die letzte Aufgabe ist zugleich Ihre Mitnahme: Wählen Sie drei Maßnahmen aus, die im eigenen Umfeld am schnellsten Wirkung zeigen. Zu jeder gehören drei Angaben — Aufwand, erwarteter Nutzen und die Person, die es umsetzt. Der letzte Punkt entscheidet, ob aus der Liste etwas wird.

15:02 Und der Hinweis empfiehlt eine Streuung: je eine Maßnahme aus den Bereichen Historie, Qualität und Grenzen. Drei kleine Schritte in drei Richtungen bringen mehr als ein großer in eine.

Danke!

15:14 Damit sind wir am Ende. Was bleibt, sind drei Gedanken. Git ist die Klammer um alles, was ein Agent in Ihrem Projekt anstellt — es sieht jede Änderung, und es kann an jeder Übergabestelle eingreifen. Lokal arbeiten Sie schnell, entfernt verbindlich; erst beides zusammen trägt. Und der wichtigste Satz zum Schluss: Die Grenzen setzt nicht das Modell, sondern die Konfiguration.

15:37 Vielen Dank für Ihre Aufmerksamkeit — Material und Kontakt finden Sie auf unserer Seite.