Ich habe die Prompts von Cursors Security-Agenten gelesen, damit Sie es nicht müssen

Das ist der Prompt – der vollständige Text:

You are a security reviewer for pull requests.
Goal: Detect and clearly explain real vulnerabilities introduced or exposed by this PR. Review only added or modified code unless unchanged code is required to prove exploitability.
1. Inspect the PR diff and surrounding code paths.
2. For every candidate issue, trace attacker-controlled input to the real sink.
3. Verify whether existing controls already block exploitation: auth or permission checks, schema validation or type constraints, framework escaping, ORM parameterization, allowlists or bounded constants.
4. Report only medium, high, or critical findings with a plausible attack path and concrete code evidence.
Prioritize: injection risks, authn or authz bypasses, permission-boundary mistakes, secret leakage or insecure logging, SSRF, XSS, request forgery, path traversal, and unsafe deserialization, dependency or supply-chain risk introduced by the change.

Er ist das Herzstück der Automatisierung von Agentic Security Review. Damit werden jede Woche über 3.000 interne PRs geprüft und mehr als 200 echte Schwachstellen aufgedeckt. Eine Rollenzuweisung, ein Ziel, eine vierstufige Methodik und eine Prioritätenliste. Kein aufwendiges Chain-of-Thought-Gerüst. Seitenweise Few-Shot-Beispiele? Fehlanzeige. Komplexe JSON-Ausgabeschemata? Ebenfalls nicht.

Hätten Sie mir vor zwei Jahren gesagt, dass ein so knapper Prompt in diesem Umfang eingesetzt werden und Ergebnisse liefern kann, die eine CI-Sperre rechtfertigen, wäre ich skeptisch gewesen. Wir wurden alle darauf eingestellt zu glauben, dass KI-Prompting aufwendige Entwicklungsarbeit erfordert: seitenlange Anweisungen, sorgfältig ausgearbeitete Beispiele und detaillierte Ausgabevorgaben. Cursors Open-Source-Vorlagen legen nahe, dass für Security-Reviews eine klare Rollendefinition und eine strukturierte Methodik ausreichen könnten.

Das ist ein bemerkenswertes Signal dafür, wo die führenden Modelle heute stehen. Das Modell „weiß“ bereits, wie SQL-Injection aussieht, wie Authentifizierungsumgehungen funktionieren und was unsichere Deserialisierung bedeutet. Es braucht lediglich ein Rahmenwerk, um dieses Wissen systematisch anzuwenden. Wenn Modelle heute mit so wenigen Anweisungen schon so viel leisten können, ist die Entwicklung in den nächsten sechs bis zwölf Monaten wirklich spannend.

Natürlich ist der Prompt nur die Spitze des Eisbergs. Die eigentliche technische Leistung sind nicht die 15 Zeilen Anweisungen, sondern alles, was dahintersteckt: der eigens entwickelte MCP-Server für Persistenz und Deduplizierung, die mit Terraform verwaltete Deployment-Pipeline, die Webhook-Orchestrierung, die weiß, wann welcher Agent gestartet werden muss, und die Zustandsverwaltung, mit der Agenten Ergebnisse aus verschiedenen Durchläufen vergleichen können. Der Prompt ist einfach , weil die umgebende Infrastruktur es nicht ist. Das ist ein wichtiger Unterschied – und tatsächlich die interessantere Geschichte: Cursor hat nicht einfach clevere Prompts geschrieben, sondern eine produktionsreife Agenten-Orchestrierungsplattform entwickelt und darauf einfache Prompts aufgesetzt.

Doch bevor wir voreilige Schlüsse ziehen, sehen wir uns das Gesamtbild an: Was Cursor entwickelt hat, was an den einzelnen Komponenten beeindruckt und wo Lücken bestehen. Dafür ist ein Rahmen hilfreich, mit dem sich Security in agentischen Entwicklungsumgebungen betrachten lässt.

Die drei Dimensionen agentischer Security

