Sicherheit von Coding-Agenten in Engineering-Teams

Was ein Coding-Agent in Ihren Systemen tun kann

Diskussionen über AI Coding Security beginnen oft beim Modell. Nützlicher ist die Frage, was der Agent in Ihren Systemen tun kann. Auf einem Entwicklerrechner läuft ein CLI-Agent in der Regel unter dem Benutzerkonto des Engineers, mit Zugriff auf alles, was dieses Konto lesen kann, und auf die Zugangsdaten in Umgebungsvariablen, Konfigurationsdateien und im Git Credential Helper. Je nach Setup kann er:

• Quellcode, Konfiguration und lokale Dateien lesen, etwa .env oder Cloud-Zugangsdaten
• Builds, Tests, Paketinstallationen und beliebige andere Shell-Befehle ausführen
• Webseiten abrufen und APIs aufrufen, auch Paket-Registries
• MCP-Server nutzen, die eigene Zugangsdaten für Tracker, Datenbanken oder Cloud-Konten halten
• Committen, Branches pushen und Pull Requests öffnen, in der CI mit dem Token der Pipeline

Damit ist der Agent eine neue Art von Identität in Ihren Systemen. Er handelt mit geliehenen Rechten und hinterlässt oft keine eigenen Spuren. Außerdem nimmt er Anweisungen aus jedem Text entgegen, den er liest, auch aus Dateien, Issues, Webseiten und Tool-Ausgaben, die jemand anderes geschrieben hat. Wir behandeln ihn wie ein neues Service-Konto mit einem ungewöhnlichen Eingabekanal: eigene, eng gefasste Zugangsdaten, ein Protokoll seiner Aktionen und ein benannter Owner für seine Konfiguration.

Prompt Injection bei Coding-Agenten

OWASP führt Prompt Injection an erster Stelle der Top 10 for LLM Applications 2025. Unterschieden wird zwischen direkter Injection, bei der der eigene Prompt eines Nutzers das Verhalten des Modells verändert, und indirekter Injection, bei der das Modell Inhalte aus externen Quellen wie Webseiten oder Dateien aufnimmt. Externe Inhalte aufzunehmen ist der größte Teil dessen, was ein Coding-Agent tut.

Zu den nicht vertrauenswürdigen Eingaben gehören Dateien im Repository, die Mitwirkende geschrieben haben, der Quellcode von Abhängigkeiten, Issues und Kommentare in Pull Requests, Dokumentation und Webseiten aus der Recherche sowie die Ausgaben von Tools und MCP-Servern. Jede dieser Quellen kann Text enthalten, der für den Agenten wie eine Anweisung klingt, und dieser Text muss für einen Reviewer nicht einmal sichtbar sein.

Ein typisches Beispiel ist ein Markdown-Kommentar, den die gerenderte Seite nicht anzeigt. Er behauptet gegenüber KI-Agenten, die Tests bräuchten die Deployment-Zugangsdaten, und fordert sie auf, die Umgebungsdatei in die Beschreibung des Pull Requests zu kopieren. Wer das gerenderte README liest, sieht nichts Auffälliges.

OWASP hält fest, dass unklar ist, ob es narrensichere Methoden gegen Prompt Injection gibt, und davon gehen wir aus. Filter, Systemprompts und bessere Modelle machen Injections seltener erfolgreich, deshalb lautet die Designfrage, was eine gelungene Injection erreichen kann. Ein Agent, der nicht vertrauenswürdige Inhalte liest, Secrets hält und Daten nach außen geben kann (per Netzwerkaufruf, Commit oder Beschreibung eines Pull Requests), bietet einem Angreifer alles, was er braucht. Fällt eine dieser Bedingungen weg, hat eine erfolgreiche Injection deutlich weniger Spielraum.

Secrets, destruktive Befehle und Abhängigkeiten

Drei weitere Risiken gelten für jedes Tool. Keines setzt einen Angreifer voraus, aber Angreifer können alle drei nutzen.

