Wenn uns technische Führungskräfte auf KI-Sicherheit ansprechen, steht meist ein dramatisches Szenario im Raum: ein Modell, das proprietären Code nach außen gibt, oder ein Agent, der außer Kontrolle gerät.
Über beides nachzudenken lohnt sich. Nur entsteht der eigentliche Schaden für die meisten Teams nicht dort.
Unserer Erfahrung nach ist das reale Risiko sehr viel leiser. KI erfindet keine neuen Arten von Fehlern. Sie sorgt nur dafür, dass Entwickler die altbekannten schneller erreichen und sie mit mehr Selbstvertrauen übernehmen. Ein Secret, das in ein Repository wandert. Ein unsicherer Vorschlag, der gemerged wird, weil er plausibel aussah. Ein Tool mit breitem Zugriff für eine eng umrissene Aufgabe.
GitHub schrieb am 1. April 2025, dass 2024 mehr als 39 Millionen Secrets über GitHub durchgesickert sind. Diese Zahl stammt noch aus der Zeit vor der großen Welle KI-gestützten Programmierens. Sie taugt gut als Ausgangspunkt: Entwicklerkomfort und Sicherheitsdisziplin liefen schon vorher auseinander. Schnellere Codegenerierung obendrauf heilt das nicht von selbst. Im Gegenteil, sie kann die Lücke unbemerkt weiter aufreißen.
Es geht in diesem Artikel also nicht um Angst. Es geht um ein praktisches Kontrollmodell, an dem Sie Entwicklungsteams tatsächlich messen können.
Die drei Sicherheitsfragen, auf die es ankommt
Bevor wir über Tools reden, wollen wir für jeden freigegebenen KI-Workflow drei Fragen beantwortet wissen.
- Welche Daten kann dieser Workflow preisgeben, und wohin?
- Welche unsichere Ausgabe könnte ein Reviewer durchwinken?
- Wie viel Zugriff hat das Tool oder der Agent wirklich, verglichen damit, wie viel die Aufgabe braucht?
Kann ein Team diese drei Fragen nicht beantworten, ist der Workflow nicht abgesichert. Er wird geduldet.
Risiko 1: Secrets und Datenabfluss
Das erste Risiko ist das langweiligste und zugleich das häufigste.
KI-Coding-Tools liefern mit mehr Kontext bessere Ergebnisse, also füttern Entwickler sie mit immer mehr davon: Dateien, Logs, Konfiguration, manchmal ganze Repositories. Jedes davon ist ein möglicher Weg, über den ein Secret oder ein sensibler Wert eine kontrollierte Grenze verlässt, sei es in ein Drittanbieter-Modell oder in ein generiertes Artefakt, das später committet wird.
Die Kontrollen dagegen sind nicht neu. Es ist die Disziplin, von der wir längst wussten, dass wir sie brauchen:
- Secret-Scanning beim Commit und in der CI, erzwungen statt nur empfohlen
- klare Regeln, welche Repositories und Datenklassen mit welchen Tools geteilt werden dürfen
- kurzlebige Zugangsdaten statt langlebiger statischer Secrets, wo immer es geht
- eine klar benannte Regel, was niemals in einen Prompt oder geteilten Kontext gehört
Der Punkt ist nicht, dass KI den Abfluss von Secrets erfunden hätte. Sie vervielfacht nur die Momente, in denen ein Secret abwandern kann, und genau deshalb müssen die bestehenden Kontrollen real sein und nicht bloß gut gemeint.
Risiko 2: unsichere Code-Vorschläge, die zu leicht übernommen werden
Das zweite Risiko ist die Übernahme.
Ein Modell kann Code erzeugen, der läuft, einen schnellen Test besteht und trotzdem ein unsicheres Muster mitschleppt: eine injection-anfällige Query, eine schwache Eingabeprüfung, ein veraltetes kryptografisches Verfahren oder eine Abhängigkeit, die dort nichts zu suchen hat.
Die Gefahr liegt nicht darin, dass der Vorschlag existiert. Sie liegt darin, dass KI-Ausgaben oft autoritativer wirken als ein halbfertiger menschlicher Entwurf, und genau das verleitet Reviewer dazu, sie ohne dieselbe Sorgfalt zu übernehmen.
Hier scheitert ein Mensch prüft das ganz unbemerkt. Wenn der Reviewer prüft, ob der Code funktioniert, und nicht, ob er sicher ist, dann hat das Sicherheits-Review nie stattgefunden.
Risiko 3: Prompt Injection und nicht vertrauenswürdiger Kontext
Das dritte Risiko ist das, was am meisten für KI-Systeme spezifisch ist, und das, was Teams am wenigsten durchdringen.
Die OWASP Top 10 für Large-Language-Model-Anwendungen führen Prompt Injection an erster Stelle. Im Entwicklungsalltag wird das in dem Moment relevant, in dem Ihr KI-Workflow nicht vertrauenswürdige Inhalte liest: eine Ticket-Beschreibung, eine Webseite, die Dokumentation einer Abhängigkeit, eine Datei aus externer Quelle oder die Ausgabe eines anderen Tools.
Lässt sich ein Modell durch Text steuern, den es eigentlich nur lesen sollte, dann lässt sich auch ein Agent, der tatsächlich handeln kann (einen Pull Request öffnen, einen Befehl ausführen, eine API aufrufen), dazu bringen, etwas zu tun, das der Entwickler nie wollte.
Dafür müssen Sie kein Frontier-Produkt bauen. Es genügt ein Agent, der nicht vertrauenswürdige Eingaben liest und zugleich Berechtigungen besitzt.
Risiko und Kontrolle gegenüberstellen
Wir finden es übersichtlicher, das Modell auf eine Seite zu bringen.
| Risiko | Was schiefgeht | Wichtigste Kontrolle |
|---|---|---|
| Secret- und Datenabfluss | Sensible Werte verlassen eine kontrollierte Grenze | Erzwungenes Secret-Scanning, Regeln zum Datenteilen, kurzlebige Zugangsdaten |
| Unsichere Vorschläge | Unsicherer Code wird übernommen, weil er autoritativ wirkt | Ein sicherheitsspezifischer Review-Standard, nicht nur funktioniert es |
| Prompt Injection | Nicht vertrauenswürdige Eingabe steuert ein Modell oder einen Agenten | Alle gelesenen Inhalte als nicht vertrauenswürdig behandeln; Agent-Rechte begrenzen |
| Zu breiter Zugriff | Ein Tool kann mehr, als die Aufgabe verlangt | Least Privilege für Tools, Agenten und Tokens |
Keine dieser Kontrollen ist exotisch. Die Arbeit besteht darin, sie explizit zu machen und durchzusetzen, statt sie einfach vorauszusetzen.
Warum ein Mensch prüft das für sich genommen keine Sicherheitskontrolle ist
Diesem Satz widersprechen wir entschieden, denn in den meisten Einführungen wird ihm viel zu viel aufgebürdet.
Menschliches Review ist nur dann eine Sicherheitskontrolle, wenn der Reviewer weiß, was er überhaupt absichert. Für Sicherheit heißt das: Der Review-Standard muss genau die Dinge benennen, die man mit KI leichter übersieht:
- Bringt diese Änderung ein Secret ein oder legt sie eines offen?
- Hält sich dieser Code an unsere Regeln zu Eingabebehandlung und Injection-Prävention?
- Hat ein Agent etwas außerhalb des vorgesehenen Rahmens angefasst?
- Durfte nicht vertrauenswürdiger Inhalt eine privilegierte Aktion beeinflussen?
Stehen diese Fragen nicht auf der Checkliste des Reviewers, hat das Team Tempo, aber keine Kontrolle. Genau diesen Zustand sollen technische Führungskräfte aus unserer Sicht am dringendsten vermeiden. Denn er fühlt sich sicher an und ist es nicht.
Das ist die Sicherheitsvariante eines Punktes, den wir zu freigegebenen Workflows ganz allgemein machen: Menschliche Aufsicht zählt erst, wenn der Reviewer benennen kann, was er prüft.
Least Privilege für KI-Tools und Agenten
Die wirksamste einzelne Gewohnheit, die wir empfehlen, ist Least Privilege, angewandt auf Tools und Agenten genauso, wie Sie es bei einem Dienstkonto tun würden.
Konkret:
- Geben Sie einem KI-Tool Zugriff nur auf die Repositories und Daten, die der Workflow braucht, nicht auf den gesamten Bestand.
- Fassen Sie Tokens eng und rotieren Sie sie.
- Trennen Sie
lesen und vorschlagen-Workflows vonhandeln und ausführen-Workflows und prüfen Sie die zweite Sorte deutlich strenger. - Verlangen Sie eine menschliche Bestätigung, bevor ein Agent eine unumkehrbare oder nach außen wirkende Aktion ausführt.
Ein Agent, der nur lesen und vorschlagen kann, ist ein beherrschbares Risiko. Ein Agent, der nicht vertrauenswürdige Eingaben liest und zugleich mit breiten Berechtigungen handelt, ist die Kombination, gegen die man gezielt entwerfen sollte.
Das deckt sich auch mit der Richtung, die die Regulierung einschlägt. Der EU AI Act, Verordnung (EU) 2024/1689, behandelt menschliche Aufsicht in Artikel 14 als echte Pflicht, und das AI Risk Management Framework von NIST versteht Sicherheit und Resilienz als Kerneigenschaften vertrauenswürdiger KI-Systeme, nicht als optionales Beiwerk.
Was wir messen würden
KI-Sicherheit lässt sich nicht über ein einziges Dashboard steuern. Aber ein kleiner Satz an Signalen zeigt Ihnen, ob die Kontrollen tatsächlich greifen.
| Signal | Was es Ihnen sagt |
|---|---|
| Abdeckung und Trefferquote des Secret-Scannings | Ob der häufigste Fehler wirklich eingedämmt ist |
| Sicherheitsfunde in KI-gestützten Änderungen | Ob Reviewer den Sicherheitsstandard anwenden |
| Berechtigungsumfang von Agenten je Workflow | Ob Least Privilege erzwungen oder nur angestrebt ist |
| Pfade nicht vertrauenswürdiger Eingaben in Agenten | Wo das Prompt-Injection-Risiko tatsächlich sitzt |
Stille ist hier kein Zeichen von Sicherheit. Wenn Sie nichts finden, ist die wahrscheinlichste Erklärung, dass niemand hinsieht, nicht, dass nichts passiert.
Unsere Sicht
Am gesündesten denkt man über KI-Sicherheit in der Entwicklung nicht als eigene neue Disziplin nach, sondern als Stresstest für Kontrollen, die Sie ohnehin haben sollten.
KI erhöht den Einsatz an drei ganz gewöhnlichen Stellen: Sie bewegt mehr Daten, sie macht es leichter, unsichere Vorschläge zu übernehmen, und sie bringt nicht vertrauenswürdige Eingaben als Steuerungsrisiko ins Spiel. Die Teams, die das gut hinbekommen, sind nicht die mit den ausgefeiltesten Tools. Es sind die, die ihre Kontrollen explizit gemacht, den Agent-Zugriff auf die jeweilige Aufgabe begrenzt und ihren Review-Standard so umgeschrieben haben, dass er benennt, was man mit KI leicht übersieht.
Das ist wenig glamouröse Arbeit. Aber genau sie erlaubt einer Führungskraft, ehrlich zu sagen, dass das gewonnene Tempo die Organisation nicht unbemerkt in einen schwächeren Sicherheitszustand verschoben hat.
Quellen
- GitHub,
GitHub found 39M secret leaks in 2024. Here's what we're doing to help, 1. April 2025 - OWASP,
OWASP Top 10 for Large Language Model Applications, abgerufen am 2026-06-10 - NIST,
Artificial Intelligence Risk Management Framework (AI RMF 1.0), abgerufen am 2026-06-10 - EUR-Lex, Verordnung (EU) 2024/1689, Artikel 14
Häufige Fragen
- Warum reicht es nicht, Secret-Scanning nur zu empfehlen, wenn Teams KI-gestützt entwickeln?
- KI-Tools liefern mit mehr Kontext bessere Ergebnisse, weshalb Entwickler ihnen immer mehr Daten geben — Dateien, Logs, Konfigurationen, manchmal ganze Repositories. Jede dieser Eingaben ist ein möglicher Weg, über den ein Secret eine kontrollierte Grenze verlässt, sei es in ein Drittanbieter-Modell oder in ein generiertes Artefakt. GitHub meldete für 2024 über 39 Millionen durchgesickerte Secrets, noch vor der eigentlichen KI-Welle. KI vervielfacht die Momente, in denen ein Secret abwandern kann — deshalb muss Secret-Scanning erzwungen sein, nicht bloß empfohlen.
- Warum ist menschliches Review allein keine ausreichende Sicherheitskontrolle für KI-generierten Code?
- Menschliches Review ist nur dann eine echte Kontrolle, wenn der Reviewer weiß, was er absichert. KI-Ausgaben wirken oft autoritativer als ein halbfertiger menschlicher Entwurf, was dazu verleitet, sie unkritischer zu übernehmen. Wer beim Review nur prüft, ob der Code funktioniert, lässt Injection-Risiken, schwache Kryptografie oder offen gelegte Secrets unbemerkt passieren. Der Review-Standard muss diese Punkte konkret benennen — sonst hat das Team Tempo, aber keine Kontrolle.
- Was ist Prompt Injection, und wann ist das für Engineering-Teams ein konkretes Risiko?
- Prompt Injection bezeichnet den Angriff, bei dem ein Modell durch Text gesteuert wird, den es eigentlich nur lesen sollte — OWASP führt es als erstes Risiko für LLM-Anwendungen. Im Entwicklungsalltag wird es relevant, sobald ein Workflow nicht vertrauenswürdige Inhalte liest: Ticket-Beschreibungen, Webseiten, Abhängigkeitsdokumentationen oder externe Dateiausgaben. Kann derselbe Agent auch handeln — Pull Requests öffnen, Befehle ausführen, APIs aufrufen — lässt er sich dazu bringen, Dinge zu tun, die der Entwickler nie beabsichtigt hat. Für dieses Risiko muss man kein Frontier-Produkt bauen; ein Agent mit Leserecht auf fremde Inhalte und echten Berechtigungen genügt.
- Wie sollte Least Privilege konkret auf KI-Agenten angewendet werden?
- Least Privilege für KI-Agenten bedeutet: Zugriff nur auf die Repositories und Daten, die der jeweilige Workflow tatsächlich braucht — nicht auf den gesamten Bestand. Tokens werden eng gefasst und rotiert. Entscheidend ist die Trennung von 'lesen und vorschlagen'-Workflows und 'handeln und ausführen'-Workflows; die zweite Kategorie wird deutlich strenger geprüft. Vor unumkehrbaren oder nach außen wirkenden Aktionen ist eine menschliche Bestätigung Pflicht. Ein Agent, der nur lesen und vorschlagen kann, ist ein beherrschbares Risiko; einer, der beides — nicht vertrauenswürdige Eingaben lesen und mit breiten Rechten handeln — kann, ist die Kombination, gegen die man bewusst entwerfen muss.
