Ein Entwickler lässt einen Coding-Agenten Tests reparieren. Der Agent liest Dateien, startet Shell-Befehle, installiert Pakete und verbindet sich vielleicht mit MCP-Servern. Genau dort entsteht das praktische Sicherheitsproblem: Zwischen „der Agent schlägt etwas vor“ und „auf dem Rechner passiert et
Ein typischer Schutzreflex in JavaScript-Projekten lautet: Installationsskripte abschalten, Abhängigkeiten pinnen, Scanner laufen lassen. Der aktuelle RedC2-Fall zeigt, warum das allein nicht mehr reicht. TrendAI Research hat eine Gruppe trojanisierter npm-Pakete analysiert, die wie harmlose Kalende
Ein Entwickler aktualisiert Abhängigkeiten, ein CI-Runner baut die Anwendung, alle Tests bleiben grün – und trotzdem läuft anschließend fremder Code auf der Build-Maschine. Genau dieses Praxisproblem zeigt ein am 20. August 2026 entdeckter Angriff auf das Rust-Ökosystem. Über ein vermutlich kompromi
Viele Unternehmen haben im März gelernt, dass ein kompromittiertes Open-Source-Paket nicht nur eine Entwicklerstörung ist. Es kann CI/CD-Runner, Cloud-Accounts, Kubernetes-Cluster, Modellanbieter-Keys und interne Agentenplattformen gleichzeitig berühren. Die neue Relevanz des LiteLLM-Falls liegt des
Viele Unternehmen behandeln LLM-API-Logs wie technische Diagnosedaten: hilfreich für Debugging, nützlich für Agenten-Traces, gelegentlich geteilt in GitHub-Issues, internen Tickets oder öffentlichen Benchmark-Repositories. Sichtbare Prompts und Antworten werden vielleicht bereinigt, interne Felder d
Ein Entwickler verbindet seinen Coding-Agenten mit einem neuen MCP-Server, weil dieser angeblich das Projekt scannt, Integritätsprüfungen durchführt oder Codequalität bewertet. Der Agent hat Zugriff auf das Repository, lokale Konfigurationen und vielleicht auch auf `.env`-Dateien, SSH-Schlüssel oder
Viele Unternehmen testen KI inzwischen für Code-Reviews, Schwachstellen-Triage, Malware-Analyse oder Incident Response. Das Praxisproblem ist nicht mehr, ob Modelle in Security-Workflows nützlich sein können. Die schwierigere Frage lautet: Was passiert, wenn ein Modell nicht nur Befunde zusammenfass
Ein KI-Agent wirkt im Enterprise-Alltag oft wie eine kontrollierte Schnittstelle: Ein Nutzer stellt eine Aufgabe, das Modell entscheidet über den nächsten Schritt, und erst danach wird ein Tool ausgeführt. Genau auf diese Annahme bauen viele Sicherheitskonzepte auf. System-Prompts sollen Grenzen set
Viele Unternehmen testen gerade interne Agenten-Plattformen: ein Web-UI, ein paar spezialisierte KI-Agenten, Zugriff auf Repositories, Tickets, Shell-Kommandos oder interne APIs. Das Praxisproblem ist nicht mehr nur, ob das Modell eine falsche Antwort gibt. Entscheidend ist, wer Konfigurationen für
Ein JavaScript-Paket wird installiert, ein Build läuft im CI-Runner, ein Entwickler öffnet später das Repository in VS Code oder ein Coding-Agent lädt eine projektspezifische Konfiguration. In vielen Unternehmen sind das getrennte Sicherheitsdomänen: Dependency-Scanning hier, CI/CD-Härtung dort, End
Ein Sicherheitslabor soll ein kontrollierter Raum sein. Teams bauen Capture-the-Flag-Umgebungen, lassen Modelle nach Schwachstellen suchen und messen, welche Angriffswege ein KI-Agent findet. Für Unternehmen klingt das zunächst nach sinnvoller Vorsicht: Bevor ein leistungsfähiges Modell in Produkte
Automatisierungsplattformen wie n8n verbinden Ticketsysteme, Datenbanken, Cloud-Dienste, Code-Repositories und zunehmend auch KI-Modelle. Ein einzelner Workflow kann deshalb auf mehr sensible Systeme zugreifen als ein normaler Benutzer. Das Praxisproblem beginnt dort, wo Unternehmen den visuellen Wo
