Ist die automatische Ausführung von DAO-Code sicher? Leitfaden zur Auswahl des Teammodus 2026

Die offizielle DAO-Code-Dokumentation beschreibt fünf Ausführungsarten: plan, default, acceptEdits, auto und bypassPermissions (README mit den Modusbeschreibungen). Daraus folgt die klare Empfehlung für diese Woche: Verwenden Sie im Team standardmäßig den Modus mit einzelner Bestätigung. Nutzen Sie plan für reine Analyse, und schalten Sie auto erst nach bestandener Prüfung von Arbeitsverzeichnis, Geheimnissen, Wiederherstellung und Protokollierung frei. Der als „yolo“ bezeichnete, weitgehend ungebremste Betrieb gehört nicht in ein normales Teamprojekt.

Diese Anleitung richtet sich an technische Verantwortliche, die eine verbindliche DAO-Code-Basis für ihr Team festlegen. Sie hilft Sicherheitsingenieuren beim Schutz von Quellcode, API-Schlüsseln und Build-Zugangsdaten. Auch Plattformadministratoren, die DAO-Code-Umgebungen mehrfach bereitstellen, erhalten eine prüfbare Einführungsroutine.

Die fünf Modi unterscheiden sich vor allem beim Kontrollverlust

Die zentrale Fehlannahme lautet: Mehr Automatisierung bedeute automatisch mehr Produktivität. In einer Codebasis zählt jedoch nicht nur, wie schnell eine Datei geändert wird. Entscheidend ist, ob ein Befehl externe Daten versendet, ob ein Geheimnis in eine Unterprozessumgebung gelangt und ob eine fehlerhafte Änderung ohne Eingriff zurückgenommen werden kann.

DAO-Code dokumentiert mehrere Stufen zwischen Planung und uneingeschränkter Ausführung. plan eignet sich für eine Bestandsaufnahme und Vorschläge, ohne dass Sie Änderungen als normalen Arbeitsablauf freigeben. Der Standardmodus fordert für riskante Aktionen eine Entscheidung an. acceptEdits kann Bearbeitungen stärker automatisieren, sollte aber nicht mit einer pauschalen Erlaubnis für beliebige Shell-Befehle verwechselt werden. auto reduziert die Zahl der Rückfragen und ist deshalb nur bei eng begrenztem Arbeitsbereich vertretbar. bypassPermissions beziehungsweise „yolo“ entfernt wesentliche Schutzschichten und ist ausschließlich für eine isolierte, jederzeit löschbare Testumgebung denkbar.

Die offizielle DAO-Code-Sicherheitsstrategie beschreibt außerdem Regelstufen, Bestätigungen für sensible Ziele, Prüfprotokolle und eine optionale Systemisolation. Diese Angaben sind Funktionsbeschreibungen des Projekts. Sie sind weder eine unabhängige Sicherheitszertifizierung noch ein Nachweis dafür, dass jedes Plugin, jeder Hook oder jeder MCP-Dienst sicher arbeitet.

Für die Teamrichtlinie genügt deshalb nicht die Frage, welcher Modus „am schnellsten“ ist. Sie brauchen eine Obergrenze:

Unbekanntes Repository oder fremder Pull Request: plan.
Vertrauenswürdige Entwicklung mit Review: Einzelbestätigung als Standard.
Klar begrenztes Testverzeichnis ohne produktive Geheimnisse: auto nach Abnahme.
Wegwerfbare Sandbox ohne echte Zugangsdaten: eventuell bypassPermissions.
Produktionsschlüssel, irreversible Befehle oder ungeprüfte MCP-Werkzeuge: immer manuelle Bestätigung.

Erster Prüfpunkt: Reichweite von Lesen, Ändern und Ausführen

Lesen ist nicht automatisch harmlos. Eine Konfigurationsdatei kann Zugangsdaten enthalten. Ein Shell-Befehl kann Daten komprimieren und an einen externen Dienst übertragen. Ein Build-Skript kann wiederum weitere Programme starten. Die Sicherheitsprüfung muss daher mindestens vier Reichweiten getrennt betrachten: Dateilesen, Dateischreiben, Befehlsausführung und externe Verbindungen.

Beginnen Sie mit den vorhandenen Regeln. Prüfen Sie, ob allow, ask und deny tatsächlich auf die Verzeichnisse angewendet werden, die Ihr Team schützen möchte. Dazu zählen etwa:

