Rechte, Zugriffe und Command-Ausführung

Stand: 2026-06-03

Kurzfassung

KI darf nicht pauschal Vollzugriff bekommen.
KI braucht einen definierten Projekt-Arbeitsraum.
Commands sind standardmäßig blockiert.
Erlaubte Commands werden projektbezogen freigegeben.
Zielbild: Commands laufen über tools/ai-run und .ai-commands-allowlist.
Produktion, Secrets, Home-Verzeichnis und andere Kundenprojekte bleiben tabu.

Thema

Rechte und Zugriffe beim Einsatz von KI-Assistenten, Agenten und KI-gestützten IDEs im Entwickleralltag.

Ausgangslage

KI-Assistenten in Entwicklungs-IDEs bekommen aus praktischen Gründen oft breite Rechte:

Projektdateien lesen,
Dateien schreiben,
Code ändern,
Shell-Commands ausführen,
lokale Entwicklungsumgebungen wie Docker oder ddev bedienen,
mehrere Projektkontexte analysieren.

In realen Migrationsprojekten kann dieser breite Kontext notwendig sein. Beispiel: Ein Legacy-Projekt und ein Relaunch-Projekt müssen gemeinsam analysiert werden, um Code- und Datenmigrationen zu planen und lokal zu testen.

Die wichtigste praktische Erkenntnis:

Vollzugriff ist nicht das Ziel. Ein definierter Arbeitsraum mit erlaubten Projekten, erlaubten lokalen Umgebungen und verbotenen Zielsystemen ist das Ziel.

Risiko in einem Satz

KI-Assistenten können durch breite IDE- und Shell-Rechte unbeabsichtigt auf sensible Dateien, andere Kundenprojekte, lokale Credentials, externe Systeme oder produktionsnahe Zugänge zugreifen.

Empfehlung

KI darf in lokalen Entwicklungsumgebungen arbeiten, aber nur innerhalb eines definierten projektbezogenen Arbeitsraums.

Der Arbeitsraum muss festlegen:

welche Projektordner gelesen werden dürfen,
wo geschrieben werden darf,
welche lokalen Entwicklungsumgebungen genutzt werden dürfen,
welche Commands erlaubt sind,
welche Systeme und Daten tabu bleiben.

Für Command-Ausführung gilt:

Standard ist: nichts ausführen. Beim ersten Command wird gefragt. Erlaubnis gilt entweder einmalig oder projektbezogen über eine Allowlist.

Rechte-Stufen

Stufe 1: Chat

nur manuell kopierter Text,
kein direkter Dateizugriff.

Stufe 2: Projektkontext lesen

KI darf definierte Projektdateien lesen,
.aiignore oder gleichwertige Ausschlüsse gelten.

Stufe 3: Dateien schreiben

KI darf Code oder Patches schreiben,
Schreibbereich ist begrenzt,
Review bleibt Pflicht.

Stufe 4: Commands ausführen

KI darf lokale Commands ausführen,
aber nur über definierte Regeln, Projekt-Working-Directory und Allowlist.

Arbeitsraum-Regel

Für komplexe Aufgaben wie Migrationen darf KI mehrere Projektkontexte sehen, wenn ein klarer Arbeitsraum definiert ist.

Beispiel:

erlaubt: legacy/
erlaubt: relaunch/
erlaubt: lokale ddev/docker-Umgebung dieser Projekte
erlaubt: separater migration/-Arbeitsordner
verboten: Home-Verzeichnis, Downloads, SSH-Keys, andere Kundenprojekte, Produktionszugänge

Schreibzugriff sollte enger sein als Leserechte:

Legacy lesen,
Relaunch oder migration/ schreiben,
Legacy nur nach expliziter Freigabe verändern.

Command-Gate

KI soll Commands nicht direkt ausführen. Commands sollen durch ein Projekt-Gate laufen.

Empfohlener Ansatz:

tools/ai-run <command>

tools/ai-run prüft:

Projektkontext,
Arbeitsverzeichnis,
.ai-commands-allowlist,
harte Blocklist,
riskante Commands,
Freigabestatus.

Wandregel:

KI führt Commands nicht direkt aus. Commands laufen durch ein Projekt-Gate.

`.ai-commands-allowlist`

Empfohlene Projektdatei:

.ai-commands-allowlist

Zweck:

erlaubte lokale Commands dokumentieren,
unbekannte Commands blockieren,
wiederkehrende Commands projektbezogen freigeben,
riskante Commands sichtbar machen.

Beispiel:

project: relaunch-migration

allowed:
  - name: ddev status
    command: "ddev status"
    cwd: "."
    mode: always

  - name: Symfony console read-only
    command: "ddev exec php bin/console *"
    cwd: "."
    mode: ask-first
    write: false
    network: local-only

blocked:
  - "git push*"
  - "ssh *"
  - "scp *"
  - "cat .env*"
  - "printenv*"
  - "history"
  - "rm -rf *"
  - "*prod*"
  - "*production*"

Freigabearten

einmalig erlauben
für dieses Projekt erlauben
blockieren

Riskante Commands sollen auch bei bestehender Allowlist erneut fragen.

Erlaubt, wenn lokal und projektbezogen

ddev status
ddev exec ...
ddev logs
bin/console ...
lokale Tests
lokale Builds
lokale Migrationstests
lokale Datenbankstruktur prüfen
lokale Entwicklungsdaten importieren oder exportieren, wenn keine echten Kundendaten enthalten sind

Nur nach expliziter Freigabe

composer update
npm install
Datenbankimport oder Datenbankexport
Datei- oder Ordnerlöschung
git pull
Branch-Wechsel
Commands mit externem Netzwerkzugriff
Änderungen an Docker, ddev, CI/CD oder Deployment-Konfiguration

P0-No-Gos

Keine Produktionsdeployments durch KI.
Kein Produktionsdatenbankzugriff durch KI.
Keine Produktions-SSH-Zugänge durch KI.
Keine Commands, die Secrets aus .env, Shell-History, Keychain oder SSH-Dateien auslesen.
Kein Zugriff auf Home-Verzeichnis, Downloads oder andere Kundenprojekte ohne expliziten Arbeitsraum.
Kein git push durch KI ohne separate menschliche Freigabe.
Keine Commands, die Zugangsdaten in Logs oder KI-Kontext bringen.

Technische Umsetzungsstufen

Stufe 1: Leitplanke

KI-Regel: Commands nur über tools/ai-run.
.ai-commands-allowlist im Projekt.
Review von Änderungen an Allowlist und KI-Regeln.

Stufe 2: Projektstandard

CI oder Pre-Push prüft, ob .ai-commands-allowlist existiert.
CI oder Pre-Push prüft, ob harte Blocklist-Regeln nicht entfernt wurden.
Team nutzt tools/ai-run als Standard für KI-Command-Ausführung.

Stufe 3: Technisch härter

KI läuft in Container, Dev Container, Remote Workspace oder eingeschränktem User-Kontext.
Direkte Shell-Ausführung wird eingeschränkt.
PATH oder Tool-Zugriff wird so begrenzt, dass Commands über Wrapper laufen.
Keine Produktions-Credentials im KI-Arbeitsraum.

Grenze der Empfehlung

Eine .ai-commands-allowlist ist nur dann technisch zuverlässig, wenn KI nicht direkt die Shell umgehen kann.

Wenn eine IDE oder ein Agent direkten Terminalzugriff hat, ist die Allowlist zunächst eine starke Arbeitsregel, aber noch keine harte technische Kontrolle.

Für sensible Projekte sollte deshalb eine Sandbox, ein Container oder ein Remote-Workspace geprüft werden.

Vorgeschlagene Wandregel

Neue Commands sind blockiert. Erlaubt wird nur projektbezogen und mit Zweck.

Alternative Kurzregel: