AI-Coding-Agenten sind jetzt Teil der Angriffsfläche

Pwn2Own Berlin 2026 ist ein nützliches Signal für alle, die AI-Coding-Tools in der Softwareentwicklung einsetzen.

Der Wettbewerb hat dieses Jahr eine eigene Kategorie für Coding-Agenten. Zu den geplanten Zielen gehören OpenAI Codex, Anthropic Claude Code und Cursor. Sicherheitsforscher schauen also nicht mehr nur auf Betriebssysteme, Browser und Server. Sie schauen direkt auf die Werkzeuge, die heute Repositories lesen, Befehle ausführen, Dependencies installieren, APIs nutzen und Entwicklern beim Ausliefern von Software helfen.

Das ist relevant.

In den letzten Monaten drehte sich die Business-Diskussion über AI-Coding-Agenten vor allem um Produktivität. Schreiben sie Features schneller? Reduzieren sie Backlog? Können Gründer Prototypen ohne großes Team bauen? Können Entwickler langweilige Implementierungsaufgaben abgeben?

Diese Fragen bleiben wichtig. Aber Pwn2Own zeigt eine reifere Frage:

Was passiert, wenn der Coding-Agent selbst ein attraktives Angriffsziel wird?

Das ist kein Grund für Panik und auch kein Argument, solche Tools pauschal zu verbieten. Es ist ein Grund, sie als ernstzunehmende Software in der Delivery-Kette zu behandeln.

Ein Coding-Agent ist nicht nur ein Editor-Feature

Das einfachste mentale Modell für AI-Coding-Tools lautet: Autocomplete, nur besser.

Dieses Modell ist inzwischen zu klein.

Ein moderner Coding-Agent kann große Teile eines Repositories lesen, Tickets inspizieren, Dateien ändern, Shell-Befehle ausführen, Packages installieren, Branches erstellen, Tests schreiben, Pull Requests öffnen und externe Werkzeuge verbinden. In manchen Setups bekommt er außerdem Zugriff auf Dokumentation, Issue-Tracker, Cloud-Konsolen, Datenbanken, Logs oder Deployment-Workflows.

Genau deshalb sind diese Tools wertvoll. Sie bewegen sich von Vorschlag zu Ausführung.

Aber Software, die in einer Entwicklungsumgebung handeln kann, ist nicht nur eine Komfortschicht. Sie wird Teil der Sicherheitsgrenze rund um das Produkt.

Wenn ein Angreifer beeinflussen kann, was der Agent liest, was er ausführt, welche Tools er aufruft, welche Credentials er sieht oder welchen Dateien er vertraut, ist das Risiko nicht mehr theoretisch. Der Agent sitzt in der Nähe von Quellcode, Secrets, Dependencies, Build-Systemen und manchmal produktionsnahen Workflows.

Das ist eine privilegierte Position.

Gründer und Produktteams müssen nicht jede Exploit-Technik im Detail verstehen, um bessere Entscheidungen zu treffen. Sie müssen nur die architektonische Realität akzeptieren: Coding-Agenten gehören ins Threat Model.

Das Risiko ist nicht nur schlechter generierter Code

Viele Teams verstehen bereits ein AI-Risiko: Der Agent könnte falschen Code schreiben.

Das stimmt, ist aber nur eine Ebene.

Das tiefere Risiko ist, dass der Agent in einer größeren Umgebung arbeitet:

auf dem Rechner des Entwicklers;
im Repository und dessen Konfiguration;
bei der Installation von Dependencies;
in Test- und Build-Skripten;
mit lokalen Environment-Variablen;
mit verbundenen SaaS-Tools;
mit CI/CD-Tokens;
mit Browser-Sessions;
mit Projektdokumentation;
mit Memory- und Kontextdateien;
mit MCP-Servern und Tool-Integrationen.

Ein AI-Coding-Workflow kann scheitern, obwohl der generierte Code vernünftig aussieht. Das Problem kann darin liegen, wie der Agent instruiert wurde, welchem Kontext er vertraut hat, welchen Befehl er ausgeführt hat, welches Package er installiert hat, welches Credential sichtbar war oder welche Änderung normale Reviews umgangen hat.

Deshalb ist die Pwn2Own-Kategorie strategisch interessant. Sie behandelt Coding-Agenten als angreifbare Runtime-Umgebungen, nicht nur als Codegeneratoren.

Für ernsthafte Unternehmen ist genau das der richtige Blick.

Produktivitätswerkzeuge werden Supply-Chain-Werkzeuge

Softwareteams wissen bereits, dass die Supply Chain wichtig ist. Dependencies, Package-Registries, CI-Systeme, GitHub Actions, Docker-Images und Build-Skripte wurden zu Sicherheitsthemen, weil sie auf dem Weg von Idee zu Produktion liegen.

Coding-Agenten kommen jetzt auf diesen Weg dazu.

Sie können:

Dependencies vorschlagen;
Lockfiles ändern;
Build-Skripte anpassen;
Infrastrukturkonfiguration verändern;
Migrationscode erzeugen;
Tests generieren;
Authentifizierungslogik ändern;
sicherheitskritischen Code zusammenfassen oder umschreiben;
Repository-Aufgaben automatisieren.

Das macht sie nicht schlecht. Es macht sie folgenreich.

Ein kompromittierter oder schlecht kontrollierter Coding-Agent-Workflow kann ein ähnliches Geschäftsrisiko erzeugen wie ein kompromittierter CI-Token oder eine bösartige Dependency: Das Werkzeug wird vertraut, weil es Teil davon ist, wie Software gebaut wird.

Das ist besonders wichtig für kleine und mittelgroße Teams. Ein Konzern hat vielleicht getrennte Prozesse für Endpoint Security, Application Security, DevOps, Platform Engineering und Einkauf. Ein gründergeführtes SaaS-Team oder eine Mittelstand-Produktgruppe arbeitet oft mit deutlich kleinerer Struktur. Dieselbe Person wählt das Tool, verbindet das Repository, akzeptiert den Pull Request und deployed die Änderung.

In so einem Umfeld muss das Sicherheitsmodell einfach genug sein, um genutzt zu werden, und stark genug, um etwas zu bewirken.

Wie ein vernünftiges Einführungsmodell aussieht

Der erste Schritt ist keine 40-seitige AI-Richtlinie. Der erste Schritt ist die Entscheidung, wo der Agent arbeiten darf.

Gute Fragen sind:

Auf welche Repositories darf der Agent zugreifen?
Darf er allen Code lesen oder nur ausgewählte Projekte?
Darf er beliebige Shell-Befehle ausführen?
Darf er Dependencies installieren?
Darf er Secrets oder Environment-Variablen sehen?
Darf er produktive Daten verwenden?
Darf er Infrastruktur- oder Deployment-Dateien ändern?
Darf er direkt Pull Requests öffnen?
Welche Änderungen brauchen immer menschliches Review?
Welche Logs bleiben erhalten, wenn der Agent handelt?

Diese Fragen sind keine Bürokratie. Sie sind das minimale Betriebsmodell für Software, die im Delivery-Prozess handeln kann.

Bei McDougall Digital betonen wir hier meistens einen einfachen Punkt: AI-unterstützte Entwicklung wird deutlich sicherer, wenn Architektur und Workflow die Grenzen festlegen, nicht die Stimmung der Person, die das Tool gerade benutzt.

Produktion bleibt am Anfang weit weg

Viele Probleme verschwinden, wenn Teams mit einer einfachen Regel starten: Coding-Agenten berühren standardmäßig keine produktiven Systeme.

Das bedeutet:

keine produktiven Datenbank-Credentials in der Agent-Umgebung;
keine echten Kundendaten in Prompts oder lokalem Kontext;
keine Deployment-Rechte in normalen Coding-Sessions;
kein unbeschränkter Zugriff auf Cloud-Konsolen;
keine automatischen Infrastrukturänderungen;
keine irreversiblen Befehle ohne explizite Freigabe.

Das macht die Tools nicht nutzlos. Die meiste sinnvolle Coding-Agent-Arbeit passiert vor Produktion: Refactoring, Testgenerierung, Dokumentationspflege, Bug-Analyse, interne Tools, Scaffolding, Code-Review-Unterstützung und Pull-Request-Vorbereitung.

Ein Team kann echte Produktivitätsgewinne erzielen, ohne den Agenten neben produktive Credentials zu setzen.

Dasselbe gilt für Kundendaten. Wenn ein Agent realistische Daten für Tests braucht, nutzt man synthetische oder anonymisierte Fixtures. Wenn er Logs braucht, werden sie sauber begrenzt. Wenn er Zugriff auf Staging braucht, bleibt Staging klar von Produktion getrennt.

Das Ziel ist nicht, AI grundsätzlich zu misstrauen. Das Ziel ist, Fehler überlebbar zu machen.

Agent-Konfiguration ist sicherheitsrelevant

Viele Coding-Agent-Setups enthalten inzwischen Projektanweisungen, Memory-Dateien, Tool-Definitionen, lokale Skripte, MCP-Server-Konfiguration, Custom Commands und umgebungsspezifische Regeln.

Solche Dateien wirken schnell wie harmlose Dokumentation.

Das sind sie nicht immer.

Wenn ein Agent vor seiner Arbeit eine Repository-Anweisung liest, kann diese Datei sein Verhalten beeinflussen. Wenn eine lokale Tool-Definition beschreibt, wie ein Service aufgerufen wird, enthält sie Annahmen über Vertrauen. Wenn eine Memory-Datei früheren Projektkontext speichert, kann sie spätere Entscheidungen prägen. Wenn MCP- oder Plugin-Konfiguration externe Systeme verbindet, wird sie Teil der Trust Boundary.

Teams sollten diese Dateien ähnlich ernst nehmen wie CI-Konfiguration:

Wer darf sie ändern?
Werden Änderungen reviewed?
Enthalten sie Secrets?
Fördern sie unsichere Befehle?
Beschreiben sie vertrauenswürdige Systeme eindeutig?
Sind Prototyp-Anweisungen von Produktionsworkflows getrennt?

Für viele Teams ist das eine neue Gewohnheit. Sie wird schnell normal werden.

Pull Requests bleiben die Kontrollfläche

Die praktischste Grenze bleibt der Pull Request.

Ein Coding-Agent kann Arbeit vorbereiten. Er kann Tests schreiben. Er kann Migrationen vorschlagen. Er kann eine Änderung erklären. Er kann lokale Checks ausführen. Aber Produktänderungen sollten weiterhin über reviewbare, testbare und rücknehmbare Pull Requests ins System kommen.

Das bedeutet:

kleine Änderungen;
klare Akzeptanzkriterien;
Refactoring getrennt von Feature-Arbeit;
automatisierte Tests vor dem Review;
Dependency- und Secret-Scanning;
menschliche Freigabe für riskante Bereiche;
ein Rollback-Pfad für Produktionsänderungen.

Der Grund ist einfach: Menschen können nur Verantwortung für das übernehmen, was sie sehen.

Wenn ein Agent einen riesigen Diff über Anwendungscode, Konfiguration, Dependencies und Infrastruktur erzeugt, wird Review zur Theateraufführung. Wenn er einen fokussierten Pull Request mit Tests und klarer Erklärung erzeugt, kann das Team eine echte Entscheidung treffen.

Hier kann AI auch sicher helfen. Ein guter Agent kann den Pull Request verbessern: Scope reduzieren, Tests ergänzen, Annahmen erklären, riskante Dateien markieren, Migrationsnotizen vorbereiten und Bereiche hervorheben, die menschliche Aufmerksamkeit brauchen.

Das ist etwas anderes, als den Agenten seine eigene Arbeit mergen zu lassen.

Tool-Auswahl ist jetzt eine Sicherheitsentscheidung

Teams wählen Coding-Tools oft nach Entwicklerpräferenz, Modellqualität oder Preis.

Das bleibt relevant. Für produktive Software zählt aber auch die Sicherheitsposition des Anbieters.

Nützliche Fragen sind:

Wie isoliert das Tool Projekte?
Welche Daten werden an Remote-Services gesendet?
Was wird gespeichert?
Wie werden lokale Befehle freigegeben?
Wie werden Extensions und Plugins kontrolliert?
Wie schnell werden Schwachstellen gepatcht?
Gibt es Enterprise-Logging?
Kann das Tool je Repository unterschiedlich konfiguriert werden?
Unterstützt es Least-Privilege-Workflows?
Was passiert, wenn ein Mitarbeiter das Unternehmen verlässt?

Das heißt nicht, dass jedes Team vor einem Experiment einen Konzern-Einkaufsprozess braucht. Es heißt, dass sich die Entscheidung verändert, sobald das Tool vom persönlichen Experiment zum Teil des Delivery-Systems wird.

Für einen Gründer mit Prototyp kann Geschwindigkeit entscheidend sein. Für ein B2B-SaaS-Produkt mit Kunden, Verträgen und produktiven Daten liegt die Messlatte höher. Für regulierte oder sicherheitssensitive Arbeit steigt sie noch einmal.

Der Fehler ist, für alle drei Fälle dasselbe Setup zu verwenden.

Der deutsche Markt wird darauf achten

Deutsche Kunden sind bei Softwarerisiken oft pragmatisch. Sie brauchen nicht zwingend das neueste Tool als Erste. Sie brauchen Systeme, die zuverlässig funktionieren, Daten schützen und langfristig wartbar bleiben.

