Sie haben ein Budget für AI-Sicherheit. Und jetzt?

Die wichtigsten Erkenntnisse

• Budgets für AI-Sicherheit müssen sich von Ausgaben für isolierte Tools hin zu einer einheitlichen Investition in Transparenz, Governance und Kontrolle über den gesamten AI-Lebenszyklus entwickeln.

• Unternehmen sollten zwei miteinander verbundene Bereiche budgetieren: die Absicherung agentischer Entwicklung, bei der AI-Agenten Code generieren, Tools verwenden und Workflows ausführen, sowie die Absicherung agentischer Anwendungen, in denen Agenten mit Nutzern, Daten, APIs und Produktivsystemen interagieren.

• Ein solides Budget für AI-Sicherheit sollte gezielte Mittel für die Erkennung von AI, die Risikoanalyse von Agenten und Modellen, die Durchsetzung von Richtlinien, adversariale Tests, Laufzeitschutz und Governance-Nachweise vorsehen.

• Governance und Compliance sollten als eigener Budgetposten behandelt und nicht in Tooling-Ausgaben versteckt oder an GRC weitergereicht werden. Teams benötigen kontinuierliche Erkennung, durchsetzbare Richtlinien, Risikoberichte und Audit-Trails, um nachzuweisen, dass AI-Systeme verantwortungsvoll verwaltet werden.

• Der Kauf voneinander unabhängiger AI-Sicherheits-Tools kann Kosten und Komplexität erhöhen, ohne eine einheitliche Kontrolle zu ermöglichen. Ein Plattformansatz hilft Sicherheitsteams, Transparenz über AI, Risikoanalysen, Richtliniendurchsetzung und Nachweise in Entwicklung und Produktion miteinander zu verbinden.

Die meisten Unternehmen geben ihr Budget für AI-Sicherheit für die falsche Ebene aus. Der naheliegende Impuls: einfach Transparenz schaffen, um Modelle zu inventarisieren, APIs zu erfassen und ein Dashboard bereitzustellen.

Doch Transparenz allein hält weder den Coding-Agenten auf, der gerade einen kompromittierten MCP-Server eingebunden hat, noch den Produktiv-Agenten, der Kundendaten an einen unzulässigen Ort weiterleiten will. Sie verhindert auch nicht, dass ein autonomer Workflow fünf für sich genommen „zulässige“ Aktionen zu einem gefährlichen Ergebnis verknüpft.

Transparenz ohne Durchsetzung ist keine Governance. Unternehmen, die jetzt AI-Agenten einführen, müssen zwei unterschiedliche, aber miteinander verbundene Bereiche absichern:

1. Die Agenten, die Software entwickeln

2. Die Agenten, die in Produktivanwendungen arbeiten

Die zentrale Budgetfrage für Sicherheitsverantwortliche lautet nicht mehr, ob sie AI-Risiken im Nachhinein erkennen können. Entscheidend ist, ob sie Agenten über ihren gesamten Lebenszyklus hinweg steuern können – von ihrer Entwicklung bis zu ihrem Verhalten in der Produktion. Dafür müssen beide Bereiche abgesichert werden: mit Security-„Shift-left“-Maßnahmen für AI-generierten Code und die Agent-Supply-Chain während der Softwareentwicklung sowie mit Transparenz und Governance für Agenten und Anwendungen in der Produktion.

Bereich 1: Agenten absichern, die Software entwickeln

In der agentischen Entwicklung binden AI-Agenten inzwischen Abhängigkeiten ein, rufen MCP-Server auf, führen Skripte aus, verknüpfen Aktionen über Umgebungen hinweg und generieren mit minimaler menschlicher Prüfung produktionsreifen Code. Dadurch entstehen drei Angriffsflächen, die mit herkömmlicher AppSec nicht kontrolliert werden sollten: was Agenten verwenden, was sie tun und was sie generieren.

1. Was Agenten verwenden: MCP-Server, Skills und externe Tools

AI-Coding-Agenten arbeiten nicht im luftleeren Raum. Um Aufgaben zu erledigen, binden sie fortlaufend MCP-Server, externe APIs, wiederverwendbare Skills, Open-Source-Komponenten, Plug-ins und Tools von Drittanbietern ein – und all diese können anfällig, bösartig oder falsch konfiguriert sein.

Diese Komponenten werden zur Laufzeit ausgewählt und aufgerufen, nicht vorab genehmigt. Dadurch können nicht vertrauenswürdige externe Tools sofort in Ihren Workflow gelangen. Prüft ein Sicherheitstool nur das fertige Artefakt, entgeht ihm der Moment, in dem das Risiko in den Workflow gelangt ist: als der Agent eine nicht vertrauenswürdige Eingabe ausgewählt und verwendet hat.

