Direkte Antwort: Wenn ein Coding-Assistent zu einem Agenten wird, der Repositories liest, Befehle ausführt und Werkzeuge aufruft, verschiebt sich sein größtes Risiko vom Erzeugen falschen Codes hin zum Ausführen unsicherer Aktionen. Die OWASP Top 10 for LLM Applications (2025) nennen Prompt Injection, die Offenlegung sensibler Informationen, Schwachstellen in der Lieferkette, unsachgemäße Ausgabeverarbeitung und übermäßige Handlungsvollmacht als führende Risiken. Diese Checkliste bildet diese Kategorien auf konkrete Kontrollen ab — besonders für Teams, die selbst gehostete Agenten betreiben.
Ein Code-Vervollständigungswerkzeug, das eine falsche Zeile vorschlägt, ist ein Produktivitätsproblem. Ein Coding-Agent, der ein von Angreifern beeinflusstes Issue liest und dann mit Ihren Anmeldedaten einen Shell-Befehl ausführt, ist ein Sicherheitsproblem. Der Unterschied ist Autonomie plus Werkzeuge, und er verändert das Bedrohungsmodell von Grund auf.
Die für 2025 aktualisierten OWASP Top 10 for LLM Applications sind der meistzitierte Ausgangspunkt für dieses Modell. Im Folgenden werden ihre Kategorien in die konkreten Formen übersetzt, in denen sie bei einem KI-Coding-Agenten auftreten, sowie in die Kontrollen, die ihnen begegnen.
Warum Coding-Agenten das Bedrohungsmodell verändern
Ein moderner Coding-Agent tut typischerweise Folgendes:
- Er nimmt nicht vertrauenswürdige Inhalte auf — Issue-Texte, Codekommentare, Webseiten, READMEs von Abhängigkeiten;
- er verfügt über Werkzeuge und Berechtigungen — eine Shell, Git-Zugriff, ausgehenden Netzwerkverkehr, Paketinstallation;
- er läuft mit einer gewissen Autonomie — er kann Aktionen verketten, ohne dass ein Mensch jeden Schritt freigibt.
Diese Kombination bedeutet, dass eine bösartige Anweisung, versteckt in Inhalten, die der Agent liest, zu einer bösartigen Aktion werden kann. Nur die Modellausgabe abzusichern reicht nicht; Sie müssen einschränken, was der Agent tun kann.
Die OWASP LLM Top 10 (2025), angewandt auf Coding-Agenten
| OWASP-Kategorie (2025) | Wie sie bei einem Coding-Agenten auftritt | Primäre Kontrolle |
|---|---|---|
| Prompt Injection (LLM01) | Versteckte Anweisungen in einem Issue, Kommentar oder einer Abhängigkeit lenken den Agenten um | Werkzeuge einschränken; für folgenreiche Aktionen menschliche Freigabe verlangen |
| Sensitive Information Disclosure (LLM02) | Quellcode, Secrets oder Prompts gelangen zu einem Modellanbieter oder in Logs | Egress-Kontrolle, Maskieren von Secrets, eng gefasste Anmeldedaten |
| Supply Chain (LLM03) | Vergiftete Modelle, Pakete oder Plugins gelangen in den Workflow | Quellen fixieren und verifizieren; interne Mirrors nutzen |
| Improper Output Handling (LLM05) | Generierter Code oder Befehle werden ohne Prüfung ausgeführt | Sandbox-Ausführung und verbindliche Review-Gates |
| Excessive Agency (LLM06) | Der Agent hat mehr Berechtigung oder Autonomie, als die Aufgabe braucht | Least Privilege und ausdrücklich begrenzter Aufgabenumfang |
| System Prompt Leakage (LLM07) | In Prompts eingebettete Konfiguration oder Secrets werden offengelegt | Secrets aus Prompts heraushalten; annehmen, dass Prompts leaken können |
OWASP überarbeitet die Liste und ihre Nummerierung regelmäßig. Überprüfen Sie die aktuellen Einträge und Definitionen beim OWASP Gen AI Security Project, bevor Sie darauf eine Kontrollmatrix aufbauen.
Eine Kontroll-Checkliste für Teams
Arbeiten Sie diese Punkte unabhängig vom Werkzeug ab, bevor Sie einem Agenten Zugriff auf echte Repositories gewähren:
- Vertrauensgrenze. Skizzieren Sie, wo nicht vertrauenswürdige Eingaben eintreten und wo der Agent handeln kann. Nehmen Sie an, dass jeder Inhalt, den der Agent liest, Anweisungen enthalten kann.
- Least Privilege. Geben Sie dem Agenten die minimal notwendigen Anmeldedaten, Repositories und den kleinstmöglichen Netzwerkumfang, die eine Aufgabe erfordert — nichts auf Dauer.
- Egress-Kontrolle. Kennen und beschränken Sie jeden ausgehenden Pfad: Modell-Endpunkte, Git-Hosts, Paketregister, Telemetrie, Logs.
- Secret-Hygiene. Halten Sie Anmeldedaten aus Prompts und generierten Artefakten heraus; rotieren Sie alles, was ein Agent beobachtet haben könnte.
- Sandbox und Isolation. Führen Sie Code in verwerfbaren, ressourcenbegrenzten Umgebungen aus, die die Produktion standardmäßig nicht erreichen können.
- Menschliche Review-Gates. Verlangen Sie eine Review vor folgenreichen Aktionen — Merges, Deployments, Infrastrukturänderungen, das Hinzufügen von Abhängigkeiten.
- Logging und Audit. Erfassen Sie Aufgaben, Werkzeugaufrufe und Ergebnisse, damit eine überraschende Aktion untersucht werden kann.
- Lieferketten-Verifizierung. Fixieren Sie Modell- und Paketquellen; validieren Sie die Integrität; bevorzugen Sie interne Mirrors für Air-Gapped- oder regulierte Arbeit.
- Modell- und Datenbedingungen. Überprüfen Sie, was ein Anbieter speichert, womit er trainiert und wo Daten verarbeitet werden.
- Incident-Übung. Testen Sie zuerst mit nicht sensiblem Code und üben Sie, Zugriffe zu entziehen und Agent-Aktionen rückgängig zu machen.
Wo Self-Hosting hilft — und wo nicht
Das Selbsthosten einer Agent-Plattform gibt einer Organisation echte Kontrolle über Egress, Isolation, Logging und Datenresidenz. Genau das sind die Hebel, von denen mehrere OWASP-Kategorien abhängen, weshalb eine selbst gehostete Bereitstellung für regulierte und proprietäre Arbeit attraktiv ist.
Aber Self-Hosting beseitigt für sich genommen nicht Prompt Injection oder übermäßige Handlungsvollmacht. Diese Risiken liegen darin, wie der Agent Inhalte verarbeitet und welche Werkzeuge er aufrufen kann, nicht darin, wo der Server läuft. Ein selbst gehosteter Agent mit weitreichenden Anmeldedaten und ohne Review-Gate ist weiterhin gefährlich.
Die öffentlichen Materialien von MonkeyCode beschreiben eine private und Offline-Bereitstellung sowie einen verwalteten Workflow rund um Aufgaben und Review. Behandeln Sie das als hilfreiche Infrastruktur für diese Kontrollen, nicht als deren Ersatz. Zwei verwandte direkte Antworten lohnen sich als Nächstes: ob Self-Hosting automatisch privat ist und ob MonkeyCode Code nach außen sendet, zusammen mit den Sicherheits- und Datenflussgrenzen der Website.
Fazit
Der Wechsel vom Assistenten zum Agenten ist ein Wechsel von „Ist der Code korrekt?“ zu „Was kann dieses System tun, und wer hat es freigegeben?“. Nutzen Sie die OWASP LLM Top 10 (2025), um die Risiken aufzuzählen, wenden Sie Least Privilege und Review-Gates an, um Aktionen einzuschränken, und verifizieren Sie jede Kontrolle mit nicht sensiblem Code, bevor Sie einer Grenze vertrauen. Self-Hosting kann mehrere dieser Kontrollen stärken, ersetzt sie aber nicht.
Quellengrenze: Die hier genannten Risikokategorien stammen aus den OWASP Top 10 for LLM Applications (Ausgabe 2025), geprüft am 20. Juli 2026. OWASP überarbeitet die Liste im Lauf der Zeit; bestätigen Sie die aktuellen Einträge und die Nummerierung direkt. Dieser Artikel ist eine allgemeine Sicherheitsanleitung, keine Zertifizierung eines bestimmten Produkts oder einer bestimmten Bereitstellung.