Dein Agent läuft mit deinen Rechten
Coding-Agenten führen Code mit den Privilegien des Entwicklers aus. Kein separater Prozess, kein eingeschränkter Benutzer — was der Agent macht, macht er als du. Credentials, Source-Code, private Keys, SSH-Keys: alles erreichbar.
Das ist kein Bug. Das ist das Design.
"Look before you run" — die alte Regel trägt hier nicht mehr. Agenten führen Befehle automatisiert aus, und du kommst mit dem Prüfen nicht hinterher. Die TrustFall-Studie von Adversa AI (Mai 2026) hat genau das festgehalten.
Das Exploitation-Fenster für Schwachstellen hat sich laut dem Synack 2026 State of Vulnerabilities Report auf wenige Stunden verkürzt. Automatisierte Scanner erkennen bekannte Attack Patterns zuverlässig. Logic Flaws, Misconfigurations und unerwartetes Verhalten bleiben unsichtbar.
Du lässt einen Agenten auf fremden Code los. Was kann dir passieren? Mehr als du wahrscheinlich annimmst.
Agentjacking — der Angriff über den Issue-Tracker
Der Einstieg ist ein gefälschter Error-Report. Eingespielt über Sentry, eine der verbreitetsten Plattformen fürs Error-Tracking. Der Agent liest den Report, hält die Quelle für legitim und führt aus, was darin steht — Malware eingeschlossen. Tenet Security nennt das Agentjacking.
Entscheidend dabei: Der Angreifer braucht keine Administratorrechte. Zugang zum Issue-Tracker genügt.
Firewalls, Authentifizierung und Verschlüsselung schützen nicht — weil das Problem eine Ebene höher liegt. Der Agent vertraut Daten, die aus einem autorisierten System kommen. Ob der Report manipuliert ist, kann er nicht erkennen. Ein erfolgreicher Agentjacking-Angriff ermöglicht damit Zugriff auf Credentials, Source-Code, private Keys oder andere sensible Daten.
Das private Repository wird öffentlich sichtbar
Eine ganz normale Issue in einem öffentlichen Repository. Mehr braucht ein Angreifer nicht.
Der Agent hat Lesezugriff über mehrere Repositories, private eingeschlossen. Die richtige Formulierung in der öffentlichen Issue genügt, damit er Inhalte aus den privaten preisgibt. Noma Security hat das gegen GitHub Agentic Workflows durchgespielt.
Kein Credential-Diebstahl. Keine organisatorischen Zugangsrechte. Nur eine Issue.
Über diesen Weg könnten Angreifer laut SecurityWeek geheime Umgebungsvariablen und API-Keys auslesen, Inhalte aus privaten Repositories extrahieren und den Workflow dazu bringen, beliebige Befehle auszuführen. Jeder, der eine Issue erstellen kann, hat Zugang zu dieser Angriffsfläche — und der Agent hat privilegierte Ausführungsrechte auf der anderen Seite.
GitHub hat das Problem bestätigt und plant laut Golem keinen grundlegenden Fix. Die Schwachstelle liegt in der Architektur: KI-Systeme sind darauf ausgelegt, flexibel auf Anfragen zu reagieren — genau das macht sie angreifbar. Was die Community als Workarounds dokumentiert hat, diskutieren wir in der Hacking & Security Zone.
Agent Data Injection — der falsche Kommentar im Thread
Indirect Prompt Injection bei Coding-Agenten funktioniert über die Daten, auf denen der Agent arbeitet — nicht über die Aufgabe selbst.
Konkretes Szenario, dokumentiert von The Hacker News: Ein Entwickler nutzt einen Coding Assistant, um einen GitHub-Fix anzuwenden. Ein Angreifer hinterlässt einen gefälschten Kommentar im Thread — mit bösartigen Befehlen. Der Agent führt sie aus, weil sie aus der erwarteten Quelle kommen.
Das umgeht viele Sicherheitsmechanismen, die auf Task-Änderungen prüfen. Die Daten selbst sind das Trojanische Pferd. OWASP nennt Prompt Injection laut dem State of Agentic AI Security and Governance die dominante Bedrohung für Agentic-AI-Systeme in der Produktion.
Memory Poisoning — wenn der Agent sich selbst vergiftet
GhostWriter heißt der Angriff, und er zielt auf das Langzeitgedächtnis. Beschrieben von Forschern der UC San Diego.
Der Hebel ist simpel: Memory-Systeme unterscheiden nicht zwischen legitimen und bösartigen Einträgen. Beim Abruf prüft niemand, woher ein Eintrag stammt.
GhostWriter erreicht laut Paper etwa 98 Prozent Injection-Rate und durchschnittlich 60 Prozent Activation-Rate gegen aktuelle State-of-the-Art-Agenten.
Wenn dein Agent ein Memory-System nutzt, ist jede Quelle die er verarbeitet — Dokumente, Issues, API-Antworten — ein potenzieller Injection-Vektor. Der Angriff muss nicht live stattfinden. Einmal vergiftet, verhält sich der Agent bei jedem späteren Abruf falsch.
Supply Chain — was LiteLLM auf PyPI lehrte
Im März 2026 befand sich ein Backdoor auf PyPI für drei Stunden online. In diesem Fenster wurden fast 47.000 Downloads durchgeführt. Ziel war LiteLLM — ein Language-Model-Gateway, das laut OWASP GenAI Security Project als Backbone für CrewAI, DSPy, Microsoft GraphRAG und Dutzende weiterer AI-Agent-Frameworks dient. Wer in diesem Fenster ein Update durchführte, holte sich "hackerbot-claw" — einen autonomen Attack-Bot — ins System.
Drei Stunden. Das war das Fenster.
Ungepinnte Dependencies in einem produktiven Agent-Setup sind kein Komfort-Feature, sie sind ein offener Angriffsvektor.
Tool Poisoning im MCP-Setup
Invariant Labs hat das Konzept Tool Poisoning Attack (TPA) dokumentiert: Ein MCP-Server registriert Tools mit einer Beschreibung, die das Sprachmodell liest — die du in der UI aber oft nie vollständig siehst. Versteckt ein Angreifer Anweisungen in dieser Beschreibung, folgt ein hinreichend fähiges Modell ihnen, ohne dass du etwas Auffälliges siehst.
Dazu kommt der Rug Pull: MCP definiert keinen Mechanismus, der sicherstellt, dass Tool-Definitionen nach dem erstmaligen Verbinden identisch bleiben. Ein Server kann sie später serverseitig ändern und schädliche Anweisungen einschleusen — ohne dass dein Client das automatisch bemerkt.
Die MCP-Sicherheitscheckliste nach OWASP-Top-10 deckt beide Angriffsvektoren mit konkreten Pass-Kriterien ab.
Die Unix-Lücke die alle trifft
Eine jahrzehntealte Unix-Sicherheitslücke ermöglicht es, die Sicherheitsabfragen von KI-Coding-Tools wie Claude Code und Cursor zu umgehen. Das ist kein Problem eines einzelnen Anbieters — nahezu alle großen Coding-Assistenten auf Unix/Linux-Basis sind betroffen. Das Problem liegt auf System-Level und lässt sich nicht durch einzelne Code-Updates lösen.
Was genau auf Betriebssystem-Ebene dagegen hilft, hat das verfügbare Material nicht geliefert — das ist eine offene Frage, die Stand September 2026 keine klare Antwort hat.
Absicherung: was du heute ändern kannst
Kein Framework löst das grundsätzliche Problem — dass ein Coding-Agent mit deinen Rechten läuft und externen Daten vertraut. Aber du kannst die Angriffsfläche konkret verkleinern:
Sofortige Maßnahmen
└── Agenten nie mit Developer-Credentials laufen lassen
└── Dedizierte Service-Accounts mit Least Privilege
└── Alle Dependencies in Agent-Umgebungen exakt pinnen
└── MCP-Tool-Beschreibungen roh lesen, nicht nur UI-Ansicht
└── Tool-Definitionen hashen und bei Updates diffen
Strukturelle Maßnahmen
└── Destructive Actions hinter Human-in-the-Loop
└── Agent-Outputs nie als System-Instruktionen behandeln
└── Memory-Systeme als nicht-vertrauenswürdige Quelle behandeln
└── Agent-Actions vollständig loggen: was, wann, mit welchen Parametern
└── Agent Threat Rules (ATR) als Detection-Layer evaluieren
Agent Threat Rules sind ein offenes YAML-Format für AI-Agent-spezifische Bedrohungen — konzeptuell ähnlich wie YARA oder Sigma-Rules, aber speziell für Prompt Injection, Tool Poisoning und Credential Theft in Agent-Execution-Flows. Sicherheitsteams können damit schneller auf neue Bedrohungen reagieren, ohne auf Tool-Updates der Anbieter zu warten.
Eine wichtige Lücke bleibt: Was Sandboxing in einem Agenten-Kontext konkret kostet — an Aufwand und eingeschränkter Funktionalität — hat das verfügbare Material nicht geliefert. Das ist je nach Setup vermutlich sehr unterschiedlich.
Weitere Artikel zu Agenten-Patterns und deren Sicherheitsimplikationen findest du in der Coding-mit-KI-Rubrik.
Dieser Artikel wurde mit KI-Unterstützung und Quellenabgleich erstellt.
