Sicherheitslösungen für Enterprise-KI-Agenten: Der vollständige Einkaufsführer (2026)

Einleitung

Im Juli 2025 löschte der KI-Coding-Agent von Replit während einer Live-Programmiersitzung eine komplette Produktionsdatenbank. Im Januar 2026 demonstrierte CVE-2026-25253 – die erste CVE, die jemals einem agentenbasierten KI-System zugewiesen wurde – die Möglichkeit zur Remote-Code-Ausführung durch ein manipuliertes Skill-Paket in der OpenClaw-Laufzeitumgebung. Nur Wochen später wurden bei der ClawHavoc-Kampagne über 1.200 bösartige Skills im OpenClaw-Marktplatz veröffentlicht, wodurch der AMOS-Credential-Stealer auf den Entwicklerrechnern von Unternehmen verbreitet wurde.

Dies sind keine theoretischen Angriffsszenarien aus einem Sicherheitsbericht. Es handelt sich um reale Vorfälle aus den ersten zwölf Monaten des großflächigen Einsatzes von agentenbasierter KI in Unternehmen. Und sie repräsentieren nur die dokumentierten Ausfälle – also jene, die öffentlich bekannt wurden. Die Lücke zwischen gemeldeten und tatsächlichen Vorfällen ist wahrscheinlich weitaus größer.

Der Markt für die Sicherheit von Enterprise-KI-Agenten entsteht als Reaktion auf eine Implementierungswelle, die bereits in vollem Gange ist. Unternehmen warten nicht auf ausgereifte Sicherheitstools, bevor sie Agenten einsetzen; sie implementieren die Agenten und entdecken die Sicherheitslücken erst unter Live-Bedingungen.

Dieser Leitfaden bildet die gesamte Landschaft der Sicherheitslösungen für Enterprise-KI-Agenten ab: Wie die Angriffsfläche aussieht, wie der Anbietermarkt strukturiert ist, wo die Lücken klaffen und wie eine vollständige Sicherheitsarchitektur für agentenbasierte KI im Jahr 2026 aussehen muss. Er behandelt, wie TrueFoundry's AI Gateway und MCP Gateway als Infrastruktur-Kontrollebene innerhalb dieses umfassenderen Ökosystems fungieren.

Warum KI-Agenten herkömmliche Sicherheitstools aushebeln

Die meisten Sicherheitsteams, die agentenbasierte KI bewerten, neigen dazu, dieselben Tools anzuwenden, die sie für ihre SaaS-Anwendungen nutzen: WAF für die API-Oberfläche, CASB für die Datengovernance, DLP für sensible Daten und SIEM für die Ereigniskorrelation. All diese Tools sind notwendig. Aber keines davon ist ausreichend.

Herkömmliche Sicherheitstools basieren auf einer spezifischen Annahme: ein Mensch initiiert eine Aktion, und diese Aktion ist in sich abgeschlossen. Ein Benutzer klickt in einer E-Mail auf Senden. Ein Entwickler führt einen Git-Push aus. Eine Abfrage wird gegen eine Datenbank ausgeführt. Jede dieser Aktionen hat einen klaren Initiator, einen definierten Umfang und einen eindeutigen Abschluss.

KI-Agenten verletzen jeden Teil dieser Annahme. Ein Agent:

• Initiiert autonom mehrstufige Aktionsketten, bei denen einzelne Schritte isoliert betrachtet legitim wären, die Kette als Ganzes jedoch eine Bedrohung darstellt (Massenauslesen von Dateien → API-Schreibzugriff → externer Upload)
• Verarbeitet nicht vertrauenswürdige Inhalte als Teil seiner Reasoning-Pipeline – Dokumente, Webseiten, API-Antworten und Datenbankeinträge können injizierte Anweisungen enthalten
• Hält den Status über Tool-Aufrufe hinweg aufrecht – das Kontextfenster überträgt Informationen von einem Tool-Aufruf zum nächsten, was bedeutet, dass eine einzige Injektion die gesamte Sitzung kontaminieren kann
• Operiert mit Maschinengeschwindigkeit – eine vollständige Datenexfiltrationskette kann in Sekunden ablaufen, noch bevor ein menschlicher Prüfer die Aktivität bemerkt
• Besitzt nicht-menschliche Identitäten mit privilegierten Zugriffsrechten – Datenbankanmeldedaten, OAuth-Token, API-Schlüssel –, die keinem einzelnen Mitarbeiter in Ihrem IAM-System zugeordnet sind

Die OWASP Agentic AI Top 10 (2025) formalisieren diese Bedrohungslandschaft. Die drei größten Risiken sind Prompt-Injection und Jailbreaks, Memory Poisoning (die Korruption des Langzeitgedächtnisspeichers des Agenten) sowie der Missbrauch von Tools/Plugins – für keines dieser Risiken bieten herkömmliche Sicherheitstools ausreichenden Schutz. WAFs verstehen keine Reasoning-Ketten von Agenten. DLP-Systeme untersuchen nicht den Inhalt des Kontextfensters eines LLMs. CASB-Lösungen können Tool-Aufrufe nicht der Benutzeridentität zuordnen, wenn der Aufruf von einem Agentenprozess ausgeht.

Die Sicherheitslücke ist kein Konfigurationsproblem. Es ist ein Kategorienfehler. Unternehmen benötigen speziell entwickelte Tools für die Agenten-Ebene, und im Jahr 2026 hat sich dieser Markt in fünf verschiedene Anbieterkategorien unterteilt.

Die Angriffsfläche der fünf Ebenen

Um die Anbieterlandschaft zu verstehen, muss man die Angriffsfläche kennen, die sie schützen soll. Enterprise-KI-Agenten haben fünf verschiedene Ebenen, auf denen Bedrohungen entstehen:

Der Anbietermarkt ist in diese fünf Ebenen unterteilt. Kein einzelner Anbieter deckt alle fünf Bereiche umfassend ab. Das Verständnis dafür, was die jeweilige Kategorie abdeckt und wo Lücken bestehen, bildet die Grundlage für eine unternehmensweite Evaluierung.

Die Anbieterlandschaft für Enterprise-KI-Agenten-Sicherheit

1. Identitätssicherheit für KI-Agenten

Das Problem, das hier gelöst wird: KI-Agenten sind nicht-menschliche Identitäten mit privilegierten Zugriffsrechten. Herkömmliche PAM-Tools wurden für menschliche Benutzer entwickelt. Agenten werden dynamisch erstellt und wieder gelöscht, verfügen oft über zu weitreichende Berechtigungen und sind nicht in die Offboarding-Prozesse eingebunden, die den Zugriff bei Mitarbeiteraustritten entziehen.

CyberArk ist der führende Anbieter in dieser Kategorie und hat seine Identity Security Platform speziell für KI-Agenten-Identitäten erweitert. Zu den wichtigsten Funktionen gehören die automatisierte Erkennung von Agenten in SaaS-, Cloud- und Entwicklerumgebungen, die Durchsetzung von Zero Standing Privileges sowie die Just-in-Time-Vergabe von Anmeldedaten. Untersuchungen von CyberArk haben ergeben, dass weniger als 10 % der Unternehmen über angemessene Berechtigungskontrollen für ihre KI-Agenten-Identitäten verfügen – ein Markt, den CyberArk gezielt adressiert.

Was fehlt: CyberArk steuert die Vergabe von Anmeldedaten und den Identitätslebenszyklus. Es findet jedoch keine inhaltliche Prüfung der Aktionen statt, für die diese Anmeldedaten verwendet werden – also weder des Prompts, des Tool-Aufrufs noch der Antwort. Dafür sind weitere Ebenen erforderlich.

2. KI-Laufzeitsicherheitsplattformen

Das Problem, das hier gelöst wird: Verhaltensbasierte Erkennung bösartiger Agentenaktivitäten zur Laufzeit – wie Prompt-Injection-Versuche, Jailbreaks, anomale Tool-Sequenzen und Datenabflussmuster.

Palo Alto Networks Prisma AIRS (Version 3.0, veröffentlicht im März 2026) ist die umfassendste Plattform in dieser Kategorie. Sie deckt KI-Anwendungssicherheit, KI-Modellsicherheit, KI-Datenschutz und den Schutz von KI-Agenten in einer einheitlichen Plattform ab. Die KI-Laufzeit-Firewall prüft LLM-Ein- und Ausgaben auf Injection-Muster und Richtlinienverstöße. AIRS umfasst zudem Funktionen für KI-Red-Teaming und Posture Management.

Lasso Security konzentriert sich speziell auf den Schutz vor Prompt-Injection und die Überwachung von LLM-Interaktionen bei agentenbasierten Workloads, wobei die MCP-Transparenz ein wesentliches Alleinstellungsmerkmal darstellt. Straiker und HiddenLayer vervollständigen die Kategorie mit Bedrohungserkennung auf Modellebene und Red Teaming.

Was ihnen fehlt: Laufzeitsicherheitsplattformen erkennen zwar Bedrohungen, steuern aber in der Regel nicht die Infrastruktur – sie arbeiten meist im Überwachungsmodus. Sie erzwingen weder Zugriffskontrollen für Modelle, Budgetobergrenzen oder Ratenbegrenzungen, noch bieten sie ein MCP-Server-Verzeichnis, das festlegt, auf welche Tools Agenten überhaupt zugreifen dürfen.

3. AI-Gateways (LLM-Proxy-Ebene)

Das gelöste Problem: Zentralisierte Steuerung jeder LLM-Anfrage – Authentifizierung, Modell-Routing, Ratenbegrenzung, Budgeteinhaltung und Beobachtbarkeit auf Anfrageebene. Das AI-Gateway fungiert als transparenter Proxy zwischen dem Agenten und dem Modellanbieter.

Dies ist eine stark besetzte Kategorie: TrueFoundry AI Gateway, Portkey, LiteLLM, Bifrostsowie Cloud-native Optionen über AWS Bedrock und Google Vertex AI. Die wichtigsten Unterscheidungsmerkmale sind die Unterstützung mehrerer Anbieter (ob das Gateway Anfragen gleichzeitig an Anthropic, OpenAI, Azure, Bedrock und Vertex weiterleiten kann), die Tiefe der Observability und ob das Gateway in eine MCP-Governance-Ebene integriert ist.

TrueFoundry AI Gateway wurde speziell für den Einsatz von KI-Agenten in Unternehmen entwickelt – mit einer p95-Latenz von unter 4 ms, über 350 RPS auf 1 vCPU, virtuellem Schlüsselmanagement, bei dem der zugrunde liegende API-Schlüssel des Anbieters niemals für Endbenutzer sichtbar ist, sowie einer nativen Integration in das TrueFoundry MCP Gateway für eine einheitliche Governance von LLMs und Tools.

Was fehlt: KI-Gateways steuern die Ebene der Modellaufrufe. Ohne ein begleitendes MCP-Gateway bleiben Tool-Aufrufe – bei denen die folgenreichsten Aktionen der Agenten stattfinden – unkontrolliert.

4. MCP-Gateways (Tool-Ebene)

Das Problem, das hier gelöst wird: Zentralisierte Governance für jeden MCP-Tool-Aufruf – welche Server erreichbar sind, welche Tools für welche Identitäten zugänglich sind, Sicherheitsvorkehrungen vor der Ausführung sowie ein vollständiger Audit-Trail darüber, was jeder Agent mit welchem Tool getan hat.

Dies ist die neueste und am schnellsten wachsende Kategorie. Da das MCP-Ökosystem auf Tausende von Servern anwächst, ist das Risiko in der Lieferkette erheblich gestiegen. Der „ToxicSkills“-Audit von Snyk ergab, dass 36,82 % von 3.984 gescannten Agenten-Skills mindestens eine Sicherheitslücke aufwiesen. Willkürliches Lesen von Dateien, RCE-Schwachstellen und Tool-Manipulationen wurden bereits in weit verbreiteten offiziellen MCP-Servern dokumentiert.

TrueFoundry MCP Gateway bietet eine zentralisierte Server-Registrierung mit rollenbasierter Zugriffskontrolle (RBAC) auf Tool-Ebene, Sicherheitsvorkehrungen vor der Ausführung, die Tool-Sequenzen mit Injektionsmustern kennzeichnen, sowie ein vollständiges Protokoll der Aufrufe – Benutzeridentität, Tool-Name, Request-Payload, Antwort, Latenz –, das über OpenTelemetry in jedes SIEM exportiert werden kann.
Siehe TrueFoundry MCP Gateway-Dokumentation für Details zur Architektur.