Die Forschung von Snyk hat bereits bösartige Agentenfunktionen in gemeinsam genutzten Ökosystemen, anfällige MCP-Server und kritische Schwachstellen in weitverbreiteter Agenten-Infrastruktur aufgedeckt. CVE-2025-6514 ermöglichte beispielsweise die vollständige Remote-Code-Ausführung über mcp-remote.

2. Was Agenten tun: Tool-Ausführung, Skripte und Systemzugriff

Agenten machen nicht nur Vorschläge, sondern führen Aktionen autonom und mit Maschinengeschwindigkeit aus. Sobald sie ein Ziel erhalten, können sie Befehle ausführen, Dateien ändern, mit Infrastruktur interagieren, Systeme abfragen, APIs aufrufen und Workflows über Umgebungen hinweg verknüpfen – häufig mit weitreichenden Berechtigungen, begrenzter Überwachung und ohne Freigabe durch Menschen.

Der Vorfall bei Replit machte dieses Fehlerszenario konkret: Ein AI-Agent ignorierte ausdrückliche „Einfrieren“-Anweisungen, löschte eine Produktivdatenbank und erfand Tausende gefälschte Datensätze, um seine Tat zu vertuschen.

Ein solcher Vorfall entsteht nicht, weil ein Scanner eine anfällige Funktion übersehen hat. Er entsteht, weil das dynamische, mehrstufige Verhalten des Agenten im Moment der Aktion nicht gesteuert wurde. Agentische Entwicklung erfordert Kontrollen innerhalb des Ausführungsprozesses – nah genug, um Kontext, Berechtigungen und Risiken zu bewerten, bevor eine unsichere Aktion abgeschlossen wird.

3. Was Agenten generieren: Code und Abhängigkeiten

Agenten generieren Code und Abhängigkeiten zudem schneller, als Menschen sie prüfen können. Dabei können Schwachstellen, unsichere Abhängigkeiten, fest codierte Geheimnisse oder Fehlkonfigurationen entstehen.

Bei agentischer Entwicklung besteht das Problem darin, dass AI kontinuierlich mit Maschinengeschwindigkeit Code generiert – oft außerhalb der Prüfprozesse, auf die Unternehmen angewiesen sind. Wenn die Prüfung nach dem Commit läuft, kann der anfällige Code bereits im Repository liegen. In manchen Workflows wurde er möglicherweise schon paketiert, bereitgestellt oder von einem anderen Agenten wiederverwendet.

Generierte Ausgaben abzusichern bedeutet, den Code direkt bei seiner Erstellung zu prüfen, bevor er ins Repository gelangt oder Teil eines größeren agentengesteuerten Workflows wird. Wenn Sie in der agentischen Entwicklung das prüfen, was Agenten generieren, nicht bereits bei der Erstellung absichern, verfolgen Sie Risiken erst, nachdem sie schon eingeführt wurden.

Bereich 2: Agenten absichern, die in Produktivanwendungen arbeiten

Der zweite Bereich ist die Produktion. In den meisten Unternehmen laufen bereits Agenten in Anwendungen – etwa Support-Agenten, die Kundenanfragen bearbeiten, Workflow-Agenten mit Zugriff auf interne Systeme, autonome Pipelines, die APIs aufrufen, und AI-native Apps, die Daten abrufen, Entscheidungen treffen und ohne menschliches Eingreifen handeln.

Die Frage ist, ob Sie wissen, was Ihre Agenten tun, und ob Sie sie stoppen können, wenn sie falsch handeln. Sobald Agenten live sind, gerät die Governance in drei Bereichen ins Wanken: Erkennung, Risikobewertung und Compliance.

1. Erkennung: Was Sie nicht sehen, können Sie nicht steuern

Sicherheitsteams benötigen einen aktuellen Überblick darüber, wo AI-Agenten laufen, welche Modelle sie verwenden, welche Tools sie aufrufen, auf welche Daten sie zugreifen und welche Workflows sie ausführen.

Die meisten Unternehmen haben keinen vollständigen Überblick. Shadow AI verschärft das Problem, wenn Beschäftigte und Teams eigene GenAI-Tools entwickeln, Agenten in Workflows integrieren und AI-Systeme ohne formelle Sicherheitsprüfung mit internen Daten verbinden. Eine Lücke im Inventar bedeutet also mehr als eine unvollständige Dokumentation bekannter Systeme: Sie umfasst auch unbekannte Agenten, die außerhalb etablierter Kanäle arbeiten.

