Vier Aktionen, bei denen ein Agent immer zuerst einen Menschen fragen sollte

Die meisten Berechtigungssysteme für Coding-Agenten sind Allowlists: Dateien lesen ja, Dateien schreiben ja, Tests ausführen ja, bei allem anderen nachfragen. Das funktioniert so lange, bis jemand einen Agenten auf „voll vertrauenswürdig“ setzt, um die ständigen Prompts loszuwerden – und der Agent an einem Freitagnachmittag git push --force ausführt.

Unsere Haltung ist klar: Vier Aktionskategorien müssen jedes Mal für einen Menschen anhalten, ganz egal wie vertrauenswürdig der Agent oder der Anfragende ist. Vertrauensstufen bestimmen, wie viele andere Dinge eine Freigabe brauchen. Diese vier laufen niemals stillschweigend ab.

Die vier

1. Pushen auf einen geteilten Branch. Ein Commit auf einem Feature-Branch ist ein Vorschlag. Ein Push auf main oder release ist eine Entscheidung, mit der das gesamte Team leben muss – oft direkt mit einem Deployment verknüpft. Vorher zu fragen kostet fast nichts; die Aktion rückgängig zu machen ist extrem teuer.

2. Löschen. Dateien, Branches, Tabellen, Buckets, Ressourcen. Das Löschen ist die eine Operation, bei der eine falsche Vermutung über die Absicht nicht durch einen zweiten Versuch rückgängig gemacht werden kann. Agenten treten selbstsicher auf, und selbstsicheres Löschen ist der klassische Weg, auf dem Backups unfreiwillig getestet werden.

3. Geld ausgeben. Eine kostenpflichtige API aufrufen, eine Ressource provisionieren, eine Domain kaufen, eine Kampagne versenden. Die Person, die die Anfrage gestellt hat, weiß vielleicht gar nicht, dass sie Geld kostet. Die Person, die dafür bezahlt, sollte es definitiv wissen.

4. Zugangsdaten anfassen. Eine Schlüsseldatei lesen, Umgebungsvariablen exportieren, sich bei einem Dienst anmelden, eine Zwei-Faktor-Authentifizierung abschließen. Bei all dem geht es um Identität – und die Identität gehört dem Besitzer der Maschine, nicht demjenigen, der sich gerade im Raum aufhält.

Warum „volles Vertrauen“ hier trotzdem pausieren sollte

Ein Berechtigungsmodus beschreibt die Beziehung einer Person zum Agenten: nur lesend, bearbeiten aber nicht pushen, volles Vertrauen. Das ist genau die richtige Granularität für die Hunderte von alltäglichen Aufrufen, die ein Agent während einer Session macht. Es ist jedoch die falsche Granularität für die vier oben genannten Aktionen. Denn diese sind selten, irreversibel oder teuer – und ihre Konsequenzen trägt meist jemand anderes als der Anfragende.

Die Regel in muti ist deshalb einfach: Keine Berechtigungsvorlage kann diese vier so konfigurieren, dass sie stillschweigend ausgeführt werden. Selbst im Modus für „volles Vertrauen“ halten sie an und werden in der Timeline hervorgehoben. Der Prompt tritt selten genug auf, um nicht zu nerven, und die Kategorien sind so präzise abgegrenzt, dass die Antwort meist auf der Hand liegt.

Wie sich das auf die Berechtigungsmodi von Claude Code überträgt

Claude Code besitzt bereits eine Abstufung: plan (nur lesend), default (fragt vor Änderungen und Befehlen), acceptEdits (Änderungen laufen durch, Befehle fragen nach) und bypassPermissions (nichts fragt nach). Diese Modi beschreiben, wie oft der Agent Sie selbst fragt. Die vier Aktionen beschreiben, was den Besitzer fragen muss, wenn jemand anderes die Anfrage stellt. Sie greifen ineinander.

Die letzte Spalte ist die Ergänzung durch den Raum und verhält sich in jeder Zeile gleich. Siehe Berechtigungsmodi im Detail erklärt.

Wer gefragt werden sollte

Das ist der Punkt, den die meisten Konzepte übergehen: Wenn ein geteilter Agent einen Menschen braucht, welchen Menschen meint er dann?