Secrets im Kontext

Secrets gelangen auf ganz gewöhnlichen Wegen in den Kontext eines Agenten: Er öffnet eine .env-Datei, um die Konfiguration zu verstehen, gibt beim Debuggen Umgebungsvariablen aus oder liest ein Log, in dem ein Token steht. Das Secret geht dann mit der nächsten Anfrage an den Modellanbieter und kann in einem Commit, in der Beschreibung eines Pull Requests, in einem Sitzungsprotokoll oder in einer Anfrage an einen externen Host landen. Deny-Regeln für Secret-Dateien helfen. Mehr hilft es, Produktions-Secrets gar nicht erst in die Umgebung des Agenten zu bringen.

Destruktive Befehle

Ein Agent, der Shell-Befehle ausführen darf, kann auch den falschen ausführen: Dateien außerhalb der Aufgabe löschen, per Force-Push einen gemeinsamen Branch überschreiben, eine Migration gegen die falsche Datenbank laufen lassen oder eine Cloud-CLI aufrufen, die mit Administratorrechten angemeldet ist. Meist sind das Fehler, die nichts in der Umgebung aufgehalten hat. Freigabeabfragen fangen einen Teil davon ab. Für den Rest braucht es eine Umgebung ohne Produktionszugänge, mit geschützten Branches und mit Backups, deren Wiederherstellung jemand tatsächlich getestet hat.

Abhängigkeiten und erfundene Paketnamen

Agenten fügen Abhängigkeiten hinzu, sobald eine Aufgabe eine zu brauchen scheint, und Modelle schlagen manchmal Pakete vor, die es nicht gibt. Eine auf der USENIX Security 2025 vorgestellte Studie stellte fest, dass solche Paket-Halluzinationen bei den untersuchten kommerziellen und quelloffenen Modellen anhaltend und systematisch auftreten. Wer einen erfundenen Namen registriert, bekommt seinen Code bei jedem installiert, der dem Vorschlag folgt, und die Installationsskripte laufen mit den Rechten dieses Benutzers oder dieser Pipeline. Eine neue Abhängigkeit verdient dasselbe Review wie neuer Code, und ein Registry-Proxy mit Allowlist macht aus diesem Review eine Regel.

MCP-Server, Plugins und wohin Ihre Daten gehen

MCP-Server erweitern, was ein Agent erreichen kann. Ein Server für Ihren Issue-Tracker, Ihre Datenbank oder Ihr Cloud-Konto hält meist eigene Zugangsdaten, und der Agent kann alles tun, was diese Zugangsdaten erlauben. Die MCP-Spezifikation verlangt, dass Clients Tool-Annotationen als nicht vertrauenswürdig behandeln, sofern sie nicht von vertrauenswürdigen Servern stammen, und sieht vor, dass immer ein Mensch eingebunden ist, der Tool-Aufrufe ablehnen kann. Auch Tool-Ausgaben sind Text im Kontext des Modells, deshalb ist ein Server, der Tickets oder Webseiten zurückgibt, ebenfalls ein Kanal für Prompt Injection. Bevor ein Server auf Ihre Allowlist kommt, sollte jemand Folgendes wissen:

• Wer ihn pflegt und welche Version Sie pinnen
• Welche Zugangsdaten er hält und was sie erlauben
• Ob er Inhalte Dritter an das Modell zurückgibt
• Wer dafür verantwortlich ist und Updates prüft

Anweisungsdateien, Skills und Plugins von Dritten verdienen dieselbe Sorgfalt. Sie sind Text, dem der Agent mit Ihren Berechtigungen folgt, und manche bringen auch Skripte mit. Workflow-Plugins wie pstack, das Cursor-Plugin von Lauren Tan, bündeln Skills und Playbooks für wiederkehrende Engineering-Arbeit, darunter Läufe über Nacht, die Pull Requests bis zum Merge bringen. Die Playbooks geben dem Agenten Anweisungen und erzwingen nichts: Ob ein Merge stattfinden kann, entscheiden die Berechtigungen und Zugangsdaten des Agenten, Branch Protection, verpflichtende Reviews und die CI. Die Dokumentation von Claude Code sagt dasselbe über die eigenen Anweisungsdateien: Sie prägen, was der Agent zu tun versucht, ändern aber nichts daran, was Claude Code erlaubt.