Bei Snyk betrachten wir die Absicherung agentischer Entwicklung in drei Dimensionen: den von den Agenten generierten Code, die Supply Chain, von der die Agenten abhängen, und das Verhalten der Agenten selbst. Die Code-Dimension steht für die meisten im Vordergrund: Schreibt die KI sicheren Code, und erkennen wir Schwachstellen, bevor sie ausgeliefert werden? Die Supply-Chain-Dimension ist neuer und weniger offensichtlich: MCP-Server, Automatisierungsvorlagen, Agenten-Skills und Plugins sind allesamt Komponenten, von denen Ihre Agenten abhängen – und sie bergen dieselben Risiken wie jede Drittanbieter-Abhängigkeit. Die Verhaltensdimension ist am vielschichtigsten: Handeln die Agenten innerhalb ihres vorgesehenen Rahmens? Treffen sie Entscheidungen, die sie nicht treffen sollten? Und können Sie nachvollziehen, was sie in Ihrer gesamten Organisation tatsächlich tun?

Cursors Security-Agenten arbeiten hauptsächlich in der ersten Dimension und decken Schwachstellen im Code auf. Das ist wertvolle und notwendige Arbeit. Doch wie Sie im folgenden Überblick sehen werden, sind die beiden anderen Dimensionen ebenso wichtig – insbesondere im Enterprise-Maßstab. Und die Unternehmen, die die besten Ergebnisse erzielen, wie Labelbox, das durch den gemeinsamen Einsatz von Cursor und Snyk einen über Jahre aufgebauten Rückstand an Schwachstellen abgearbeitet hat, berücksichtigen alle drei.

Die vier Agenten: Was überzeugt und was fehlt

Heute hat Travis McPeak einen Blogbeitrag veröffentlicht, in dem er beschreibt, wie Cursors Security-Team auf Basis von Cursor Automations (ihrer Cloud-Agentenplattform) vier autonome Security-Agenten entwickelt und deren Vorlagen zur freien Nutzung als Open Source veröffentlicht hat. Die PR-Frequenz war innerhalb von neun Monaten auf das Fünffache gestiegen, und die traditionelle statische Analyse konnte nicht Schritt halten. Also entwickelten sie Agenten, die das konnten.

Das gesamte System baut auf einer bemerkenswerten Grundlage auf: einem eigens entwickelten MCP-Server (Model Context Protocol), der als serverlose Lambda-Funktion bereitgestellt wird. Er ermöglicht eine persistente Zustandsverfolgung, eine von Gemini Flash 2.5 unterstützte Deduplizierungsschicht (damit verschiedene Agenten denselben Fund nicht unterschiedlich formuliert melden) und eine einheitliche Slack-Ausgabeformatierung mit Aktionen zum Verwerfen oder Zurückstellen. Alles wird mit Terraform verwaltet. Solide Entwicklungsarbeit.

Hier sehen Sie die einzelnen Agenten und erfahren, was mich wirklich beeindruckt und worüber ein Enterprise-Security-Team nachdenken sollte.

Agentic Security Review: der PR-Wächter

Was er tut: Prüft jeden Pull Request anhand von Cursors spezifischem Bedrohungsmodell. Meldet Ergebnisse in einem privaten Slack-Kanal, kommentiert PRs direkt und kann die CI-Pipeline bei Security-Funden blockieren. Der entscheidende Unterschied zu einem universell einsetzbaren Review-Bot wie Cursor’s Bugbot: Die Prompts lassen sich gezielt auf Security abstimmen, ohne bei jedem kleinen Codequalitätsmangel zu blockieren.

Was beeindruckt: Die Ergebnisse sprechen für sich. In den vergangenen zwei Monaten wurde dieser Agent für Tausende PRs eingesetzt und hat Hunderte Probleme daran gehindert, in die Produktion zu gelangen. Und wie oben gezeigt, ist der Prompt, der all das steuert, bemerkenswert knapp. Das Signal-Rausch-Verhältnis ist für einen LLM-basierten Reviewer wirklich überraschend.