Was fehlt: MCP-Gateways steuern den Zugriff auf Tools, untersuchen jedoch nicht die Ebene der Modelllogik, die die Tool-Auswahl steuert – dafür benötigen Sie Laufzeitsicherheit oder Sicherheitsvorkehrungen durch ein KI-Gateway.

5. KI-Red-Teaming und Posture Management

Das Problem, das dies löst: Proaktive Identifizierung von Schwachstellen in Ihren Agenten-Deployments, bevor Angreifer sie finden – durch automatisiertes Red Teaming, Sicherheitsbewertungen und kontinuierliche Scans.

Vollständiger Plattformvergleich: Was die einzelnen Kategorien abdecken

Wo TrueFoundry einzuordnen ist: Die Infrastructure Control Plane

Die oben beschriebene Anbieterlandschaft lässt sich auf ein spezifisches mentales Modell übertragen: Einige Anbieter erkennen Bedrohungen; TrueFoundry setzt Richtlinien durch. Dies sind komplementäre, keine konkurrierenden Funktionen.

Palo Alto AIRS und Lasso Security überwachen das Verhalten von Agenten und schlagen Alarm, wenn etwas verdächtig erscheint. TrueFoundry steuert von vornherein, was überhaupt möglich ist – noch bevor eine Bedrohung die Chance hat, aktiv zu werden.

Die Architektur besteht aus drei Ebenen:

Ebene 1: AI Gateway – Der Durchsetzungspunkt für LLMs

Jeder Modellaufruf von jedem Agenten in Ihrem Unternehmen wird über das AI Gateway von TrueFoundry geleitet, ANTHROPIC_BASE_URL (oder das entsprechende Äquivalent für OpenAI, Azure, Bedrock und Vertex). Auf dieser Ebene erfolgt:

• Virtuelle Schlüsselverwaltung – Entwickler und Agentenprozesse erhalten eingeschränkte Schlüssel, die den zugrunde liegenden API-Schlüssel des Anbieters niemals offenlegen. Widerrufen Sie einen virtuellen Schlüssel, ohne das Konto beim Anbieter zu berühren oder andere Benutzer zu beeinträchtigen.
• Modell-Zugriffskontrolle – definieren Sie, auf welche Modelle jedes Team, jeder Benutzer oder jede Agentenidentität zugreifen darf. Sperren Sie GPT-4o für ein Team, das ausschließlich Claude Sonnet verwenden soll. Verhindern Sie den Zugriff auf leistungsstarke Modelle für automatisierte Pipelines, die diese nicht benötigen.
• Budgetobergrenzen und Ratenbegrenzungen – Ausgabenlimits pro Benutzer, Team oder Projekt, die verhindern, dass agentische Ausreißer-Szenarien (wie der Replit-Vorfall) unbegrenzte Rechenressourcen verbrauchen.
• Tracing auf Anfrageebene – jeder LLM-Aufruf wird mit Benutzerzuordnung, Modell, Token-Anzahl, Latenz und Kosten protokolliert. Export via OpenTelemetry nach Grafana, Datadog, Splunk oder in Ihr SIEM. Dies schließt gleichzeitig die Audit-Lücke bei Cowork, die Beobachtbarkeits-Lücke bei Claude Code und die Lücke bei der API-Schlüssel-Zuordnung.

Für die vollständige Bereitstellungsarchitektur siehe TrueFoundry Claude Code Integrationsleitfaden.

Layer 2: MCP Gateway – Der Tool-Durchsetzungspunkt

Jeder Aufruf eines MCP-Tools wird über das TrueFoundry MCP Gateway geleitet – den einzigen genehmigten Endpunkt in der managed-settings.json. Auf dieser Ebene:

• Zentralisiertes Server-Verzeichnis – nur Server, die explizit von Ihrem Plattform-Team genehmigt wurden, sind erreichbar. Angriffe nach dem ClawHavoc-Prinzip, bei denen ein Entwickler eine bösartige Marktplatz-Erweiterung installiert, werden auf Netzwerkebene blockiert, noch bevor ein Aufruf erfolgt.
• Rollenbasierter Tool-Zugriff – Ein Ingenieur hat Zugriff auf Code-Tools. Ein Finanzanalyst hat Zugriff auf schreibgeschützte Finanzdaten-Tools. Eine Admin-Pipeline hat Zugriff auf Schreib-Tools. Diese Berechtigungen werden am Gateway durchgesetzt und nicht dem Agentenprozess überlassen.
• Guardrails vor der Ausführung – Tool-Sequenzen, die Injektionsmuster aufweisen (massives Lesen von Dateien gefolgt von externen Schreibvorgängen, API-Aufrufe mit Exfiltrationsmustern), werden vor der Ausführung markiert oder blockiert.
• Vollständiger Audit-Trail für Aufrufe – Benutzeridentität, Tool-Name, Server-URL, Request-Payload, Antwort, Erfolg/Fehler und Latenz – für jeden Tool-Aufruf, über alle Agenten, alle Sitzungen und alle Teams hinweg.

Informationen zur MCP-Governance-Architektur finden Sie unter TrueFoundry MCP Gateway Dokumentation.

Ebene 3: Infrastruktur – Endpunkt-, MDM- und Netzwerkkontrollen

Die Plattformebene unterhalb beider Gateways: managed-settings.json wird per MDM bereitgestellt und sperrt die Endpunktkonfiguration, Mandantenbeschränkungen am Proxy verhindern die Umgehung der Authentifizierung privater Konten, und Netzwerkausgangskontrollen begrenzen den Browser- und Shell-Zugriff. Dies wird ausführlich behandelt in TrueFoundrys Leitfaden zur Unternehmenssicherheit für Claude.

Die OWASP Agentic AI Top 10: Wie jedes Risiko den Kontrollen zugeordnet wird

Die OWASP Top 10 für agentische Anwendungen vom Dezember 2025 sind der erste standardisierte Risikorahmen der Branche für autonome Agenten. Hier erfahren Sie, wie die wichtigsten Risiken konkreten Kontrollen zugeordnet werden:

Die Kosten des Nichtstuns

Die Kosten für die Implementierung von Sicherheitslösungen für KI-Agenten im Unternehmen sind real. Die Kosten, wenn man sie nicht implementiert, sind weitaus höher.

Die Löschung der Produktionsdatenbank bei Replit war ein Vorfall zur Geschäftskontinuität mit direkten Auswirkungen auf den Umsatz. Die ClawHavoc-Kampagne zielte auf unternehmensweite Entwickler-Credential-Stores ab. CVE-2026-25253 demonstrierte RCE gegen die Agenten-Laufzeitumgebung auf einer weit verbreiteten Plattform. Diese Vorfälle verursachten reale Sanierungskosten, Reputationsschäden und in einigen Fällen behördliche Untersuchungen.

Jenseits der Vorfälle entstehen Kosten durch die Compliance. Unternehmen, die Cowork oder Claude Code in Umgebungen mit HIPAA-, SOC 2-, DSGVO- oder Finanzregulierungsanforderungen ohne Observability auf Anfrageebene und MCP-Governance betreiben, weisen eine Sicherheitslücke bei Audits auf. Diese müssen sie früher oder später gegenüber einem Prüfer rechtfertigen. Je früher diese Lücke geschlossen wird, desto geringer sind die Kosten für die Behebung.

Sicherheitstools in diesem Bereich kosten bei Unternehmenseinsätzen mehrere tausend Dollar pro Monat. Die Reaktion auf einen Vorfall wie den Diebstahl von Zugangsdaten in Unternehmensgröße kostet Millionen.

Häufig gestellte Fragen

Was sind Sicherheitslösungen für KI-Agenten in Unternehmen?

‍Sicherheitslösungen für KI-Agenten in Unternehmen sind Plattformen und Kontrollmechanismen, die darauf ausgelegt sind, autonome KI-Agenten-Implementierungen vor spezifischen Bedrohungen für agentische Systeme zu schützen – wie Prompt-Injection, Tool-Missbrauch, Identitätsdiebstahl, Lieferkettenangriffe und Audit-Versäumnisse. Sie umfassen fünf Kategorien: Identitätssicherheit, Laufzeitsicherheit, KI-Gateways, MCP-Gateways und Red Teaming. Keine einzelne Plattform deckt alle fünf Ebenen ab; Unternehmensarchitekturen kombinieren daher mehrere Tools.

