Am 19. März 2026 wurde die Security-Welt kurz aufgerüttelt: Trivy, eines der meistgenutzten Open-Source-Security-Scanning-Tools im Container-Ökosystem, war für kurze Zeit durch einen Supply-Chain-Angriff kompromittiert. Wäre die Community nicht schnell eingeschritten, hätten automatisierte Systeme das kompromittierte Tool weiter ausgeführt. Der Vorfall zeigt, wie schnell aus Vertrauen in technische Systeme ein reales Risiko werden kann.
Parallel dazu gewinnt in DACH eine andere Entwicklung an Bedeutung: KI-Agenten werden zunehmend in Enterprise-Prozesse integriert, über MuleSoft, über Salesforce Agentforce oder über Custom APIs. Diese Agenten verhalten sich nicht wie klassische Nutzer. Sie greifen autonom auf Schnittstellen zu, treffen Entscheidungen auf Basis ihres Kontexts und erzeugen Aufrufmuster in einer Frequenz, die kein menschlicher Anwender je erzeugen würde.
Genau in dieser Kombination liegt die eigentliche Herausforderung. Die klassische API-Security-Denke wurde für menschliche Nutzer und bekannte Anwendungen entwickelt, nicht für autonome Systeme mit dynamischem Verhalten. Für die Agentic Era braucht es deshalb ein Sicherheitsmodell, das diese neue Realität tatsächlich abbildet.
Die neue Angriffsfläche
Traditionelle API-Security basierte lange auf einem relativ klaren Kontext: Ein menschlicher Nutzer oder eine bekannte Applikation sendet strukturierte Requests, authentifiziert sich per OAuth, wird durch Rate Limits begrenzt und durch Input-Validierung gegen typische Angriffe abgesichert. KI-Agenten verschieben jedoch gleich mehrere dieser Grundannahmen.
Die erste Frage lautet: Wer ruft eigentlich an? Ein KI-Agent handelt oft im Namen eines Nutzers, ist aber nicht selbst dieser Nutzer. Wenn ein klassisches OAuth-Token dem Agenten dieselben Rechte gibt wie dem Menschen, verschwimmt die Verantwortlichkeit. Plötzlich ist unklar, wer was mit welchem Scope autorisiert hat.
Die zweite Frage ist: Was wird überhaupt angefordert? KI-Agenten generieren API-Calls nicht starr, sondern dynamisch aus ihrem Reasoning heraus. Dadurch können unerwartete Parameterkombinationen entstehen, Edge Cases in der API-Logik getroffen werden oder ganze Sequenzen von Calls ausgelöst werden, die in der ursprünglichen API-Spezifikation nie vorgesehen waren.
Die dritte Veränderung betrifft die Frequenz. Ein Agent, der 50 API-Calls pro Sekunde auslöst, verhält sich nicht automatisch bösartig. Das kann schlicht normaler Betrieb sein. Klassische Rate Limits, die für menschliche Nutzungsmuster konzipiert wurden, greifen in solchen Szenarien oft zu kurz oder blockieren im Zweifel legitimen Traffic.
Fünf KI-spezifische Angriffsmuster
1. Prompt Injection über API-Responses Einer der gefährlichsten neuen Angriffsvektoren. Ein KI-Agent ruft eine API auf und verarbeitet deren Antwort. Wenn diese Antwort manipulierte Instruktionen enthält, kann der Agent dazu gebracht werden, falsche oder schädliche Aktionen auszuführen. Kontrolliert ein Angreifer eine Datenquelle, etwa einen JIRA-Ticket-Inhalt, eine CRM-Notiz oder ein Web-Ergebnis, kann er dem Agenten über die API-Antwort neue Befehle unterschieben. Ohne saubere Ausgabe-Validierung folgt der Agent diesen Anweisungen unter Umständen blind.
2. Token Stuffing und Scope Creep In vielen Projekten werden OAuth-Tokens für KI-Agenten zu breit definiert, weil ein globaler Lesezugriff einfacher einzurichten ist als sauber granulare Scopes. Wird ein solcher Agent kompromittiert, kann er auf Daten zugreifen, die er nie hätte sehen dürfen. Die OWASP API Security Top 10 beschreiben dieses Prinzip als Broken Object Level Authorization. Im Agenten-Kontext vervielfacht sich dieses Risiko.
3. Authorization Bypass durch Verkettung Einzelne API-Calls können für sich genommen legitim und autorisiert sein. In ihrer Kombination entsteht aber ein Problem. Wenn zum Beispiel zuerst eine Nutzer-ID abgerufen wird, danach Rollen gelesen und im nächsten Schritt Berechtigungen verändert werden, ist jeder einzelne Call technisch zulässig. Die Sequenz als Ganzes wäre es jedoch nicht. Genau diese Sequenzlogik prüfen klassische API-Sicherheitsmechanismen meist nicht.
4. Datenexfiltration über Chained Calls Erlangt ein Angreifer Kontrolle über einen Agenten-Prompt, kann er den Agenten dazu bringen, systematisch Informationen aus internen Systemen abzufragen und über externe APIs, etwa scheinbar harmlose Webhooks, nach außen zu übertragen. Im MCP-Ökosystem wird dieses Muster häufig als Tool Poisoning beschrieben.
5. Denial-of-Service durch Agentic Loops KI-Agenten können in Schleifen geraten, etwa wenn sie versuchen, einen Fehler zu beheben, den sie selbst im vorherigen Schritt verursacht haben. Ohne Circuit Breaker und agentenspezifisches Rate Limiting können daraus theoretisch unendliche API-Call-Kaskaden entstehen, die Gateways und Backend-Systeme massiv belasten.
Sicherheitsfunktionen von MuleSoft für agentischen Traffic
Die MuleSoft Anypoint Platform bietet eine starke Grundlage für API-Security. Für agentische Szenarien reicht es aber nicht, Standard-Policies einfach unverändert zu übernehmen. Entscheidend ist die bewusste Konfiguration für KI-spezifisches Verhalten.
JWT-Validierung mit Agent-Claims. Standard-OAuth allein reicht nicht aus. Tokens für KI-Agenten sollten explizite Claims wie agent_id, agent_type oder session_id enthalten. Die JWT-Validation-Policy von MuleSoft lässt sich so konfigurieren, dass genau diese Claims geprüft und protokolliert werden. Das schafft Identität, Rückverfolgbarkeit und eine sauberere Abgrenzung zwischen menschlichem Nutzer und Agent.
Granulares Rate Limiting pro Agent-Typ. Nicht jeder Agent braucht dieselben Limits. Ein Dokumenten-Analyse-Agent erzeugt typischerweise andere Lastprofile als ein Echtzeit-Support-Agent. MuleSoft ermöglicht headerbasiertes Rate Limiting. Wird dieses auf einen Wert wie agent_type abgestimmt, lassen sich unterschiedliche Grenzwerte pro Agentenklasse definieren, ohne den gesamten Traffic pauschal zu behandeln.
Threat Protection Policies. Die Anypoint Platform unterstützt unter anderem IP-Blocklisting, JSON Threat Protection und XML Threat Protection. Gerade für KI-Agenten ist JSON Threat Protection besonders relevant, weil sich damit Tiefe und Größe von Payloads begrenzen lassen. Das wird wichtig, wenn ein Agent potenziell manipulierte Antworten aus externen Quellen weiterverarbeitet.
MuleSoft API Analytics. KI-Agenten hinterlassen oft charakteristische Muster: ungewöhnliche Call-Sequenzen, atypisch hohe Frequenzen oder ungewöhnliche Parameterkombinationen. Solche Anomalien lassen sich erkennen, sofern entsprechende Alerts und Auswertungen sauber konfiguriert sind.
Der Einstein Trust Layer: Was er schützt und was nicht
Für Salesforce-Agentforce-Deployments ist der Einstein Trust Layer eine wichtige Sicherheitskomponente. Er sorgt unter anderem dafür, dass Prompts und Responses nicht für Modelltraining verwendet werden (Zero Data Retention), prüft Eingaben und Ausgaben auf schädliche Inhalte, maskiert personenbezogene Daten vor der LLM-Verarbeitung und protokolliert AI-Interaktionen.
Seine Rolle sollte dennoch nicht überschätzt werden. Der Trust Layer schützt nicht vor Prompt Injection in externen Datenquellen, die der Agent selbst abruft. Er ersetzt auch keine granulare API-Authorization auf den von Agentforce genutzten APIs und verhindert keine sequenzbasierten Authorization-Bypässe. Er ist also eine wichtige Schicht, aber keine vollständige Security-Lösung. In der Praxis muss er durch API-Gateway-Security auf der MuleSoft-Schicht ergänzt werden.
Zero Trust für KI-Agenten
Das Zero-Trust-Prinzip gilt für KI-Agenten noch konsequenter als für menschliche Nutzer. Jeder Agent sollte eine eigene Service-Identität erhalten, idealerweise über einen separaten Service Account. Geteilte Tokens zwischen mehreren Agenten oder zwischen Mensch und Agent erhöhen das Risiko unnötig.
Least Privilege. Jeder Agent sollte nur genau die API-Scopes bekommen, die sein konkreter Use Case erfordert. Ein Agent mit reinem Lesezweck braucht keinen Admin-Zugriff. Diese Regel klingt selbstverständlich, wird in frühen Agentic-AI-Projekten aber besonders häufig verletzt.
Kurzlebige Tokens. Ein kompromittiertes Token mit 24 Stunden TTL öffnet einem Angreifer ein viel zu großes Zeitfenster. Ein Token mit 15 Minuten TTL reduziert dieses Fenster drastisch und verbessert die Reaktionsfähigkeit im Incident-Fall.
Session Isolation. Was ein Agent in Session A sehen oder tun darf, darf nicht automatisch Auswirkungen auf Session B haben. Gerade bei mehrstufigen Prozessen ist diese Trennung essenziell, um Seiteneffekte und Rechteausweitung zu verhindern.
Auditierbarkeit. Jeder API-Call eines Agenten sollte mit Agenten-ID, Session-ID, Zeitstempel, Payload-Hash und Response-Code protokolliert werden. Diese Logs sind nicht nur für Security Monitoring wichtig, sondern auch für Incident Response, Compliance-Nachweise und spätere Forensik.
DSGVO und NIS2: Regulatorische Pflichten
Wer KI-Agenten mit personenbezogenen Daten arbeiten lässt, bewegt sich vollständig im Anwendungsbereich der DSGVO. Der Einsatz solcher Systeme muss im Verarbeitungsverzeichnis erfasst werden. Für Hochrisiko-Verarbeitungen kann eine Datenschutz-Folgenabschätzung (DSFA) erforderlich sein. Außerdem müssen die technischen und organisatorischen Maßnahmen (TOMs) auch die agentische Schicht abdecken. Das gilt ebenso für Betroffenenrechte wie Auskunft oder Löschung, die auch dann umsetzbar bleiben müssen, wenn Daten durch Agenten verarbeitet wurden.
Auch NIS2 ist relevant. Für Unternehmen im DACH-Raum sollte man hier allerdings präzise unterscheiden: In Deutschland ist das NIS-2-Umsetzungsgesetz seit dem 6. Dezember 2025 in Kraft. In Österreich wurde das NISG 2026 Ende 2025 veröffentlicht; zentrale Bestimmungen treten am 1. Oktober 2026 in Kraft. Die Schweiz ist nicht direkt an die NIS2-Richtlinie gebunden, hat aber seit dem 1. April 2025 eine eigene Meldepflicht für Cyberangriffe auf kritische Infrastrukturen. Für API-Security in agentischen Szenarien bedeutet das insbesondere stärkere Anforderungen an Lieferkettensicherheit, belastbare Zugriffskontrolle und Authentifizierung sowie klar definierte Incident-Reporting-Prozesse. Unter NIS2 gilt dabei grundsätzlich eine Early Warning innerhalb von 24 Stunden und eine Incident Notification innerhalb von 72 Stunden.
Checkliste: API-Security-Audit mit KI-Agenten
• Separate Service Accounts für jeden KI-Agenten-Typ einrichten, minimale OAuth-Scopes dokumentieren und die Token-TTL auf höchstens 1 Stunde setzen.
• MuleSoft Rate Limiting pro Agent-Typ konfigurieren, JSON/XML Threat Protection aktivieren und sicherstellen, dass API-Responses nicht blind weitergereicht, sondern validiert werden.
• Vollständiges Audit-Logging für alle Agenten-API-Calls aktivieren und in ein SIEM integrieren, inklusive Alerts für ungewöhnliche Frequenzen.
• Ein Incident-Response-Playbook für kompromittierte Agenten-Tokens definieren und prüfen, ob für agentenbasierte Datenverarbeitung eine DSFA erforderlich oder bereits durchgeführt wurde.
Fazit
Wer KI-Agenten produktiv in Unternehmensprozesse integriert, muss API-Security neu denken. Klassische Schutzmechanismen bleiben wichtig, reichen für agentischen Traffic aber nicht mehr aus. Denn autonome Systeme greifen schneller, dynamischer und oft in komplexeren Sequenzen auf Schnittstellen zu als menschliche Nutzer oder klassische Anwendungen.
Gerade in Umgebungen mit MuleSoft, Salesforce Agentforce und Custom APIs braucht es deshalb ein Sicherheitsmodell, das Identitäten sauber trennt, Berechtigungen granular vergibt, Anomalien sichtbar macht und regulatorische Anforderungen wie DSGVO und NIS2 mitdenkt.
Die gute Nachricht: Viele der nötigen Grundlagen sind bereits vorhanden. Entscheidend ist, sie konsequent auf agentische Szenarien auszurichten. Für Unternehmen in DACH wird genau das 2026 zu einem zentralen Faktor, wenn aus ersten KI-Pilotprojekten belastbare produktive Systeme werden sollen.