Worüber Sie nachdenken sollten: LLMs können selbstbewusst eine „kritische SQL-Injection“ in einer parametrisierten Abfrage melden, die vollkommen sicher ist – weil das Modell den Datenfluss falsch verstanden hat. Sie können auch eine echte Schwachstelle übersehen, weil ihre Aufmerksamkeit bei einer umfangreichen Codebasis nachlässt. Im Security-Kontext sind beide Fehlerarten kostspielig: Falschmeldungen untergraben das Vertrauen von Entwicklern, während übersehene Schwachstellen in der Produktion verbleiben. Wenn Ihre Erkennungsschicht vollständig probabilistisch arbeitet, gehen Sie beide Risiken ein. Das Prinzip ist einfach: Der Agent kann seine eigenen Hausaufgaben nicht bewerten. Sie brauchen eine unabhängige Validierungsschicht, die bestätigt, was das LLM gefunden hat. Deshalb ist es wichtig, die LLM-Prüfung durch deterministische SAST-Analyse wie Snyk Code zu ergänzen. Die deterministische Engine erkennt bekannte Muster mit mechanischer Präzision; das LLM findet neuartige, dateiübergreifende Logikfehler, die regelbasierte Tools übersehen. Sie brauchen beides.

Ebenfalls erwähnenswert: Sehen Sie sich das Ende der Prompt-Vorlage an.

Post a short Slack summary with the overall outcome and the top findings, if any.
Do not push changes or open fix PRs from this workflow.

Der Review-Agent führt ausdrücklich keine Fixes durch. Er findet, meldet und blockiert – aber ein Mensch entscheidet weiterhin, was zu tun ist. Selbst Cursors eigenes Security-Team lässt bei den eigenen Tools Menschen in den Entscheidungsprozess eingebunden. Das sagt einiges darüber aus, wo autonome KI-Security heute tatsächlich steht: Sie ist ein leistungsstarker Beschleuniger, kein Ersatz für menschliches Urteilsvermögen. Zumindest noch nicht.

Vuln Hunter: die bestehende Codebasis scannen

Was er tut: Statt neue Codeänderungen zu überwachen, scannt Vuln Hunter die bestehende Codebasis. Er unterteilt das Repository in logische Abschnitte, sucht in jedem nach Schwachstellen und überlässt dem Security-Team die Triage der Ergebnisse in Slack. Häufig nutzen sie @Cursor direkt in Slack, um Fix-PRs zu erstellen.

Was beeindruckt: LLM-gestütztes Schlussfolgern auf Legacy-Code anzuwenden, ist klug. Hier spielt KI ihre Stärken aus: Sie versteht komplexe, undokumentierte Codebasen und erkennt Schwachstellen, die statische Regeln übersehen würden. Dazu gehören dateiübergreifende Logikfehler, fehlerhafte Zugriffskontrollmuster und Authentifizierungsumgehungen, die in jahrealtem Code verborgen sind. Herkömmliche Scanner haben hier Schwierigkeiten, weil sie klar definierte Muster benötigen, nach denen sie suchen können.

Worüber Sie nachdenken sollten: Dieser Agent produziert im großen Maßstab am ehesten Falschmeldungen. Eine ganze Codebasis statt eines gezielten PR-Diffs zu scannen, bedeutet, dass das Modell mit einem viel größeren Kontext arbeitet. Genau hier wird das Nachlassen der LLM-Aufmerksamkeit zum ernsthaften Problem. BaxBench, ein Benchmark von ETH Zürich, UC Berkeley und INSAIT, ergab, dass 62 % der von selbst den besten Modellen generierten Lösungen entweder falsch sind oder Sicherheitslücken enthalten. Wenn das Modell umfangreiche, komplexe Codebasen analysiert, gilt der Grundsatz „Der Agent kann seine eigenen Hausaufgaben nicht bewerten“ umso mehr: Die Ergebnisse des LLM sollten deterministisch bestätigt oder widerlegt werden, bevor jemand Zeit in einen Fix investiert.

Anybump: automatisiertes Dependency-Patching

Was er tut: Er nimmt sich der mühsamsten Aufgabe in der Application Security an: dem Patchen von Abhängigkeiten. Eine Erreichbarkeitsanalyse filtert Schwachstellen heraus, die tatsächlich Auswirkungen haben können. Der Agent verfolgt Codepfade, führt Tests aus, prüft, ob etwas beschädigt wurde, und erstellt bei erfolgreichen Tests einen PR. Der gesamte Ablauf ist automatisiert; Cursors Canary-Deployment-Pipeline dient als letzte Sicherheitskontrolle.