pstack-Workflows in der Praxispstack im Rahmen unserer Cursor-Beratung

Jeder Agent schickt außerdem planmäßig Daten nach außen: Prompts, Dateiinhalte, Befehlsausgaben und Tool-Ergebnisse gehen an einen Modellanbieter, manchmal über ein Gateway, und manche Tools ergänzen Telemetrie oder Session-Sharing. Aufbewahrung, Nutzung für das Training und Verarbeitungsregion hängen vom Anbieter, vom Plan und von Ihrem Vertrag ab und können sich zwischen CLI, IDE-Erweiterung und Cloud-Agent eines Tools unterscheiden. Halten Sie den Datenfluss je Oberfläche schriftlich fest und lassen Sie ihn von Ihren Daten- und Vertragsverantwortlichen gegen Ihre Vereinbarungen prüfen. Wir dokumentieren ihn, können aber keine Zusagen im Namen eines Anbieters machen.

Sicherheitskontrollen für Coding-Agenten

Keine einzelne Kontrolle macht einen Agenten sicher, und keine der folgenden erhebt diesen Anspruch. Sie wirken als Schichten, die ein Fehler oder eine erfolgreiche Injection durchdringen muss, bevor Schaden entsteht.

• Berechtigungen der Coding-Agenten je Repository, möglichst zentral vorgegeben, mit freigegebenen Routinebefehlen, damit die übrigen Freigabeabfragen gelesen werden
• Sandboxing oder ein eigener Container bzw. eine eigene VM für unbeaufsichtigte Läufe, mit frischem Checkout und ohne Zugangsdaten des Hosts
• Eine Allowlist für ausgehenden Netzwerkverkehr mit Ihrem Git-Host, dem Registry-Proxy und dem Modell-Endpunkt
• Kurzlebige Zugangsdaten je Aufgabe, begrenzt auf ein Repository und die Aktionen, die die Aufgabe braucht
• Secret-Scanning in Pre-Commit-Hooks und in der CI, dazu Deny-Regeln für Secret-Dateien
• Eine Richtlinie für Abhängigkeiten: Registry-Proxy, Lockfiles und menschliches Review neuer Pakete
• Branch Protection, verpflichtende Checks und menschliches Review, die mit den Zugangsdaten des Agenten nicht änderbar sind

Zwei Aufzeichnungen gehören dazu. Die eine ist ein Audit-Log über Befehle, Tool-Aufrufe und Pushes, das nach einem Vorfall auch tatsächlich auffindbar ist, die andere die oben beschriebene MCP-Allowlist.

Pull Requests von Agenten reviewen

Kontrollen der Anbieter und ihre Grenzen

Die verbreiteten Tools bringen solche Kontrollen mit und dokumentieren ihre Grenzen offen. Claude Code hat Berechtigungsmodi sowie Allow-, Ask- und Deny-Regeln, die Administratoren über Managed Settings verbindlich vorgeben können. Laut Dokumentation gehört der Modus, der Berechtigungsabfragen überspringt, nur in isolierte Umgebungen wie Container oder VMs, und eine Deny-Regel für einen Shell-Befehl ist keine Sicherheitsgrenze um das Programm. OpenAI Codex kombiniert einen Sandbox-Modus mit einer Freigaberichtlinie, und im Standardmodus workspace-write bleibt der Netzwerkzugriff aus, solange Sie ihn nicht aktivieren.

