KI-Werkzeuge im Entwicklungsteam freigeben: welche Leitplanken es braucht

01

Warum braucht ein Coding-Agent andere Regeln als eine Autovervollständigung?

Eine Autovervollständigung schlägt Text vor, den ein Mensch annimmt. Ein Coding-Agent handelt: Er liest Dateien, führt Befehle aus, installiert Pakete und ruft externe Werkzeuge auf. Für ihn gelten dieselben Fragen wie für jedes Konto mit Rechten, plus eine neue: Anweisungen können in Dateien, Tickets oder Webseiten stecken, die er liest.

Das OWASP-Projekt beschreibt beide Risiken für Anwendungen mit Sprachmodellen. Excessive Agency entsteht aus zu viel Funktionalität, zu vielen Rechten oder zu viel Autonomie; als Gegenmaßnahme nennt OWASP unter anderem, dass Menschen folgenreiche Aktionen vorher freigeben (OWASP, 2025). Indirekte Prompt Injection liegt vor, wenn ein Modell Eingaben aus externen Quellen wie Webseiten oder Dateien verarbeitet (OWASP, 2025). Im Repository heißt das: Eine README, ein Issue oder eine Abhängigkeit kann Text enthalten, der wie eine Anweisung wirkt.

Der DORA-Bericht 2025 findet einen positiven Zusammenhang zwischen KI-Nutzung und Auslieferungsdurchsatz, aber weiterhin einen negativen mit der Stabilität der Auslieferung (Google Cloud, 2025). Was Studien zur Qualität generierten Codes zeigen und wo ihre Grenzen liegen, fasst Was Studien über die Qualität KI-generierten Codes zeigen zusammen. Welcher Agent zu welchem Team passt, vergleicht Coding-Agent wählen.

02

Was darf automatisch laufen, und was nie?

Automatisch laufen darf, was im Arbeitsverzeichnis bleibt und sich leicht rückgängig machen lässt: Lesen, Suchen, Tests und Linter. Mit Rückfrage laufen Paketinstallationen und Netzwerkzugriffe. Nie durch den Agenten laufen sollten das Zusammenführen in geschützte Branches, Auslieferungen, Zugriffe auf Produktionsdaten und das Lesen von Geheimnissen.

Die Angaben folgen der Herstellerdokumentation (Claude Code Permissions, Claude Code Sandboxing, Cursor Run Modes, Copilot Risks and Mitigations, Copilot Content Exclusion). Namen und Funktionen ändern sich zwischen Versionen.

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(git push *)"],
    "ask": ["Bash(npm install *)"],
    "disableBypassPermissionsMode": "disable"
  }
}

03

Wie erzwingen Sie eine Prüfung vor dem Zusammenführen?

Eine Prüfung ist erzwungen, wenn die Plattform sie verlangt, nicht wenn eine Richtlinie sie empfiehlt. Auf GitHub leisten das Rulesets mit Pull-Request-Pflicht, Mindestzahl an Freigaben, verworfenen Freigaben nach neuen Commits, Freigabe durch jemand anderen als die letzte pushende Person und verpflichtenden Statusprüfungen vor dem Zusammenführen.

Zwei dieser Optionen passen besonders zu KI-Werkzeugen (GitHub Docs). Verworfene Freigaben verhindern, dass eine letzte Korrektur durch den Agenten ungeprüft mitläuft. Die Freigabe durch eine andere Person als die letzte pushende verhindert, dass jemand eine Änderung mit dem eigenen Agenten nachschiebt und sie selbst freigibt. Für den Copilot Cloud Agent beschreibt GitHub eine eingebaute Variante: Die beauftragende Person kann seinen Pull Request nicht freigeben, und Workflows starten standardmäßig erst, wenn eine Person mit Schreibrechten sie nach Prüfung zulässt. Für Pfade wie Authentifizierung oder Datenbankmigrationen verlangt eine Code-Owner-Regel die Freigabe der Zuständigen.

Worauf Prüfende bei generierten Änderungen achten

• Geänderte oder gelöschte Tests. Ein Agent, der Tests grün machen soll, kann auch den Test ändern.
• Neue Abhängigkeiten. Existiert das Paket, wird es gepflegt, passt die Lizenz?
• Berechtigungsprüfungen. Sitzt die Prüfung im Server oder nur in der Oberfläche?
• Pipeline und Konfiguration. Änderungen an CI-Dateien, Rechten oder Umgebungsvariablen verdienen eine zweite Person.
• Umfang. Ein Diff, den niemand in Ruhe lesen kann, ist nicht geprüft. Kleine Aufträge ergeben prüfbare Pull Requests.

Welche Schuldenmuster sich in generiertem Code häufen, beschreibt Technische Schulden in KI-generiertem Code erkennen.

04

Wie halten Sie Geheimnisse aus der Reichweite des Agenten?

Geheimnisse sind sicher, wenn sie gar nicht erst in der Umgebung liegen, in der der Agent arbeitet. Ausschlussregeln und Ignore-Dateien helfen, sind aber keine Grenze. Wirksam sind Entwicklungszugänge ohne Produktionsrechte, eine Sandbox mit erlaubten Netzwerkzielen und eine Sperre, die erkannte Geheimnisse beim Push in das Repository abweist.