das eigentliche Projektverzeichnis;
übergeordnete Verzeichnisse mit gemeinsam genutzten Konfigurationen;
SSH-Konfigurationen und Schlüssel;
lokale Cloud-Konfigurationen;
Build- und Deployment-Dateien;
Protokoll- und Cache-Verzeichnisse;
Verzeichnisse mit privaten Modellen oder internen Promptdaten.

Die entscheidende Frage ist nicht, ob eine Regel in einer Konfigurationsdatei steht. Sie lautet: Bleibt deny auch dann wirksam, wenn auto aktiviert ist? Führen Sie deshalb einen absichtlich ungefährlichen Überschreitungstest durch. Lassen Sie DAO-Code versuchen, eine Testdatei außerhalb des freigegebenen Arbeitsverzeichnisses anzulegen. Prüfen Sie danach die Datei, den Entscheidungsvermerk und den Prozessstatus. Verwenden Sie für diesen Test keine echte private Datei und keinen echten Schlüssel.

macOS kann zusätzliche Grenzen über Sandbox-Mechanismen setzen. Die Apple-Dokumentation zur macOS App Sandbox erklärt, dass App-Zugriffe auf Ressourcen gezielt eingeschränkt werden können. Das ersetzt keine DAO-Code-Regelprüfung: Ein nicht sandboxender Prozess, ein Shell-Unterprozess oder ein MCP-Server kann andere Zugriffspfade eröffnen. Behandeln Sie die macOS Seatbelt-Isolation daher als zusätzliche Schicht, nicht als Beweis für vollständige Prozesssicherheit.

Zweiter Prüfpunkt: Schutz von API-Schlüsseln und SSH-Zugangsdaten

Für die Teamfreigabe ist der Umgang mit Geheimnissen wichtiger als die Bezeichnung des Modus. Prüfen Sie mindestens DeepSeek API Key, SSH-Konfiguration, Cloud-Zugangsdaten und projektspezifische Schlüssel. Der Test muss drei Orte abdecken: Eingabe und Prompt, Prozessumgebung sowie Protokoll und Erinnerung.

Ein Schlüssel darf nicht in einer Fehlermeldung, einem Chatverlauf oder einer automatisch erstellten Zusammenfassung erscheinen. Er darf auch nicht unkontrolliert an einen Kindprozess vererbt werden. Das gilt selbst dann, wenn der Auftrag nur eine lokale Änderung verlangt. Ein Build- oder Testskript kann die Umgebung übernehmen und sensible Variablen ausgeben.

Nutzen Sie für jede Umgebung eine absichtlich ungültige Testkennung. Sie soll eindeutig erkennbar sein, darf aber keinen Zugriff ermöglichen. Führen Sie damit diese Prüfungen durch:

Suchen Sie nach dem Testwert in DAO-Code-Protokollen und temporären Dateien.
Prüfen Sie, ob der Wert an einen Shell-Unterprozess weitergereicht wird.
Beobachten Sie, ob eine externe Verbindung den Wert als Parameter oder Header verwendet.
Löschen Sie die Sitzung und prüfen Sie, ob der Wert in einer lokalen Erinnerung verbleibt.
Kontrollieren Sie, ob das Team die echte Kennung über den Systemschlüsselbund statt über eine Projektdatei bereitstellt.

Die offiziellen DAO-Code-Hinweise zu sensiblen Zielen, Geheimnisscans und SSRF-Schutz sind nützliche Kontrollpunkte. Sie sind jedoch keine vollständige Sicherheitsprüfung. Die OWASP-Empfehlungen für AI-Agenten weisen ebenfalls darauf hin, dass Agentenberechtigungen, externe Eingaben, Werkzeuge und Geheimnisse gemeinsam bewertet werden müssen.

Achtung: Ein Geheimnisscan findet nur Muster, die er kennt. Er beweist nicht, dass kein Schlüssel über eine ungewöhnliche Variable, eine Binärdatei, einen MCP-Aufruf oder eine Fehlermeldung nach außen gelangt.

Dritter Prüfpunkt: Wiederherstellung nach fehlerhaften Änderungen

Die Sicherheitsqualität eines automatischen Modus zeigt sich oft erst nach einem Fehler. Eine falsche Änderung ist beherrschbar, wenn sie in einem isolierten Arbeitsbaum entsteht, ein nachvollziehbarer Prüfpunkt existiert und die Rückkehr keinen produktiven Git-Verlauf beschädigt.

Prüfen Sie deshalb shadow-git nicht nur auf seine Existenz. Ermitteln Sie, wann ein Prüfpunkt erstellt wird, welche Dateien er erfasst und ob auch fehlgeschlagene Befehle dokumentiert werden. Testen Sie eine Änderung an einer ungefährlichen Beispieldatei. Lassen Sie danach eine zweite Aktion denselben Bereich fehlerhaft verändern. Stellen Sie anschließend den vorherigen Zustand wieder her und vergleichen Sie:

Arbeitsbaum vor und nach der Wiederherstellung;
normaler Git-Verlauf des Projekts;
unversionierte Dateien und temporäre Artefakte;
Protokolle des automatischen Vorgangs;
Dateien außerhalb des freigegebenen Bereichs.

Die Wiederherstellung muss auf den Testbereich begrenzt bleiben. Sie darf weder einen bereits veröffentlichten Commit umschreiben noch fremde Branches verändern. Wenn Ihr Team diese Grenze nicht sicher belegen kann, bleibt der Modus mit Einzelbestätigung die richtige Obergrenze.

Verwenden Sie zusätzlich das projektinterne Versionskontrollverfahren. Ein Schattenprüfpunkt ist kein Ersatz für Code Review, Branch-Schutz oder eine getestete Sicherung. Er kann eine schnelle lokale Rückkehr ermöglichen, aber keine fachliche Entscheidung darüber treffen, ob eine Änderung korrekt ist.

Vierter Prüfpunkt: Sichtbarkeit von Verantwortung und Auditdaten

Ein Team muss später beantworten können, wer eine riskante Aktion freigegeben hat, welches Werkzeug sie ausgelöst hat und welche Dateien betroffen waren. Das Protokoll sollte deshalb mindestens Entscheidung, Zeitpunkt, Ziel, Aktion, Ergebnis und verantwortliches Konto erkennen lassen. Prüfen Sie, ob Fehlermeldungen oder Eingaben dabei geheime Inhalte übernehmen.

Die OWASP-Leitlinie für sicheres Logging empfiehlt eine klare Trennung zwischen sicherheitsrelevanten Ereignissen und sensiblen Daten. Für DAO-Code bedeutet das: Protokollieren Sie den Namen eines Zielpfads, aber nicht automatisch dessen gesamten Dateiinhalt. Speichern Sie die Entscheidung für einen Netzwerkzugriff, aber nicht unmaskierte Authentifizierungsdaten.

Legen Sie vor der Einführung eine Verantwortungsmatrix fest:

Wer genehmigt Zugriffe auf externe Dienste?
Wer kontrolliert nach einem Vorfall die Protokolle?
Wer darf den Modus von Bestätigung auf auto ändern?
Wie wird eine Änderung der DAO-Code-Regeln dokumentiert?
Wann wird eine Umgebung nach einem fehlgeschlagenen Test verworfen?

Ein DevSecOps-Prozess sollte diese Entscheidungen mit Entwicklung, Betrieb und Sicherheit verbinden. Das NIST-Referenzmodell für DevSecOps kann dabei als organisatorische Orientierung dienen. Es ersetzt keine DAO-Code-spezifische Prüfung, verhindert aber, dass die Moduswahl allein beim Entwicklerkonto liegen bleibt.

Teamumgebungen nach Einsatzprofilen auswählen

Die folgenden Entscheidungsbedingungen sind wichtiger als eine pauschale Freigabe. Gehen Sie sie in der angegebenen Reihenfolge durch:

