Standardmäßig keine Freigabe

Standardmäßig keine Freigabe bedeutet, dass nichts an einem Agenten, seiner Maschine oder seinen Räumen für irgendjemanden sichtbar oder nutzbar ist, bis der Besitzer des Agenten eine ausdrückliche Entscheidung trifft, es zu teilen – und dass jede solche Entscheidung im Umfang begrenzt, protokolliert und widerrufbar ist. Es ist das einzige Grundprinzip unter muti. Alles, was wie eine separate Sicherheitsregel aussieht, ist eine Konsequenz daraus.

Die Konsequenzen aufzuschreiben ist nützlich, weil jede von ihnen eine Abkürzung verbietet, die sonst verlockend wäre.

Das Prinzip ganz oben; darunter fünf Regeln, jede eine Konsequenz.

Konsequenz 1: Der Raum ist die Grenze

Nichts wechselt zwischen Räumen. Ein Agent in zwei Räumen trägt kein Gedächtnis, keine Nachrichten und keine Artefakte von einem in den anderen. Eine Person in einem Raum kann nicht sehen, dass ein anderer Raum existiert. Es gibt keine „Workspace“-Ebene über den Räumen, über die Dinge seitlich durchsickern könnten.

Verbietet: globale Agentenverzeichnisse, raumübergreifende Suche, „Kürzlich aktiv“-Listen, die andere Räume offenbaren.

Konsequenz 2: Eine Erwähnung gewährt keinerlei Rechte

Ein @agent stellt eine Nachricht in die Inbox des Agenten zu. Ob er ausgeführt wird, hängt von einer bestehenden Freigabe oder einer Bestätigung durch den Besitzer ab. Im Raum zu sein, erwähnt zu werden oder die lauteste Person im Thread zu sein, verleiht keinerlei Rechte.

Verbietet: Berechtigungsmodelle auf Basis von Channel-Mitgliedschaften; „Jeder im Raum kann ausführen“-Standardeinstellungen. Siehe Claude Code Dispatch vs. ein Raum.

Konsequenz 3: Zugangsdaten verlassen niemals die Maschine

Der daemon lädt Timeline-Ereignisse hoch, keine Dateien oder Systemumgebungen. Anmeldungen, Zwei-Faktor-Codes und der Zugriff auf Schlüssel werden an den Besitzer geleitet und niemals an den Anfragenden – selbst nicht an den Anfragenden, der den prompt ausgelöst hat. Es gibt keine Funktion, die ein Geheimnis irgendwohin kopiert, auch nicht in mutis eigene Cloud.

Verbietet: gehostete Runtimes, Zugangsdaten-Tresore im Raum, „Fügen Sie Ihr Token hier ein“-Abläufe. Siehe was der daemon hochlädt.

Konsequenz 4: Vier Aktionen pausieren immer

Das Pushen auf einen geteilten Branch, das Löschen, das Ausgeben von Geld und das Anfassen von Zugangsdaten halten für den Besitzer bei jedem Request von jemand anderem an – unter jedem Berechtigungstemplate, einschließlich vollem Vertrauen. Kein Template kann dies deaktivieren, denn ein Template ist eine Freigabeentscheidung, und das Prinzip besagt, dass Freigabeentscheidungen für irreversible Aktionen pro Aktion explizit sein müssen.

Verbietet: einen „Wirklich vertrauen“-Modus; unbemerkte Pushes durch Ausleihende. Siehe vier Aktionen, bei denen ein Agent immer vorher fragen sollte.

Konsequenz 5: Chat-Eingaben sind nicht vertrauenswürdig

Eine Nachricht von Feishu, Slack oder einem beliebigen Connector sind Daten. Sie kann einen Request erstellen; sie kann keine Berechtigung erstellen. Die Identität ist an ein muti-Konto gebunden, nicht an einen Anzeigenamen: in Slack über die E-Mail-Adresse, die der Workspace verifiziert hat, mit einem Einmal-Link-Code als Ausweichlösung, sodass Berechtigungen am Konto hängen.

Verbietet: das Ausführen für ungebundene Benutzer; das Vertrauen in die Admin-Definition einer Chat-Plattform.

Konsequenz 6: Der Widerruf erfolgt sofort und vollständig

Das Widerrufen einer Freigabe, das Entfernen eines Mitglieds, das Widerrufen einer Maschine oder das Stoppen des daemon wird sofort wirksam. Wartende Requests der betroffenen Person werden abgebrochen; laufende Arbeiten werden abgeschlossen und verbleiben im Verlauf, damit das Protokoll keine Lücken aufweist.

Verbietet: Übergangsfristen; „Entfernung ausstehend“-Zustände; das Löschen des Verlaufs beim Widerruf.

Konsequenz 7: Das Protokoll ist append-only und liegt beim Besitzer

Jeder Request und jede Genehmigung erzeugt eine Zeile, die der Besitzer exportieren und niemand bearbeiten kann. Die eigenen Aktionen des Besitzers werden ebenfalls protokolliert, denn ein Protokoll nur über Außenstehende ist ein halbes Protokoll.

Verbietet: bearbeitbare Logs; Logs im Besitz des Anfragenden; Opt-out-Protokollierung. Siehe was ein Audit-Log aufzeichnen muss.

Was das Prinzip kostet

Es kostet an drei Stellen Bequemlichkeit, und wir akzeptieren alle drei.

• Kein globales „Jeden beliebigen Agenten fragen“-Eingabefeld. Man muss im Raum sein.
• Gelegentliche Prompts bei vertrauenswürdigen Personen. Die vier Aktionen fragen selbst dann nach, wenn man zugestimmt hätte.
• Keine gehostete Runtime, auch wenn sie das Problem schlafender Maschinen verschwinden ließe. Die Inbox ist stattdessen die Antwort. Siehe die Inbox für Agenten.

Häufig gestellte Fragen

Ist „standardmäßig nichts freigeben“ nicht einfach nur eine Einstellung? Es ist das Fehlen von Einstellungen, die mehr freigeben könnten, als der Besitzer gewählt hat. Jeder Freigabeakt ist eine explizite Gewährung, eine Genehmigung oder eine Einladung, jeweils protokolliert.

Muss der Besitzer für immer alles genehmigen? Nein. Dauerhafte Freigaben machen Genehmigungen pro Request für Personen überflüssig, denen Sie vertrauen. Die vier Aktionen pausieren weiterhin; das ist der einzige Teil, der sich nicht delegieren lässt.

Wie steht es mit der eigenen Nutzung des Agenten durch den Besitzer? Besitzer werden bei ihren eigenen Agenten nicht blockiert, aber sie werden auf die gleiche Weise protokolliert. Das Prinzip betrifft das Teilen, nicht den Zugriff des Besitzers auf die eigene Maschine.

Eine Regel, sieben Konsequenzen, ein Produkt. Geben Sie Ihrem Agenten einen Raum.