Wenn Sie nicht wissen, welche Agenten existieren, können Sie keine Richtlinien für sie durchsetzen, ihre Risiken bewerten, Compliance nachweisen oder im Problemfall Verantwortliche benennen. Das Inventar ist die Grundlage der Governance, aber nicht ihr Ziel.

2. Risikobewertung: Regeln müssen dort greifen, wo Agenten handeln

Viele Unternehmen verfügen bereits über Richtlinien zur AI-Governance. Das Problem: Die meisten stehen in Dokumenten oder Tabellen oder sind Teil von Prüfabläufen, mit denen Agenten nie in Berührung kommen. Diese „Papier-Governance“ vermittelt ein gefährliches falsches Sicherheitsgefühl.

Eine Richtlinie wie „Agenten dürfen Kundendaten nicht an externe Dienste weitergeben“ ist beispielsweise nur dann relevant, wenn sie durchgesetzt wird, sobald der Agent handeln will. Andernfalls gibt es Governance auf dem Papier und unkontrolliertes Verhalten in der Produktion.

Agentische Anwendungen benötigen die Durchsetzung von Richtlinien auf der Ausführungsebene. Dort wird geprüft, was der Agent tun will, welche Daten er verwendet, welche Tools er aufruft und ob die Aktion eine definierte Grenze überschreitet. Versucht ein manipulierter Agent beispielsweise, Kundendaten an einen externen Endpunkt zu senden, kann die Aktion blockiert oder geändert werden, bevor sie abgeschlossen ist.

3. Compliance: Sie müssen belegen, was geschehen ist, warum und mit welcher Berechtigung

Wenn ein Agent ein Geschäftsproblem verursacht, benötigen Sicherheitsteams mehr als nur Logs. Sie brauchen einen belastbaren Nachweis darüber, was geschehen ist: was der Agent getan hat, auf welche Daten er zugegriffen hat, welches Tool er aufgerufen hat, welche Richtlinie galt, ob die Aktion erlaubt oder blockiert wurde und wer für den Workflow verantwortlich war.

Der Fall Air Canada zeigte, dass Unternehmen für die Aussagen eines AI-Chatbots gegenüber Kunden haftbar gemacht werden können. Der Prompt-Injection-Vorfall bei Chevrolet zeigte, wie leicht öffentlich zugängliche AI zu geschäftsschädigenden Ergebnissen manipuliert werden kann. Toxic Flows zeigen, wie Agenten Tools, Daten und APIs so verknüpfen können, dass eine einzelne Aktion dies nicht erkennen ließe.

Governance und Compliance sollten einen eigenen Posten im Budget für AI-Sicherheit bilden, nicht in Tooling-Ausgaben versteckt oder als nachgelagerte GRC-Aufgabe behandelt werden. Da sich AI-Agenten in Entwicklungs-Workflows und Produktivanwendungen verbreiten, benötigen Unternehmen eine Möglichkeit nachzuweisen, welche AI-Systeme vorhanden sind, welche Richtlinien für sie gelten und ob diese durchgesetzt werden. Ohne diese Grundlage machen sich die Governance-Kosten später durch gescheiterte Audits, ins Stocken geratene Enterprise-Deals, Untersuchungen nach Vorfällen oder kurzfristig beauftragte Beratung bemerkbar, um einen Audit-Trail nachträglich zu rekonstruieren, der von Anfang an hätte vorhanden sein sollen.

Warum zwei voneinander unabhängige Tools keine Lösung sind

AI-Risiken bleiben nicht sauber auf eine Ebene begrenzt. Ein Modell, Agenten-Framework oder MCP-Server kann in Code eingeführt, über eine Pipeline bereitgestellt, von einer Anwendung aufgerufen und anschließend von einem Agenten für Aktionen in der Produktion genutzt werden. Wird jede Phase mit einem anderen Tool gesteuert, müssen Sicherheitsteams Teilansichten desselben Systems mühsam zusammenführen.

AI-Risiken bleiben nicht sauber auf eine Ebene begrenzt. Ein Modell, Agenten-Framework oder MCP-Server kann in Code eingeführt, über eine Pipeline bereitgestellt, von einer Anwendung aufgerufen und anschließend von einem Agenten für Aktionen in der Produktion genutzt werden. Wird jede Phase mit einem anderen Tool gesteuert, müssen Sicherheitsteams Teilansichten desselben Systems mühsam zusammenführen.

Fragmentiertes Tooling führt zu fragmentierter Kontrolle. Das hat folgende Folgen:

• Uneinheitliche Richtlinien zwischen Entwicklung und Laufzeit

• Doppelte, voneinander abweichende Inventare

• Blinde Flecken zwischen Build und Deployment

• Getrennte Audit-Trails, die nur einen Teil der Vorgänge abbilden

• Unklare Zuständigkeiten bei einem agentengesteuerten Vorfall

Hinzu kommen fragmentierte Kosten: Jedes einzelne Tool bringt eigene Lizenzgebühren, Integrationsaufwand, Daten-Pipelines, Dashboards und Anbieterbeziehungen mit sich, die verwaltet werden müssen. Teams investieren oft doppelt in sich überschneidende Funktionen für Erkennung, Risikoanalyse und Richtliniendurchsetzung, während dazwischen weiterhin Lücken bleiben. Wenn mehrere Tools schließlich miteinander verbunden sind, können Gesamtkosten und Komplexität den Nutzen einer einheitlichen Plattform übersteigen – ohne eine einheitliche Kontrolle zu ermöglichen.

Bei AI-Sicherheit ist Konsolidierung mehr als eine Budgetentscheidung. Sie ist eine Governance-Anforderung. Sicherheitsteams benötigen einen zusammenhängenden Überblick darüber, wo AI eingesetzt wird, welche Risiken dadurch entstehen, wie sie sich verhält und welche Richtlinien während ihres gesamten Lebenszyklus durchgesetzt werden. Ohne diese Verbindung geben Unternehmen möglicherweise mehr aus und verfügen dennoch nicht über die Transparenz, Rechenschaftspflicht und Kontrolle, die für eine sichere Ausweitung des AI-Einsatzes erforderlich sind.

Snyk sichert beide Seiten agentischer Sicherheit auf einer Plattform ab

Die AI-Security-Plattform von Snyk sichert beide Seiten des Agenten-Lebenszyklus auf einer Plattform ab. Für die agentische Entwicklung unterstützt Snyk Sie dabei, zu steuern, was Agenten verwenden, tun und generieren – von MCP-Servern und Skills über die Ausführung bis hin zu AI-generiertem Code. Für agentische Anwendungen in der Produktion bietet Snyk mit Evo AI-SPM ein System of Record für AI-Risiken in Bezug auf Agenten, Modelle, Tools, Daten und Workflows. So wird aus Governance-Absichten durchsetzbare Richtlinien.

Das Ergebnis ist eine gemeinsame Kontrollebene für Agenten-Sicherheit: mit zentraler Erkennung und Richtlinien, Echtzeit-Durchsetzung und Auditierbarkeit in Entwicklung und Produktion.

Zusammen ergibt das ein einheitliches Modell für Agenten-Sicherheit:

• Ein zentrales System zur Erfassung von KI- und Agentenrisiken

• Ein Richtlinienmodell für Entwicklung und Produktion

• Eine Durchsetzungsebene für unsicheres Verhalten von Agenten

• Ein Audit-Trail für Governance und Verantwortlichkeit

Die Frage, die Sie vor der Budgetfreigabe beantworten sollten

Wenn Sie über ein Budget für KI-Sicherheit verfügen und Ihre Führungsebene Ergebnisse erwartet, ist die entscheidende Frage ganz einfach: Können Sie eine Sicherheitsrichtlinie für einen Agenten durchsetzen – in der Entwicklung und in der Produktion –, bevor eine unsichere Aktion ausgeführt wird?

Lautet die Antwort Nein, sind Ihre Agenten nicht abgesichert, und Sie sind nicht ausreichend auf den nächsten Agenten vorbereitet, der eine Produktionsdatenbank löscht, eine Richtlinie halluziniert, die Ihr Unternehmen haftbar macht, sensible Daten preisgibt oder zugelassene Tools zu einem unsicheren Workflow verkettet. Erfolgreich mit KI werden nicht die Unternehmen sein, die ihre Einführung verlangsamen. Es werden diejenigen sein, die kontinuierliche Kontrolle in die Softwareentwicklung mit Agenten und den Betrieb von Agenten in der Produktion integrieren.

Das Budget ist genehmigt, und die Bedrohung ist real. Der nächste Schritt: Stellen Sie sicher, dass Ihr KI-Sicherheitsprogramm handeln kann, bevor eine unsichere Aktion zu einem geschäftlichen Vorfall wird. Sie möchten einen praxisorientierten Leitfaden zu kontinuierlicher, durchsetzbarer Governance? Laden Sie noch heute den Executive Guide to Operationalizing & Enforcing AI Governance herunter.