Wenn das Repository unbekannt ist oder externe Eingaben verarbeitet, wählen Sie plan. Fehlen Herkunft, Review oder klare Eigentümerschaft, darf DAO-Code zunächst analysieren und Vorschläge liefern. Für Schreib- und Shell-Aktionen wechseln Sie nicht direkt zu auto.
Wenn der Code vertraut ist, aber echte Zugangsdaten oder produktive Branches erreichbar sind, wählen Sie Einzelbestätigung. Jede Änderung an Konfiguration, Deployment, Netzwerkziel oder Berechtigung bleibt sichtbar freizugeben.
Wenn der Auftrag nur ein klar abgegrenztes Testverzeichnis betrifft, die deny-Regeln den Übergriff blockieren und die Geheimnisprüfung bestanden ist, testen Sie auto zunächst in einer isolierten Umgebung. Erst nach erfolgreicher Wiederherstellung und Protokollprüfung darf es als Teamprofil gespeichert werden.
Wenn die Umgebung jederzeit neu erstellt werden kann und keinerlei echte Schlüssel, Kundendaten oder produktive Git-Ziele enthält, kommt bypassPermissions beziehungsweise „yolo“ für einen kontrollierten Test infrage. Für ein dauerhaftes Projektprofil bleibt dieser Modus ungeeignet.
Wenn nur eine der Prüfungen fehlschlägt, gehen Sie einen Modus zurück. Ein unklarer Auditpfad bedeutet Bestätigung. Ein nicht getesteter Außenpfad bedeutet plan oder isolierte Analyse. Ein nicht belegter Rollback bedeutet keine automatische Freigabe.

Vergleichsmatrix für die Teamentscheidung

Prüfmerkmal	`plan`	Einzelbestätigung	`auto`	`bypassPermissions` / „yolo“
Analyse eines unbekannten Repositorys	Geeignet	Möglich, aber aufwendiger	Nicht empfohlen	Nicht geeignet
Schreibzugriffe	Vorschlag statt Freigabe	Jede kritische Aktion prüfbar	Nur in begrenztem Bereich	Weitgehend ungebremst
Shell- und Netzwerkaktionen	Vorher prüfen	Sichtbare Entscheidung	Nur nach Regel- und Sandbox-Test	Hohes Fehlerrisiko
Schutz echter Geheimnisse	Am leichtesten kontrollierbar	Kontrollierbar	Nur nach separater Geheimnisprüfung	Für echte Schlüssel ungeeignet
Rückkehr nach Fehländerung	Manuell	Mit Freigabepunkten	Nur mit getestetem `shadow-git`	Hoher Wiederherstellungsaufwand
Teamempfehlung	Fremder oder lesender Auftrag	Standardmodus	Begrenztes, abgenommenes Testprofil	Wegwerf-Sandbox

In der letzten Tabellenzeile steht bewusst keine automatische Freigabe für den Alltag. Ein Modus kann technisch funktionieren und trotzdem organisatorisch falsch sein. Besonders bei MCP-Diensten müssen Sie Herkunft, Werkzeuge, Netzwerkziele und Datenfluss einzeln prüfen. Die OWASP-Anleitung zur Agentensicherheit ist dafür eine geeignete Ergänzung, aber kein Freifahrtschein.

Begrenzung von DAO-Code auf das Arbeitsverzeichnis

Die Begrenzung gelingt nur, wenn drei Schichten zusammenpassen. Erstens muss DAO-Code Regeln für erlaubte, zu bestätigende und verbotene Ziele anwenden. Zweitens muss die macOS-Umgebung den Prozesszugriff tatsächlich einschränken. Drittens darf der gestartete Unterprozess keine weiterreichenden Rechte oder Geheimnisse erben.

Richten Sie zunächst ein eigenes Testverzeichnis ein. Legen Sie darin nur eine harmlose Beispieldatei und eine reproduzierbare Testaufgabe ab. Versuchen Sie anschließend, eine Datei im Elternverzeichnis, in einem separaten Projekt und in einem geschützten Konfigurationspfad anzulegen. Dokumentieren Sie für jeden Versuch:

ob DAO-Code die Aktion blockiert;
ob eine Bestätigung verlangt wird;
ob macOS Seatbelt oder eine andere Isolation zusätzlich eingreift;
ob ein Unterprozess trotzdem außerhalb schreiben kann;
ob der Vorfall im Auditprotokoll erscheint.

Verwenden Sie für die Prüfung niemals echte SSH-Schlüssel, Cloud-Tokens oder produktive Pfade. Nach dem Test löschen Sie die Umgebung und erstellen sie neu. Eine manuelle Bereinigung ist kein gleichwertiger Ersatz für eine reproduzierbare Neuaufsetzung.

Für wiederkehrende Teamumgebungen lohnt sich eine schriftliche Abnahme. Das deutsche Hilfecenter von Hashvps kann als interner Einstiegspunkt für Betriebsfragen dienen. Halten Sie dort beziehungsweise in Ihrer internen Dokumentation fest, welche Isolation, Zugriffsregeln und Wiederherstellungsprozedur für jede Umgebung gelten.