• Ausschluss ist keine Grenze. Laut Cursor-Dokumentation verhindert .cursorignore den Zugriff über Terminal- und MCP-Werkzeuge nicht. Anthropic beschreibt Bash-Regeln in Claude Code ausdrücklich nicht als Sicherheitsgrenze und verweist dafür auf die Sandbox.
• Sitzungsverläufe liegen lokal. Claude Code speichert sie laut Anthropic-Dokumentation (2026) standardmäßig 30 Tage im Klartext unter ~/.claude/projects/ (Anthropic). Ein in eine Sitzung kopierter Schlüssel liegt danach auf der Festplatte.
• Push-Schutz. GitHub blockiert erkannte Geheimnisse unter anderem bei Pushes über die Kommandozeile. Für Repositorys setzt das GitHub Secret Protection voraus; Personen mit Schreibrechten können die Sperre mit Begründung umgehen, was einen Alarm erzeugt (GitHub Docs).
• Kurzlebige Zugänge. Entwicklungsumgebungen erhalten eigene Schlüssel mit engen Rechten, die sich ohne Folgen widerrufen lassen.

05

Dürfen Kundendaten in ein KI-Werkzeug?

Das entscheidet sich an Vertrag und Konfiguration des konkreten Plans: ob Eingaben zum Training genutzt werden, wie lange der Anbieter sie speichert, wo verarbeitet wird und ob ein Vertrag zur Auftragsverarbeitung besteht. Für die Entwicklung selbst reichen meist synthetische oder anonymisierte Daten, und Produktionsdaten gehören nicht in Arbeitsverzeichnisse, die ein Agent liest.

Die Herstellerangaben unterscheiden deutlich nach Plan. Anthropic schreibt, dass Code und Prompts unter kommerziellen Bedingungen (Team, Enterprise, API) nicht zum Training genutzt werden, sofern der Kunde nicht ausdrücklich zustimmt, und nennt dort eine Standardaufbewahrung von 30 Tagen; für Verbraucherpläne gelten andere Regeln (Anthropic). Cursor beschreibt einen Privacy Mode ohne Training auf Nutzerdaten, den Team-Administratoren aktivieren können (Cursor). Bei GitHub lösen seit März 2026 die Generative AI Services Terms die zuvor geltenden produktspezifischen Bedingungen ab.

06

Wie gehen Sie mit Herkunft und Lizenzen generierten Codes um?

Generierter Code kann öffentlichem Code ähneln, auch lizenzpflichtigem. Manche Werkzeuge prüfen das: GitHub Copilot vergleicht Vorschläge mit öffentlichem Code und kann Treffer blockieren oder mit Lizenzangabe anzeigen. Wo ein Werkzeug das nicht bietet, bleiben die Lizenzprüfung von Abhängigkeiten in der Pipeline und ein genauer Blick auf auffällig vollständige Codeblöcke.

Laut GitHub vergleicht Code Referencing einen Vorschlag samt etwa 150 Zeichen umgebendem Code mit einem Index öffentlicher Repositorys auf GitHub.com; Treffer betreffen typischerweise weniger als ein Prozent der Vorschläge (GitHub Docs, 2026). Über die Richtlinie Suggestions matching public code werden Treffer blockiert oder mit Fundstelle und Lizenz angezeigt. Selbst geschriebener oder nachträglich veränderter Code wird dabei nicht geprüft (GitHub Docs).

Für die Richtlinie heißt das: festlegen, welche Filter aktiv sind, Lizenzen von Abhängigkeiten automatisch prüfen und größere, bibliotheksartige Blöcke vor der Übernahme auf ihre Herkunft ansehen. Die Rechtslage zu Haftung für generierten Code beschreibt Wer haftet, wenn KI-generierter Code Schaden anrichtet?. Anbieterbedingungen wie die Commercial Terms von Anthropic ändern sich und sind im jeweils gültigen Stand zu lesen.

07

Wie bleibt nachvollziehbar, was ein Werkzeug geändert hat?

Nachvollziehbar bleibt es, wenn jede Änderung über Branch und Pull Request läuft, die Beschreibung den Auftrag an das Werkzeug nennt und die Konfiguration des Werkzeugs selbst versioniert ist. Ob generierter Code zusätzlich im Commit gekennzeichnet wird, entscheidet die Richtlinie. Wichtig ist, dass diese Entscheidung für alle Repositorys einheitlich gilt.

Der Copilot Cloud Agent schreibt Commits laut GitHub unter eigenem Namen und trägt die beauftragende Person als Co-Autorin ein (GitHub Docs); Git kennt dafür den Trailer Co-authored-by (GitHub Docs). Bei Claude Code liegen gemeinsame Projekteinstellungen in .claude/settings.json im Repository, verbindliche Vorgaben in Managed Settings mit höchster Priorität (Anthropic). So bleibt erkennbar, unter welchen Regeln eine Änderung entstand.

08

Wie ist eine interne Richtlinie aufgebaut?

Eine tragfähige Richtlinie ist kurz und beschreibt Prinzipien, Zuständigkeiten und Ausnahmen. Die konkreten Regeln stehen in Konfiguration: Managed Settings, Rulesets, Push-Schutz. So veraltet das Dokument nicht still, wenn ein Werkzeug eine Funktion umbenennt, und die Durchsetzung hängt nicht davon ab, dass jede Person das Dokument kennt.