Hier ist der Kern des Prompts:

You are a dependency-vulnerability remediation automation.
Goal: When a new Linear issue describes a vulnerable dependency, determine whether it can be upgraded safely and open a PR only when confidence is high.
Decision rule: Create PR only when upgrade is clearly safe; otherwise do not make changes.

Was beeindruckt: Dieser Ansatz löst ein Problem, das jedes Security-Team nur zu gut kennt. Dependency-Patching ist so zeitaufwendig, dass die meisten Teams irgendwann aufgeben und die Aufgabe an die Entwicklung weiterreichen, wo sie monatelang (oder jahrelang) im Backlog liegt. Die Automatisierung von Erreichbarkeitsanalyse, Tests und PR-Erstellung verbessert den Workflow spürbar.

Worüber Sie nachdenken sollten: Anybump löst den schwierigsten Teil des Dependency-Managements: den Patch tatsächlich anzuwenden, zu testen und in einen PR zu übernehmen. Doch alles rund um den Patch bleibt außen vor. Es gibt keine SBOM-Erstellung, keine Lizenz-Compliance-Prüfung und keinen Audit-Trail für Ihr Compliance-Team. Das sind weniger Schwächen des Agenten als vielmehr ganz andere Problemkategorien. Automatisiertes Patchen und Software Composition Analysis auf Enterprise-Niveau überschneiden sich, sind aber nicht dasselbe. Wenn Sie in einer regulierten Branche tätig sind oder Software im Rahmen von Kundenverträgen mit Compliance-Anforderungen bereitstellen, benötigen Sie neben der Automatisierung auch diese umfassendere Infrastruktur.

Wenn Sie ein Startup mit nur einem Repository sind, reicht Anybump möglicherweise aus. Wenn Sie im Enterprise-Maßstab arbeiten – mit Hunderten von Repositories, in regulierten Branchen und mit Kundenverträgen, die bestimmte Compliance-Zertifizierungen verlangen –, müssen Sie genau wissen, was in Ihrer Software steckt, welche Lizenzen Sie verwenden, und dies auch nachweisen können. Das ist der Unterschied zwischen automatisiertem Patchen und Software Composition Analysis auf Enterprise-Niveau: Die beiden überschneiden sich, lösen aber grundlegend unterschiedliche Probleme.

Invariant Sentinel: Compliance-Abweichungen erkennen

Was er tut: Prüft täglich anhand einer Reihe von Security- und Compliance-Eigenschaften auf Abweichungen. Für jeden logischen Abschnitt des Repositorys startet er Subagenten, vergleicht mithilfe des Automatisierungsgedächtnisses den aktuellen Zustand mit früheren Durchläufen und benachrichtigt das Security-Team, wenn sich etwas ändert.

Was beeindruckt: Die Zustandsverwaltung ist clever gelöst. Mithilfe der Gedächtnisfunktion der Automatisierung können Durchläufe miteinander verglichen werden. So erkennt der Agent Änderungen an der Sicherheitslage und nicht nur Momentaufnahmen. Die Möglichkeit, Validierungscode neben der Analyse zu schreiben und auszuführen, sorgt für eine Gründlichkeit, die reines LLM-Schlussfolgern allein nicht bieten würde.

Worüber Sie nachdenken sollten: Compliance-Abweichungen zu erkennen ist wertvoll, doch Compliance-Governance ist eine umfassendere Herausforderung. Invariant Sentinel meldet Ihnen, wenn sich etwas geändert hat. Er setzt jedoch keine Policy-as-Code-Vorgaben über Hunderte Repositories hinweg durch, erstellt keine Compliance-Berichte für Auditoren und stellt Ihrem CISO kein Dashboard mit Risikotrends im Zeitverlauf bereit. Das sind Plattformfunktionen, die über das hinausgehen, was ein einzelner Agent leisten kann.

Das ist immer noch CI – und Security sollte nicht erst dort beginnen