Zwei Einführungsprofile für Plattformadministratoren

Plattformadministratoren sollten nicht jedem Entwickler dieselbe Voreinstellung geben. Ein Analyseprofil darf nur lesen und planen. Ein Entwicklungsprofil kann bestätigte Änderungen im Arbeitsbereich ermöglichen. Ein Testprofil darf auto enthalten, wenn es nach jeder Sitzung zerstörbar ist. Die Profile müssen getrennte Zugangsdaten und getrennte Verzeichnisse verwenden.

Teamprofil	Geeigneter Modus	Mindestbedingungen vor der Freigabe	Ausschlussgrund
Analyse und Code Review	`plan`	Repository-Herkunft dokumentiert, keine Schreibfreigabe	Unbekannte externe Werkzeuge
Normale Entwicklung	Einzelbestätigung	Regelwerk, Geheimnisschutz, Audit und Review festgelegt	Produktionszugriff ohne Freigabepunkt
Isolierter Test	`auto`	Arbeitsbereich begrenzt, Überschreitung blockiert, `shadow-git` wiederhergestellt	Unklare Unterprozesse oder Netzwerkziele
Wegwerfbare Experimentumgebung	`bypassPermissions` / „yolo“	Keine echten Geheimnisse, keine Kundendaten, vollständige Löschbarkeit	Dauerhafte Codebasis oder produktive Branches

Vor der Übergabe an das Team sollte jede Umgebung diese Abnahme bestehen:

[ ] Die gewählte DAO-Code-Version und ihre Modi sind dokumentiert.
[ ] allow, ask und deny wurden mit einem Überschreitungstest geprüft.
[ ] Arbeitsverzeichnis und Elternverzeichnisse sind eindeutig getrennt.
[ ] Testschlüssel wurden nicht in Protokoll, Erinnerung oder Unterprozessumgebung gefunden.
[ ] SSH-, Cloud- und Build-Zugangsdaten liegen nicht als ungeschützte Projektdatei vor.
[ ] shadow-git kann eine Teständerung zurücknehmen, ohne den offiziellen Git-Verlauf zu beschädigen.
[ ] Auditdaten enthalten Entscheidungen und Ziele, aber keine unmaskierten Geheimnisse.
[ ] MCP-Werkzeuge und externe Netzwerkziele sind einzeln bewertet.
[ ] Eine zuständige Person genehmigt Modusänderungen.
[ ] Die Umgebung kann nach einem Fehltest reproduzierbar gelöscht und neu erstellt werden.

Wenn Sie diese Punkte nicht vollständig belegen können, bleiben Sie beim Bestätigungsmodus oder bei plan. Das ist keine unnötige Verlangsamung. Es ist eine klare Begrenzung der Verantwortung.

Für Teams, die DAO-Code nur zeitweise testen, kann eine getrennte Mac-Umgebung sinnvoller sein als die Vermischung mit dem täglichen Entwicklergerät. Ein lokaler Mac bietet zwar direkte Hardware- und Dateizugriffe, aber nicht automatisch eine saubere Trennung zwischen privatem Arbeitsbereich, Testprojekt und Zugangsdaten. Wenn Ihr Gerät keine unabhängige, zurücksetzbare Umgebung bereitstellt, prüfen Sie ein Hashvps-Mac-Paket für getrennte Arbeitsumgebungen. Eine gemietete Umgebung ist dabei kein Ersatz für Regeln oder Reviews. Ihr Vorteil liegt in der kontrollierbaren Übergabe und im leichteren Neuaufsetzen.

Die nüchterne Empfehlung lautet daher: Für die meisten Teams ist die automatische Ausführung von DAO-Code nicht der Standard, sondern eine Freigabe nach Messkriterien. plan schützt die Analyse unbekannter Projekte. Einzelbestätigung bleibt die belastbare Voreinstellung für normale Entwicklung. auto ist erst nach erfolgreicher Prüfung von Verzeichnisgrenzen, Geheimnissen, Wiederherstellung und Audit vertretbar. „Yolo“ gehört ausschließlich in eine isolierte Testumgebung ohne echte Daten und ohne dauerhaften Git- oder Netzwerkzugriff.