GitHub dokumentiert eine Firewall, die den Internetzugang des Cloud-Agenten von GitHub Copilot standardmäßig begrenzt. Sie gilt für Prozesse, die der Agent über sein Bash-Tool startet, nicht aber für MCP-Server oder konfigurierte Setup-Schritte, und GitHub weist darauf hin, dass ausgefeilte Angriffe sie umgehen können. Bevor Sie sich auf eine Grenze verlassen, lesen Sie den Abschnitt zu den Einschränkungen des jeweiligen Tools und prüfen Sie, welche Kontrollen Ihr Plan enthält.

Unbeaufsichtigte Läufe in der CI und in Cloud-Umgebungen

Unbeaufsichtigte Läufe verändern das Risiko. Niemand sieht die Befehle, die Eingabe stammt oft aus einem Issue oder Pull Request, den jeder geschrieben haben könnte, und der Lauf hält ein Pipeline-Token. Zwei Vorfälle aus dem Jahr 2025 zeigen, wie viel von den Zugangsdaten rund um die Automatisierung abhängt.

Im Juli 2025 meldete AWS, dass ein zu weit gefasstes GitHub-Token im Build-Setup der Amazon Q Developer Extension für VS Code es einem Angreifer ermöglichte, Schadcode in das Open-Source-Repository der Extension zu committen. Der Code wurde mit Version 1.84.0 ausgeliefert und lief wegen eines Syntaxfehlers nicht. Im August 2025 erbeuteten Angreifer das npm-Token des Build-Systems Nx über einen GitHub-Actions-Workflow, der bei Pull Requests mit den Rechten des Ziel-Repositorys lief und die Titel von Pull Requests ungeprüft an die Shell übergab. Laut Postmortem des Nx-Teams versuchten die am 26. August veröffentlichten Schadversionen, lokale KI-Tools wie Claude und Gemini zu nutzen, während sie Rechner nach sensiblen Daten durchsuchten.

In keinem der beiden Fälle brauchte es einen raffinierten Angriff auf ein Modell. Beide hingen an Zugangsdaten mit mehr Reichweite, als die Aufgabe erforderte, und der zweite zeigt, dass Angreifer versuchen, die Agenten-CLIs auf Entwicklerrechnern zu nutzen. Für unbeaufsichtigte Läufe arbeiten wir nach diesen Regeln:

• Eine frische, isolierte Umgebung je Lauf, die danach verworfen wird
• Ausgehender Netzwerkverkehr nur über eine Allowlist mit Modell-Endpunkt und Paket-Proxy
• Zugangsdaten je Lauf, die auf ein Repository begrenzt sind und mit der Aufgabe ablaufen
• Der Agent pusht nur auf eigene Branches, und Pipeline-Code entscheidet, ob ein Pull Request geöffnet oder gemergt wird
• Verpflichtende Checks und menschliches Review, die das Token des Agenten weder ändern noch umgehen kann
• Keine Läufe mit Secrets bei Ereignissen, die externe Mitwirkende auslösen können

Runmill, ein Open-Source-Projekt unseres Gründers im Status Developer Preview, folgt diesem Muster. Der Agent arbeitet in einem isolierten Workspace, genau der Kandidaten-Commit muss die erforderlichen Checks und ein Review in frischem Kontext bestehen, und über Pushes, Pull Requests und Merges entscheidet deterministischer Code, nie der Agent.

Die autonome Software-FabrikHarness Engineering für delegierte Cloud-Umgebungen

Governance, Zuständigkeiten und Incident Response

Ohne Owner driften Kontrollen auseinander. Die Konfiguration der Agenten, von Anweisungsdateien und Berechtigungen bis zu Hooks, MCP-Konfiguration und Plugin-Versionen, gehört in die Versionskontrolle, mit einem benannten Owner und einem Änderungsprozess. Änderungen daran brauchen das Review dieses Owners, auch wenn der Agent sie selbst vorschlägt. Außerdem entscheidet jemand, welche Tools, MCP-Server und Plugins freigegeben sind und wer Ausnahmen genehmigen darf.