Bei Architekturdiagrammen und Agenten-Orchestrierung übersieht man leicht Folgendes: Im Kern hat Cursor eine hochentwickelte CI-Schicht entwickelt. Die Agenten werden durch GitHub-Webhooks gestartet, wenn PRs erstellt oder aktualisiert werden. Sie prüfen Diffs, veröffentlichen Kommentare, blockieren Pipelines und erstellen Fix-PRs. Im Grunde ist das derselbe Kontrollpunkt, an dem herkömmliche Security-Tools seit Jahren ansetzen – nur ist er jetzt intelligenter, weil ein LLM die Analyse übernimmt und keine regexbasierte Regel-Engine.

Und ja, das ist eine echte Verbesserung – daran besteht kein Zweifel. Aber CI ist nach wie vor der falsche Ort, um Sicherheit anzugehen.

Warum CI für Sicherheit zu spät kommt

Denken Sie einmal darüber nach: Wenn Sie Cursor verwenden, um Code in Ihrer IDE zu schreiben, und der anfällige Code es bis in einen PR schafft, bevor ihn jemand entdeckt, haben Sie bereits Zeit verloren. Entwickler wechseln von dem Code, den sie geschrieben haben, zu einem anderen Kontext. Der PR-Review-Zyklus kostet zusätzliche Zeit, und wenn der CI-Check blockiert, muss der Entwickler zurückgehen, den Fund verstehen, eine Korrektur vornehmen, sie pushen und auf einen weiteren Review-Zyklus warten. Das ist sicherlich besser, als die Sicherheitslücke erst in der Produktion zu entdecken. Aber es ist immer noch das „Scannen und Ticket“-Modell – nur komprimiert auf den Zeitrahmen eines PRs.

Wie Shift Left wirklich aussieht

Was Sie wirklich brauchen, sind Security-Tools, die direkt in Ihrer IDE laufen und Scans sowie Behebungen sofort auslösen, sobald neuer Code hinzukommt. So gelangt anfälliger Code gar nicht erst in einen Commit. Ihre Git-Historie bleibt sauber. Ihre PRs werden nicht blockiert, weil Sicherheitsprobleme im Arbeitsablauf erkannt und behoben werden, bevor der Entwickler die Änderung überhaupt für das Staging vormerkt. Und Sie reduzieren den Bedarf an kostspieligen Human-in-the-Loop-Reviews erheblich: Wenn eine Sicherheitslücke es nicht in einen PR schafft, muss niemand sie priorisieren, und keine Pipeline wird freitags um 16:30 Uhr blockiert.

IDE-first-Sicherheit vs. CI-first-Sicherheit

Mit Snyk Studio funktioniert es genau so. Sicherheitsleitplanken fangen unsicheren Code ab, bevor der Entwickler den KI-Vorschlag überhaupt annimmt. Der KI-Assistent führt snyk_code_scan bei neuem Code in Echtzeit aus und behebt gefundene Sicherheitsprobleme direkt im Arbeitsablauf. Das funktioniert direkt in Cursor und allen anderen großen KI-Coding-Assistenten. Keine blockierte CI-Pipeline, kein Kontextwechsel und keine unübersichtliche Git-Historie.

Warum mehrschichtige Sicherheit notwendig ist

Stellen Sie sich nun vor, Sie nutzen beides: Snyk Studio auf IDE-Ebene, um die große Mehrheit der Probleme direkt bei ihrer Entstehung abzufangen, und die Sicherheitsagenten von Cursor auf CI-Ebene als Sicherheitsnetz für alles, was dennoch durchrutscht. So erhalten Sie Defense in Depth: Der größte Teil der Arbeit wird unbemerkt in der IDE erledigt, während kostspielige menschliche Reviews komplexen Fällen vorbehalten bleiben. BaxBench zeigt, wie unsicher KI-generierter Code ist: 62 % der Lösungen führender Modelle enthalten Schwachstellen oder sind fehlerhaft. Ein solcher mehrschichtiger Schutz ist daher kein nettes Extra, sondern unerlässlich.