• Zugangsdaten gehen an den Besitzer. Logins, Zwei-Faktor-Codes und Schlüsselzugriffe berühren die Identität des Besitzers. Sie werden immer an den Besitzer geleitet, unabhängig davon, wer die Aufgabe gestartet hat. Der Anfragende sieht, dass eine Übernahme stattgefunden hat, nicht das Geheimnis selbst.
• Fragen zur Absicht gehen an den Anfragenden. „Meintest du die Staging-Datenbank?“ betrifft das, was die Person eigentlich tun wollte. Diese Frage wird an die anfragende Person weitergeleitet.
• Beide sehen dieselbe Timeline. Niemand muss dem anderen den Kontext mühsam nachreichen; die Frage und ihre Antwort befinden sich im selben Thread wie die laufende Arbeit.

Prompts für Zugangsdaten und gefährliche Aktionen gehen an den Besitzer; Fragen zur Absicht gehen an den Anfragenden; beide sehen den Austausch.

Anatomie einer guten Freigabekarte

Eine Freigabe, über die man in fünf Sekunden entscheiden kann, besteht aus fünf Elementen.

Geben Sie ihr drei Buttons: Approve, Deny und nur lesend fortfahren. Der dritte Button wird massiv unterschätzt: Er erlaubt es, die Arbeit weiterlaufen zu lassen, während der riskante Schritt auf Freigabe wartet.

Sorgen Sie dafür, dass Freigaben überall dort beantwortet werden können, wo sich der Besitzer ohnehin aufhält: in der Konsole, auf dem Smartphone oder über eine Karte auf einer Chat-Plattform. Eine Entscheidung an einem Ort sollte universell gelten. Setzen Sie zudem ein Ablaufdatum, damit eine vergessene Karte nicht eine Woche später plötzlich ausgeführt wird.

Freigabemüdigkeit ist der wahre Feind

Jeder Prompt trainiert die Person, die ihn sieht. Gibt es zu viele davon, wird sie den Schalter suchen, der sie komplett abstellt. Drei Maßnahmen halten die Frequenz niedrig, ohne die vier Grundregeln aufzuweichen.

• Den Scope des Agenten einschränken. Ein Arbeitsverzeichnis pro Agent bedeutet weniger Dateien, die er überhaupt anfassen könnte, und somit weniger Prompts darüber.
• Normale Modi für normale Aufrufe nutzen. Read-only zum Erkunden, Bearbeiten-ohne-Push für die meiste Arbeit. Reservieren Sie „volles Vertrauen“ für Personen, die sonst direkt an Ihrer Tastatur sitzen würden.
• Die Standardvorlagen ehrlich halten. Liefern Sie Voreinstellungen für Read-only, Bearbeiten-ohne-Push und volles Vertrauen standardmäßig mit, damit niemand eigene Richtlinien von Grund auf neu erstellen und dabei Fehler machen muss.

Der Audit-Trail

Jede Anfrage und jede Freigabe sollte genau eine Zeile erzeugen, die der Besitzer exportieren kann: wer gefragt hat, wer entschieden hat, wann, welche Regel, was passiert ist, welche Ressourcen genutzt wurden. Nicht, weil man das täglich liest – sondern weil der Tag, an dem etwas schiefgeht, der denkbar schlechteste Moment ist, um mit dem Logging zu beginnen.

Häufig gestellte Fragen

Bremst ständiges Nachfragen den Agenten nicht aus? Nur bei diesen vier Kategorien, und die sind in einer normalen Session selten. Die Pause kostet Sekunden; die Behebung eines Fehlers wird in Stunden oder Geld gemessen.

Was ist, wenn der Besitzer seinen eigenen Agenten nutzt? Der Besitzer unterliegt an seinem eigenen Agenten keinen Berechtigungsmodi. Die vier Aktionen werden dennoch in der Timeline erfasst, damit der Verlauf lückenlos bleibt.

Kann ein Anfragender Aktionen für sich selbst genehmigen? Nein. Die Genehmigung steht allein dem Besitzer der Maschine zu. Der Anfragende kann die Aktion abbrechen, wiederholen oder zusätzlichen Kontext ergänzen.

Räume in muti werden standardmäßig mit diesen Regeln ausgeliefert – ohne Möglichkeit, sie zu deaktivieren. Wenn das nach den richtigen Grundeinstellungen für Sie klingt: Geben Sie Ihrem Agenten einen Raum.