Was sind die OWASP Top 10 für agentische Anwendungen?

‍Die OWASP Top 10 für agentische Anwendungen (Dezember 2025) sind die erste branchenübliche Risikotaxonomie, die speziell für autonome KI-Agenten entwickelt wurde und sich von den OWASP LLM Top 10 unterscheidet. Die drei größten Risiken sind Prompt-Injection, Memory-Poisoning und der Missbrauch von Tools/Plugins – für keines davon bieten herkömmliche Sicherheitstools einen ausreichenden Schutz. Sie dienen als primärer Bewertungsrahmen für die Sicherheitslage von KI-Agenten in Unternehmen.

Was ist ein MCP-Gateway und warum benötigt jedes Unternehmen, das KI-Agenten einsetzt, eines?

‍Ein MCP-Gateway ist eine zentralisierte Kontrollschicht zwischen KI-Agenten und den externen Tools, auf die sie über das Model Context Protocol zugreifen. Ohne ein solches Gateway vergrößert jeder MCP-Server, mit dem sich ein Entwickler oder Agent verbindet, die Angriffsfläche direkt – ohne Governance, ohne Audit-Protokoll und ohne Durchsetzung des Least-Privilege-Prinzips. Mit einem Gateway sind nur genehmigte Server erreichbar, der Tool-Zugriff ist rollenbasiert eingeschränkt, Guardrails vor der Ausführung blockieren durch Injections ausgelöste Sequenzen und jeder Aufruf wird protokolliert. Siehe TrueFoundry MCP-Gateway-Dokumentation für Implementierungsdetails.

Was ist die minimal erforderliche Sicherheitsarchitektur für ein Unternehmen, das Claude Code oder Claude Cowork einsetzt?

‍Mindestens:

(1) Enterprise-Tarif (nicht Team/Pro/Max),

(2) SSO + SCIM über Ihren IdP,

(3) managed-settings.json via MDM mit deaktiviertem Bypass und blockierten Anmeldedatenpfaden,

(4) Sämtlicher LLM-Datenverkehr über das TrueFoundry AI Gateway,

(5) Sämtlicher MCP-Datenverkehr über das TrueFoundry MCP Gateway,

(6) OTEL-Routing an Ihr SIEM. Dies deckt Identität, Modell-Governance, Tool-Governance und Observability ab. Laufzeit-Verhaltenserkennung.

Den vollständigen Härtungsleitfaden finden Sie in der TrueFoundry Claude Code Governance-Dokumentation.

Fazit

Der Markt für Sicherheit von Enterprise-KI-Agenten existiert, weil die Bereitstellungswelle den Sicherheits-Tools vorausging. Unternehmen betreiben heute autonome Agenten in ihrer gesamten Infrastruktur mit unterschiedlichem Grad an Governance, Observability und Kontrolle. Vorfälle sind nicht mehr nur theoretisch. Die Compliance-Lücke ist nicht mehr nur theoretisch. Die behördliche Prüfung ist nicht mehr nur theoretisch.

Die Anbieterlandschaft hat sich in fünf Kategorien unterteilt: Identitätssicherheit, Laufzeitsicherheit, KI-Gateways, MCP-Gateways und Red Teaming. Kein einzelner Anbieter deckt den gesamten Stack ab. Unternehmen, die eine verteidigbare Sicherheitsstrategie aufbauen, sind diejenigen, die diese Kategorien gezielt schichten – Durchsetzung zuerst, Erkennung danach, Compliance als Ergebnis beider.

Das AI Gateway und das MCP Gateway von TrueFoundry bilden die Durchsetzungsebene dieser Architektur: die Steuerungsebene, die festlegt, worauf Agenten zugreifen können, in welchem Umfang, mit welcher Governance und mit welchem Audit-Trail. Die Erkennungsebene baut auf diesem Fundament auf. Die Compliance-Nachweise fließen aus beidem.

Das Zeitfenster, um der Bereitstellungswelle zuvorzukommen, wird immer kleiner. Unternehmen, die jetzt eine Governance-Infrastruktur aufbauen, werden über verteidigbare Sicherheitsstrategien verfügen, bevor regulatorische Rahmenbedingungen diese fordern. Unternehmen, die abwarten, werden erst als Reaktion auf Vorfälle handeln.