Und selbst abgesehen von der Frage rund um CI ist ein Sicherheitsprogramm weit mehr als eine Reihe von CI-Checks. Dazu gehören zentrale Dashboards, die Risiken aus Hunderten von Repositories zusammenführen. Dazu gehören SAST-Ergebnisse, die mit DAST-Ergebnissen abgeglichen werden und bestätigen, dass derselbe Endpunkt zur Laufzeit ausnutzbar ist. Dazu gehört Ihre SCA-Engine, die erkennt, dass die von Ihnen verwendete ORM-Bibliothek eine bekannte CVE aufweist, durch die sich die Parametrisierung in bestimmten Sonderfällen umgehen lässt, und diesen Befund mit dem SAST-Ergebnis in derselben Controller-Methode verknüpft. Für sich genommen ist jede dieser Informationen ein einzelner Datenpunkt. Zusammengeführt und auf derselben Plattform miteinander verknüpft, zeigen sie Ihnen genau, was passiert, warum es passiert und was zuerst behoben werden sollte. Ein Code-Scanner – selbst ein autonomer mit vier Agents und beeindruckendem PR-Durchsatz – beantwortet diese Fragen nicht. Das leistet eine Sicherheitsplattform.

Bestätigung, kein Wettbewerb (und wir sind bereits integriert)

Vor einigen Wochen habe ich über die Einführung von Claude Code Security durch Anthropic geschrieben und argumentiert, dass Investitionen von KI-Coding-Plattformen in Sicherheit eine Bestätigung und keine Disruption sind. Dasselbe gilt hier: Wenn die größten Namen im Bereich KI-Entwicklungstools Sicherheitsfunktionen entwickeln, zeigt das, dass die Branche erkannt hat: Sicherheit bei KI-gestützter Entwicklung ist Infrastruktur und kein optionales Extra.

Wie Cursor und Snyk zusammenarbeiten

Cursor und Snyk fahren nicht einfach aneinander vorbei: Snyk ist bereits im MCP Directory von Cursor vertreten. Wir bieten eine verifizierte Erweiterung an. Wir stellen Evo Agent Guard via Hooks bereit. Seit zwei Wochen ist Cursor unser AI Innovation Partner of the Year. Das ist keine konfrontative Beziehung, sondern eine Zweischichtenarchitektur in Aktion. Stellen Sie es sich so vor: KI-Agenten sind die Forscher. Sie entdecken Schwachstellen und schlagen schnell und kreativ Korrekturen vor. Die deterministische Validierung ist das Peer-Review, das unabhängig bestätigt, dass die Funde echt und die Korrekturen zuverlässig sind.

Die zweischichtige Sicherheitsarchitektur

Sie würden keine wissenschaftliche Arbeit ohne Peer-Review veröffentlichen – und sollten auch keinen Sicherheitsfix ohne deterministische Validierung ausliefern. Cursor stellt die Forschungsebene bereit (Agenten-Orchestrierung, Webhook-Auslöser, automatisierte PR-Erstellung). Snyk liefert das Peer-Review, die Governance und die umfassende Abdeckung der gesamten Software-Supply-Chain.

Und das funktioniert bereits in der Praxis: Labelbox setzt Cursor und Snyk gemeinsam in der Produktion ein und konnte einen über Jahre aufgebauten Rückstand an Schwachstellen beseitigen. Cursor automatisiert die Behebungsabläufe; Snyk stellt sicher, dass die Korrekturen wirksam sind und Enterprise-Ansprüchen genügen.

Die agentische Supply-Chain ist die neue Angriffsfläche

Treten Sie einen Schritt zurück und betrachten Sie nicht nur die konkrete Implementierung von Cursor, sondern auch die Entwicklungen in der gesamten Branche. Im vergangenen Jahr ist eine völlig neue Software-Supply-Chain entstanden, die rasant wächst: MCP-Server, Agent-Skills, Automatisierungsvorlagen, KI-Tool-Plugins und benutzerdefinierte Modellkonfigurationen. Nennen wir sie die agentische Supply-Chain. Sie umfasst die Komponenten, auf die KI-gestützte Entwicklungstools angewiesen sind, um zu funktionieren. Und derzeit sichert sie kaum jemand ab.

