Du gibst einem Coding-Agenten eine kleine Aufgabe: Behebe einen fehlschlagenden Test. Zwanzig Minuten später hat er drei unbeteiligte Dateien umgeschrieben, eine Datenbankmigration gegen die DATABASE_URL laufen lassen, die er zufällig in deiner Shell gefunden hat, und auf einen Branch force-gepusht, den gerade jemand anderes benutzte. Nichts im Prompt hat auch nur eines davon verlangt. Der Agent hatte freie Hand auf der Maschine – also nutzte er diese freie Hand.
Berechtigungen sind das Mittel, mit dem du im Voraus festlegst, worauf ein Agent zugreifen darf. Eine Coding-Agent-Berechtigung ist eine Regel, die bestimmt, auf welche Dateien, Befehle, Zugangsdaten und Repositories ein bestimmter Agent während eines Runs zugreifen kann und an welcher Stelle ein Mensch eingreifen muss. Machst du es richtig, scheitert ein Agent, der vom Skript abweicht, sicher innerhalb eines Rahmens, den du selbst gezogen hast. Machst du es falsch, erreicht ein einziger schlechter Run die Produktion.
Dieser Artikel geht das Berechtigungsmodell Ebene für Ebene durch, benennt auf jedem Schritt das typische Fehlerbild und endet mit einer Checkliste, die du noch heute durchgehen kannst. Zur Veranschaulichung dient Sharkly, denn Sharklys Aufgabe ist es, über deinen Coding-Agenten zu sitzen und diesen Scope an einer Stelle zu bündeln. Du hast bereits Coding-Agenten. Sharkly macht daraus ein Team – und ein Team braucht Regeln dafür, wer was tun darf.
Die drei Ebenen, auf denen die Berechtigungen eines Agenten liegen
Berechtigungen für einen Coding-Agenten sind keine einzelne Einstellung. Sie liegen an drei Stellen, und eine Lücke an einer davon macht die anderen beiden zunichte.
- Die Runtime entscheidet, welche Tools der Agent aufrufen darf: eine Datei lesen, eine Datei bearbeiten, einen Shell-Befehl ausführen, aufs Netzwerk zugreifen. Das ist Claude Code, Codex, Gemini CLI oder welcher Agent auch immer die Arbeit ausführt.
- Die Maschine entscheidet, was diese Tools erreichen können: welche Verzeichnisse, welche Zugangsdaten, welche Umgebungsvariablen, welches Netzwerk. Ein Computer in Sharkly „stellt das Betriebssystem, die Dateien, die Zugangsdaten, den Netzwerkzugriff und die Tools bereit, die ein Agent benötigt“ – die Maschine ist also der eigentliche Blast Radius.
- Die Aufgabe entscheidet über die Grenze der Absicht: auf welches Repository dieser Run beschränkt ist, welche Status der Agent setzen darf und an welchem Punkt ein Mensch das Ergebnis abnimmt.
Eine Grenze sollte man klar benennen: Eine Berechtigung ist kein Approval Gate. Eine Berechtigung beschreibt, was der Agent tun kann. Ein Approval Gate ist die Stelle, an der ein Mensch entscheidet. Du brauchst beides. Enge Berechtigungen ohne Gate bedeuten, dass niemand das Ergebnis prüft. Ein Gate mit lockeren Berechtigungen bedeutet, dass der Schaden bereits angerichtet ist, bis jemand hinschaut.
Schritt 1: Die Tools der Runtime eingrenzen
Fang dort an, wo der Agent handelt. Die meisten Coding-Agenten bringen ein Berechtigungssystem mit: eine Allow-Liste und eine Deny-Liste für Tools sowie eine Rückfrage, bevor etwas Destruktives ausgeführt wird. Claude Code zum Beispiel erlaubt es dir, bestimmte Tools zu erlauben oder zu verbieten, und fragt vor Shell-Befehlen nach. Die genauen Einstellungsnamen unterscheiden sich je nach Runtime und ändern sich häufig – lies also die aktuelle Doku deines Agenten statt eines Snippets, das du letztes Jahr gefunden hast.
Der sichere Standard ist großzügig bei Lesezugriffen und knauserig bei Schreibzugriffen. Lass den Agenten das Repo lesen, Tests laufen lassen, Typen prüfen und bauen, ohne nachzufragen. Dateiänderungen und Shell-Befehle hängen dagegen hinter einer Rückfrage oder einer expliziten Allow-Liste.
Dieses Fehlerbild hat einen Namen, und es ist genau das, zu dem alle unter Termindruck greifen: der pauschale Überspringmodus. Jede Runtime hat ein Flag, das alle Rückfragen abschaltet – praktisch für eine beaufsichtigte Session. Gefährlich wird es, wenn es bei einem unbeaufsichtigten Run eingeschaltet bleibt. Ein Agent, der nie fragen muss und nach einem Plan arbeitet, der sich als falsch erwiesen hat, löscht mit Freuden genau das, was er missverstanden hat. Nutze Auto-Accept, wenn du zusiehst. Schalte es aus, wenn du weggehst.
Schritt 2: Die Maschine und ihre Zugangsdaten eingrenzen
Die Tool-Liste der Runtime ist wertlos, wenn die Maschine dem Agenten alles in die Hand gibt. Ein Agent, der Shell-Befehle auf deinem Hauptrechner ausführen darf, kann jeden SSH-Key, jede .env und jeden Zugangsdatensatz lesen, den dein eigener Login erreicht. Dieses Fehlerbild ist leise: Nichts sieht falsch aus, bis ein Agent einen Produktionsschlüssel verwendet, den er nie hätte sehen dürfen.
Zwei Maßnahmen verkleinern den Blast Radius. Erstens: Lass Agenten an einem eingegrenzten Ort laufen statt auf dem Laptop, auf dem du deine echten Secrets aufbewahrst. Sharkly registriert einen Computer mit einem einmaligen Install-Token, der kurzlebig und nur ein einziges Mal verwendbar ist – und die Doku ist unmissverständlich: Pack diesen Token nicht in ein wiederverwendbares Image, Skript, Task oder Kommentar. Ob der Computer ein Container, ein Server oder eine Ersatzmaschine ist: Die Reichweite des Agenten ist die Reichweite dieser Umgebung, nicht deine. Wenn Agenten arbeiten sollen, während du offline bist, lass sie auf einem Remote-Computer laufen statt auf deinem offenen Laptop.
Zweitens: Übergib nur, was ein Run braucht. Die Umgebung eines Sharkly-Runs wird aus expliziter Konfiguration zusammengesetzt: angebundene Repositories, Umgebungsvariablen, Secret-Bindings und ein Arbeitsverzeichnis. Häng Repositories an einen Agenten, wenn er einen engeren Code-Scope braucht als den Space-Standard, damit ein Frontend-Agent nie den Billing-Service auscheckt. Halte jeden Run in einem eigenen isolierten Worktree – das ist der Unterschied zwischen einer schlechten Änderung, die in einem Checkout bleibt, und zwei Agenten, die denselben Working Tree beschädigen. Für jedes Feld gilt die Hausregel: Gib nur die Konfiguration ein, nach der das Produkt verlangt, und füge niemals Passwörter oder Tokens in unzusammenhängende Felder oder Startbefehle ein.
Schritt 3: Die Aufgabe eingrenzen und den Merge dem Menschen überlassen
Die letzte Ebene ist die Absicht. Selbst ein korrekt gesandboxter Agent mit eingegrenzten Zugangsdaten kann die falsche Arbeit tun: seine eigene Aufgabe als erledigt markieren, eine halbfertige Änderung in einen gemeinsamen Branch pushen oder entscheiden, dass ein PR bereit zum Mergen ist.
Hier gehört der Human-Agent-Vertrag hin. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Automatisierung endet dort, wo das Urteilsvermögen des Teams gefragt ist. Ein Agent sollte einen Draft-PR öffnen und seine Testausgabe anhängen dürfen; er sollte diesen PR aber nicht genehmigen oder in deinen geschützten Branch mergen. Branch Protection auf dem Host und menschliches Review am Task sind die beiden Schlösser, die diese Grenze intakt halten.
In Sharkly trägt der Task selbst diese Grenze. Ein Workflow vom Typ Task schränkt ein, welche Status ein Agent auswählen kann, sodass ein Agent Arbeit nicht still in einen Status wie „Done“ oder „Released“ verschieben kann, der einer Person gehört. Wenn ein Agent eine Entscheidung braucht, lässt er den Task auf menschliches Review oder eine menschliche Antwort warten – das erscheint in der Inbox für die verantwortliche Person, die dann abnehmen, Änderungen anfordern oder neu zuweisen kann. Ausführung, Blocker, Ergebnisse und das Review landen alle wieder im selben Task, statt sich über fünf Terminals zu verteilen.
Und hier stößt auch das Selbstbau-Setup an seine Skalierungsgrenzen. Ein Agent, ein Repo, eine sorgfältige Entwicklerin: Das ganze Berechtigungsmodell passt noch in deinen Kopf. Kommen ein zweiter und dritter Agent, mehr Repositories und ein Teammitglied dazu, wird aus der Frage „Was darf welcher Agent hier?“ eine Frage, die niemand aus dem Gedächtnis beantworten kann. Ein Task Board macht diese Regeln zu einer gemeinsamen, nachvollziehbaren Konfiguration: Wer hat die Arbeit zugewiesen, welchen Scope hatte der Run, welche Belege kamen zurück und wer hat das Ergebnis abgenommen? Das ist die Management-Ebene über deinen Coding-Agenten. Du kannst sie von Hand bauen – mit Worktrees, eingegrenzten Zugangsdaten und Branch Protection – oder deine bestehenden Coding-Agenten über Sharkly laufen lassen und Berechtigungen, Tasks und Review an einer Stelle verwalten.
Die Berechtigungs-Checkliste für den heutigen Tag
Geh diese Liste für jeden Agenten durch, den du an ein echtes Repository lassen lässt:
- Runtime: Lesezugriffe und Tests ohne Rückfrage erlaubt; Änderungen und Shell-Befehle abgesichert; pauschaler Überspringmodus für unbeaufsichtigte Runs aus.
- Maschine: Der Agent läuft auf einem eingegrenzten Computer, nicht auf deinem Hauptrechner; Install- und Access-Tokens sind einmalig verwendbar und werden nie eingecheckt.
- Zugangsdaten: nur die Umgebungsvariablen und Secret-Bindings, die dieser Run braucht – nichts in unzusammenhängende Felder eingefügt.
- Repository-Scope: Der Agent ist an die Repos angebunden, die seine Arbeit erfordert, nicht an jedes Repo im Space.
- Isolation: Jeder Run bekommt seinen eigenen Worktree, damit eine schlechte Änderung keinen gemeinsamen Checkout beschädigen kann.
- Task-Scope: Der Agent kann Arbeitsstatus setzen, aber einen Task nicht in einen abgenommenen oder released Status verschieben, der einer Person gehört.
- Der Merge: Branch Protection plus menschliches Review mit Belegen auf Task-Ebene stehen zwischen dem PR des Agenten und main.
Wenn eine Zeile locker sitzt, zieh sie vor dem nächsten Run fest – nicht erst nach dem Vorfall, der dir zeigt, warum sie wichtig war.
FAQ
Was ist der Unterschied zwischen Berechtigungen für Coding-Agenten und Approval Gates? Berechtigungen definieren, wozu ein Agent technisch in der Lage ist: auf welche Dateien, Befehle und Zugangsdaten er zugreifen kann. Ein Approval Gate ist der Punkt, an dem ein Mensch entscheidet, ob er akzeptiert, was der Agent getan hat. Du brauchst beides, denn enge Berechtigungen lassen trotzdem Arbeit übrig, die ein Mensch absegnen sollte, und Approval Gates helfen nicht, wenn der Agent bereits die Berechtigung hatte, Schaden anzurichten.
Sollte ein Coding-Agent jemals seine eigenen PRs mergen dürfen? Nein, nicht standardmäßig. Lass den Agenten einen Draft-PR öffnen und seine Verifikationsausgabe anhängen, und überlass den Merge dann einer Person oder einem verpflichtenden Review. Die Begründung ist der Human-Agent-Vertrag: Agenten führen aus und berichten, Menschen nehmen ab und veröffentlichen. Das gilt auch für Human-in-the-Loop-Workflows, bei denen der Agent den Großteil der Arbeit erledigt.
Ist es sicher, einen Agenten mit abgeschalteten Berechtigungs-Rückfragen laufen zu lassen? Nur solange du zusiehst. Auto-Accept-Modi sind nützlich für eine beaufsichtigte Session, in der du einen falschen Schritt stoppen kannst. Für unbeaufsichtigte Runs oder den Betrieb über Nacht solltest du Rückfragen oder eine Allow-Liste aktiviert lassen und den Agenten auf einer eingegrenzten Maschine laufen lassen, damit ein Fehler contained bleibt.