Wenn etwas schiefgeht

1. 1

   Stoppen und Zugriff entziehen

   Laufende Sessions stoppen und die Zugangsdaten des Agenten widerrufen, einschließlich der Tokens von MCP-Servern und aller CI-Tokens in seiner Reichweite.

2. 2

   Den Ablauf rekonstruieren

   Mit Audit-Logs, Sitzungsprotokollen und der Git-Historie klären, was der Agent gelesen, ausgeführt, gesendet und gepusht hat.

3. 3

   Rotieren und aufräumen

   Jedes Secret rotieren, das in den Kontext gelangt sein könnte, und betroffene Branches, Pakete und Build-Artefakte zurücksetzen oder isolieren.

4. 4

   Die Kontrolle nachschärfen

   Die Berechtigung, den Umfang der Zugangsdaten oder die Review-Regel ändern, die den Vorfall zugelassen hat, und die Korrektur am tatsächlichen Ablauf prüfen.

Betriebsrat und Datenschutz in der KI-Softwareentwicklung

Dieser Teil ist eine praktische Orientierung und keine Rechtsberatung. Nach § 87 Abs. 1 Nr. 6 BetrVG hat der Betriebsrat, soweit keine gesetzliche oder tarifliche Regelung besteht, bei der Einführung und Anwendung technischer Einrichtungen mitzubestimmen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen. Nutzungs-Dashboards, Sitzungsprotokolle und personenbezogene Kennzahlen der Agenten können diese Frage aufwerfen. Beziehen Sie den Betriebsrat deshalb vor dem Rollout ein und vereinbaren Sie, was protokolliert wird, wer es sieht und wie lange es aufbewahrt wird. Wir werten Pilotprojekte nach Team, Aufgabe und Modell aus, nie nach einzelnen Engineers.

Der Datenschutz läuft parallel. Code, Commit-Historie, Tickets und Logs enthalten oft personenbezogene Daten, von Autorennamen bis zu Kundendaten in Test-Fixtures, und für alles davon, was bei einem Modellanbieter ankommt, gilt die DSGVO. Ihr Datenschutzbeauftragter wird den schriftlichen Datenfluss sehen wollen, die Verarbeitungsbedingungen des Anbieters, Aufbewahrung und Region sowie eine Entscheidung darüber, was in den Kontext eines Agenten gelangen darf.

Agent surface:      <agent> CLI on developer laptops
Model endpoint:     <provider, account, region>
Gateway:            <none, or name and owner>
Sent:               prompts, file contents, command output, tool results
Kept out:           .env, secrets/, customer-data/
Retention:          <per contract, checked on YYYY-MM-DD>
Training use:       <per contract and plan settings>
Telemetry:          <setting and destination>
Credentials held:   <token, scope, lifetime, owner>
MCP servers:        <name, pinned version, owner, credential scope>
Config owner:       <team>
Next review:        <date>

Wie Cloudsail unterstützt

Wir erledigen diese Arbeit gemeinsam mit Ihren Engineers und Ihrem Security-Team, in Ihren eigenen Repositories: Harness und Berechtigungen für jedes Tool, das Sie einsetzen, schriftlich festgehaltene Datenflüsse sowie isolierte Umgebungen mit eng gefassten Zugangsdaten für unbeaufsichtigte Läufe. Jede Änderung prüfen wir an repräsentativen Aufgaben, bevor sie teamübergreifend geteilt wird.

Workshops finden remote oder vor Ort in Deutschland und Polen statt, auf Deutsch, Englisch oder Polnisch, als Sessions mit einem Team in dessen eigenen Repositories. Offene Kurse und Zertifikate bieten wir nicht an. Ihr Plattformteam behält die Konfiguration, die Runbooks und die Begründung hinter jeder Einstellung.

Harness Engineering für Coding-AgentenRollout von Coding-AgentenClaude Code: Berechtigungen und Rollout