Das ist keine theoretische Gefahr. Im Januar 2026 entdeckte das Forschungsteam von Snyk Hunderte bösartige Skills auf ClawHub – den ersten großen Supply-Chain-Angriff auf KI-Agenten-Ökosysteme. Denken Sie dabei an die Open-Source-Automatisierungsvorlagen, die Cursor gerade veröffentlicht hat: Sie laufen mit Zugriff auf Ihre Codebasis, CI-Pipelines, Slack-Kanäle und GitHub-Repositories. Oder an einen MCP-Server, der als Lambda-Funktion bereitgestellt wird und jeden Sicherheitsfund in Ihrem Unternehmen verarbeitet. Das sind leistungsstarke Komponenten mit weitreichenden Berechtigungen. Und das Ökosystem für ihre Verteilung und Entdeckung – Marktplätze, Vorlagengalerien und Open-Source-Repositories – wächst deutlich schneller als die Sicherheitspraktiken, die es schützen sollen.

Die traditionelle Software-Supply-Chain hat Jahrzehnte gebraucht, um die Tools zu entwickeln, auf die wir uns heute verlassen: Paket-Registries mit Signaturprüfung, SBOMs, Lizenzscanner und Schwachstellendatenbanken. Der agentischen Supply-Chain fehlt diese Infrastruktur noch, und trotzdem wird sie bereits in großem Maßstab eingesetzt. Jedes Unternehmen, das MCP-Server installiert, Automatisierungsvorlagen importiert oder Agent-Skills mit seiner Entwicklungsumgebung verbindet, vergrößert seine Angriffsfläche auf eine Weise, die selbst ausgefeilte Scans auf Code-Ebene nicht abdecken.

Genau dieses Problem wurde mit Evo by Snyk angegangen. Evo ist unser agentisches Security-Orchestrierungssystem für die AI-native Entwicklungslandschaft: KI-Threat-Modeling, das anhand Ihres Codes dynamische Threat-Modelle erstellt; KI-Red-Teaming, das Ihre Modelle und Agenten kontinuierlich auf die Probe stellt; AI-SPM, damit Sie genau wissen, welche KI-Modelle und Frameworks in Ihrem Unternehmen laufen – einschließlich der „Shadow AI“, von der Ihre Sicherheitsteams nichts wissen; und Agent Scanning, das alle Toolchains sichtbar macht und mit Echtzeit-Leitplanken absichert.

Wenn autonome Sicherheitsagenten Ihre Codebasis bearbeiten, müssen Sie auch diese Agenten absichern. Die Tools in Ihrer agentischen Supply-Chain sind genauso wichtig wie die npm-Pakete in Ihrem node_modules und verdienen dieselbe Sorgfalt.

Wie es weitergeht: die Fragen, die sich daraus ergeben

Statt mit einer These zu schließen, über die ich bereits geschrieben habe, möchte ich mit den zukunftsgerichteten Fragen enden, die die Ankündigung von Cursor aufwirft. Denn ich finde, sie sind spannender als ein Blick zurück.

Probieren Sie es selbst aus

Snyk Studio ist kostenlos und in wenigen Minuten eingerichtet. Es funktioniert in Cursor und praktisch allen anderen KI-Coding-Assistenten. In etwa fünf Minuten stehen Ihnen deterministische Scans und der Behebungsbefehl /snyk-fix in Ihrer IDE zur Verfügung. Wenn Sie mehrschichtige Sicherheit in der Praxis erleben möchten, ist dies der schnellste Weg.

Evo by Snyk ist die richtige Lösung, wenn Sie den KI-Stack selbst absichern möchten: mit Threat-Modeling, Red-Teaming, AI-SPM, Agent Scanning und agentischer Security-Orchestrierung. Wenn Ihr Unternehmen KI-Coding-Tools in großem Maßstab einsetzt – und seien wir ehrlich: wahrscheinlich ist das bereits der Fall –, bietet Evo Ihnen die nötige Transparenz und die passenden Leitplanken für einen sicheren Einsatz.

Die Automatisierungsvorlagen von Cursor sind Open Source auf GitHub. Wenn Sie Cursor nutzen, lohnt es sich, sie auszuprobieren. Und wenn Sie sie zusammen mit Snyk einsetzen, erhalten Sie das Beste aus beiden Welten: agentengestützte Automatisierung mit Validierung auf Enterprise-Niveau.

Alles ist bereit. Bringen wir es zusammen.