Das widerspricht AI-unterstützter Entwicklung nicht. Im Gegenteil: Es schafft eine Chance.

Wenn ein Unternehmen sagen kann: “Wir nutzen AI-Coding-Agenten, aber mit begrenztem Zugriff, reviewbaren Pull Requests, ohne produktive Secrets, mit kontrollierten Tool-Integrationen und nachvollziehbaren Logs”, ist das deutlich stärker, als so zu tun, als spiele AI keine Rolle.

Transparenz und Disziplin können Teil des Wertversprechens werden.

Das betrifft Gründer, die in den Mittelstand verkaufen, Produktverantwortliche, die interne Tools modernisieren, und CTOs, die Delivery beschleunigen wollen, ohne Vertrauen zu verlieren. AI-Adoption wird weniger an der Demo gemessen werden und mehr am Betriebsmodell darum herum.

Eine praktische Readiness-Checkliste

Bevor Coding-Agenten normaler Teil der Delivery werden, sollte ein Team konkrete Fragen beantworten können:

Welche Tools sind für welche Art von Arbeit freigegeben?
Auf welche Repositories und Datenquellen darf jedes Tool zugreifen?
Welche Befehle brauchen Freigabe?
Wo sind Secrets aus dem Agent-Kontext ausgeschlossen?
Wie werden Projektanweisungen, Memory und Tool-Definitionen reviewed?
Welche Änderungen müssen über Pull Requests laufen?
Welche Tests und Scans laufen vor dem menschlichen Review?
Wer besitzt eine agentenunterstützte Änderung nach dem Merge?
Wie würde das Team eine verdächtige Agent-Aktion untersuchen?
Wie werden Tools aktualisiert oder entfernt, wenn sich das Risiko ändert?

Wenn diese Antworten unklar sind, muss das Unternehmen nicht aufhören, AI zu nutzen. Es muss die ersten Use Cases enger schneiden und das Betriebsmodell verbessern.

Gute Startpunkte sind risikoarme, wertvolle Workflows:

Testgenerierung für bestehendes Verhalten;
Dokumentationspflege;
interne Skripte;
Refactoring in gut getesteten Modulen;
Unterstützung bei statischer Analyse;
Pull-Request-Zusammenfassungen;
Backlog-Analyse;
Migrationsplanung ohne automatische Ausführung.

Danach kann der Einsatz wachsen.

Die richtige Lektion aus Pwn2Own

Die falsche Lektion lautet: “AI-Coding-Agenten sind gefährlich, also vermeiden wir sie.”

Die bessere Lektion lautet: “AI-Coding-Agenten sind mächtig genug, um dieselbe Engineering-Disziplin zu verdienen wie der Rest der Delivery-Kette.”

Das ist ein gesundes Zeichen. Werkzeuge werden angegriffen, wenn sie wichtig genug werden, um relevant zu sein.

Für ernsthafte Produkte ist das Ziel nicht, weniger AI zu nutzen. Das Ziel ist, AI so einzusetzen, dass sie begrenzt, beobachtbar und passend zum Risikoprofil des Produkts ist.

Hier zählt Architektur. Nicht Architektur als abstraktes Diagramm, sondern Architektur als Summe der Entscheidungen, die Software verständlich und kontrollierbar machen: Grenzen, Berechtigungen, Tests, Deployment-Pfade, Ownership und Wiederherstellung.

AI kann Implementierung beschleunigen. Sie ersetzt diese Entscheidungen nicht.

Wie McDougall Digital helfen kann

McDougall Digital hilft Teams, AI-unterstützte Softwareentwicklung einzuführen, ohne Delivery in eine Vertrauensübung zu verwandeln.

Das kann mit einem Coding-Agent-Readiness-Review beginnen: Welche Tools sind im Einsatz, wo laufen sie, worauf dürfen sie zugreifen, welche Repositories und Credentials sind sichtbar, wie kommen Änderungen in Produktion, und wo verlässt sich der aktuelle Workflow zu stark auf informelle Urteile?

Danach wird es praktisch: begrenzte Agent-Workflows, sichereres Repository-Setup, CI- und Secret-Scanning, klarere Pull-Request-Regeln, bessere Tests, Grenzen für Tool-Integrationen, Dokumentation und Production-Readiness-Arbeit.

Das Ziel ist nicht, das Team auszubremsen. Das Ziel ist, die Geschwindigkeit für ernsthafte Produkte nutzbar zu machen.