Viele Unternehmen testen KI-Agenten nicht mehr nur als Chat-Oberfläche. Sie setzen sie zunehmend als operative Helfer ein: Sie lesen Tickets, durchsuchen Dokumente, schreiben Code, greifen auf SaaS-APIs zu oder starten Cloud-Workflows. Damit entsteht ein handfestes Sicherheitsproblem. Ein Agent ist kein klassischer Benutzer, aber auch kein gewöhnlicher Service-Account. Er handelt im Auftrag eines Menschen, nutzt eigene Werkzeuge, verarbeitet Kontext aus mehreren Quellen und kann Aktionen mit realen Folgen auslösen.
Damit verschiebt sich die zentrale Frage. Es geht nicht mehr nur darum, ob ein Modell richtige Antworten liefert. Entscheidend wird, welche Identität ein Agent im Unternehmen hat, welche Rechte er nutzt, wer für ihn verantwortlich ist und wie sich seine Aktionen nachträglich nachvollziehen lassen. Zwei aktuelle Meldungen zeigen, warum das Thema die Experimentierphase verlässt: SailPoint kündigte am 11. Mai 2026 „Agentic Fabric“ an, eine Plattform zur Governance von KI-Agenten und anderen nicht-menschlichen Identitäten. Am selben Tag griff CSO Online öffentlich verfügbare Forschung zu ungeschützten MCP-Servern auf. Beide Meldungen beschreiben denselben Trend: Agenten-Sicherheit wird zu Identity- und Access-Management für autonome Systeme.
Warum Agenten anders sind als Service-Accounts
Klassische Service-Accounts bereiten vielen Unternehmen schon heute Probleme. Sie laufen über Jahre, verfügen oft über breite Rechte und werden selten konsequent rezertifiziert. KI-Agenten verschärfen dieses Muster. Sie treffen Entscheidungen oder wählen zumindest dynamisch Werkzeuge aus. Je nach Aufgabe greifen sie auf Dokumente, Code-Repositories, Kalender, CRM-Systeme, Cloud-Ressourcen oder interne Datenbanken zu. Läuft dieser Zugriff über einen pauschalen API-Key, lässt sich aus Security-Sicht kaum noch unterscheiden, ob eine Aktion legitim, fehlerhaft oder manipuliert war.
SailPoint adressiert genau diese Lücke in der Ankündigung zu Agentic Fabric. Unternehmen müssten KI-Agenten, Maschinenidentitäten und Anwendungen über Cloud-Umgebungen, Applikationen und Endpunkte hinweg entdecken, einem menschlichen Eigentümer zuordnen, Lifecycle-Kontrollen anwenden und Zugriffe in Echtzeit autorisieren. Entscheidend ist weniger die Produktverpackung als die Architekturannahme dahinter: Jeder Agent braucht eine überprüfbare Beziehung zu einem Menschen, einem Zweck, einem Datensatz und einem definierten Satz erlaubter Aktionen.
Das klingt nach klassischer Identity-Governance. Technisch ist es anspruchsvoller als ein weiterer Eintrag im IAM-System. Agenten wechseln Kontext, rufen Tools auf, erzeugen Zwischenergebnisse und binden über Frameworks wie das Model Context Protocol, kurz MCP, externe Funktionen an. Damit wandert die Identitätsfrage in die Laufzeitumgebung des Agenten: Was darf dieser Agent jetzt, in diesem konkreten Task, mit diesen Daten und diesem Tool tun?
MCP macht die Angriffsfläche sichtbar
Anthropic stellte MCP im November 2024 vor, um große Sprachmodelle standardisiert mit externen Tools und Datenquellen zu verbinden. Für Entwickler ist das Protokoll attraktiv, weil es Integrationen vereinfacht. Ein Agent kann über einen MCP-Server etwa verfügbare Werkzeuge auflisten und anschließend Aktionen gegen angebundene Systeme ausführen. Genau diese Bequemlichkeit macht MCP sicherheitsrelevant.
Knostic veröffentlichte im Juli 2025 eine Untersuchung zu öffentlich erreichbaren MCP-Servern. Die Forscher nutzten Shodan und eigene Python-Tools, um MCP-Instanzen im Internet zu identifizieren. Das Ergebnis: 1.862 MCP-Server waren öffentlich auffindbar. Aus dieser Menge prüfte Knostic 119 Server manuell. Alle 119 erlaubten laut Bericht Zugriff auf interne Tool-Listings ohne Authentifizierung. Zugleich betonten die Forscher, dass sie nur internet-exponierte Server untersuchten und viele MCP-Installationen in privaten Netzen laufen können. Die Zahl ist daher keine Gesamtschätzung für den Markt. Sie zeigt aber, wie unsicher frühe Deployments ausfallen können.
CSO Online griff diese Befunde am 11. Mai 2026 erneut auf und ordnete sie als Zero-Trust-Problem für die Agenten-Ära ein. Kritisch ist nicht nur, dass ein Server erreichbar war. Entscheidend ist, was ein Tool-Listing offenlegt: Welche internen Systeme ein Agent erreichen kann, welche Aktionen vorgesehen sind und welche Workflows automatisiert wurden. Für Angreifer ist das eine Landkarte. Selbst wenn sich keine Aktion direkt auslösen lässt, liefern Namen, Endpunkte, Tool-Beschreibungen und Parameterstrukturen wertvolle Aufklärung.
Die technische Kontrollfrage: Wer autorisiert die Handlung?
Bei Agenten reicht die klassische Berechtigungskette nicht aus. Ein Mitarbeiter kann einen Agenten legitim starten. Im weiteren Verlauf sieht der Agent aber neue Informationen, nutzt ein Plugin oder wird durch Prompt-Injection zu einer unerwünschten Aktion bewegt. Die Berechtigung darf deshalb nicht nur beim Start geprüft werden. Sie muss an die konkrete Handlung gebunden sein.
Ein robustes Modell braucht mindestens fünf Ebenen. Erstens Inventarisierung: Welche Agenten, MCP-Server, Plugins und Maschinenidentitäten existieren überhaupt? Zweitens Ownership: Jeder Agent benötigt einen fachlichen und technischen Besitzer. Drittens Least Privilege: Rechte werden pro Tool, Datendomäne und Aktion vergeben, nicht pauschal pro Agent. Viertens Laufzeit-Autorisierung: Kritische Aktionen wie Datenexporte, Rechteänderungen, Deployment-Starts oder Finanztransaktionen erfordern kontextabhängige Freigaben. Fünftens Auditierbarkeit: Logs müssen Nutzer, Agent, Prompt-Kontext, Tool-Aufruf, Datenquelle, Ergebnis und Policy-Entscheidung miteinander verknüpfen.
Was Unternehmen jetzt konkret prüfen sollten
Der erste Schritt ist eine Bestandsaufnahme. Security-Teams sollten nicht nur nach offiziell eingeführten Agenten fragen. Sie müssen auch Entwickler-Tools, lokale MCP-Server, Copilot-Erweiterungen, Automatisierungsskripte und Schattenintegrationen erfassen. Viele Risiken entstehen nicht im zentralen AI-Programm, sondern in Teams, die schnell einen nützlichen Workflow bauen.
Zweitens sollten MCP-Server grundsätzlich nicht öffentlich erreichbar sein, sofern kein explizit abgesichertes Betriebsmodell existiert. Authentifizierung, TLS, Netzwerkzugriffsbeschränkungen, Rate Limits und klare Tool-Scopes sind Mindestanforderungen. Tool-Listings dürfen nicht anonym abrufbar sein. Für produktive Systeme sollten Unternehmen zusätzlich prüfen, ob ein MCP-Server nur lesen darf oder auch schreibende Aktionen ausführen kann.
Drittens müssen Unternehmen Agentenrechte regelmäßig rezertifizieren. Ein Agent, der für einen Proof of Concept Lesezugriff auf Testdaten hatte, darf später nicht stillschweigend Produktionsdaten, Ticketsysteme oder Cloud-Konten erreichen. Lifecycle-Prozesse für Agenten sollten deshalb ähnlich streng ausfallen wie für privilegierte Accounts: Antrag, Begründung, Besitzer, Ablaufdatum, Review und Entzug.
Viertens braucht Incident Response neue Fragen. Wenn ein Agent eine falsche Aktion ausführt, reicht es nicht zu wissen, welcher API-Key genutzt wurde. Teams müssen rekonstruieren können, welcher Nutzer den Lauf gestartet hat, welche Instruktionen im Kontext lagen, welches Tool warum gewählt wurde und ob die Policy-Engine eine Ausnahme zugelassen hat.
Risiken und Grenzen der aktuellen Lage
Die SailPoint-Meldung ist eine Anbieterankündigung, kein unabhängiger Wirksamkeitsnachweis. Unternehmen sollten solche Plattformen deshalb an eigenen Anforderungen messen: Unterstützte Agenten-Frameworks, Integrationen in bestehende IAM- und SIEM-Systeme, Policy-Tiefe, Latenz bei Laufzeitentscheidungen und Qualität der Logs sind entscheidend. Ebenso wichtig ist die Frage, ob sich proprietäre Kontrollschichten vermeiden lassen oder ob neue Abhängigkeiten entstehen.
Auch die MCP-Zahlen brauchen Einordnung. Knostic untersuchte öffentlich erreichbare Server und verifizierte eine Stichprobe. Daraus folgt nicht, dass jedes MCP-Deployment unsicher ist. Die Untersuchung zeigt aber, dass frühe Implementierungen häufig ohne ausreichende Zugriffskontrollen betrieben wurden. Für Unternehmen reicht das als Warnsignal: Agenten-Infrastruktur darf nicht wie ein internes Entwicklerexperiment behandelt werden, sobald sie reale Systeme berührt.
Fazit
KI-Agenten verschieben Security von der Modellfrage zur Handlungsfrage. Das Risiko liegt nicht allein im Sprachmodell, sondern in der Kombination aus Identität, Kontext, Tool-Zugriff und Berechtigung. Die SailPoint-Ankündigung und die erneut diskutierten MCP-Funde zeigen, dass der Markt beginnt, Agenten als eigene Identitätsklasse zu behandeln.
Für Unternehmen ist die Konsequenz pragmatisch: Jeder Agent braucht einen Besitzer, einen Zweck, minimale Rechte, laufzeitnahe Autorisierung und nachvollziehbare Logs. Wer MCP-Server, Plugins und Agenten-Workflows ohne diese Kontrollen betreibt, schafft neben dem bestehenden IAM eine neue privilegierte Zugriffsschicht. Die gute Nachricht: Die passenden Kontrollprinzipien sind nicht neu. Sie müssen jetzt konsequent auf autonome Systeme angewendet werden.
Quellen: SailPoint/GlobeNewswire, „SailPoint Launches Agentic Fabric to Secure AI Identities Across the Enterprise“, 11. Mai 2026; CSO Online, „1,800+ MCP servers exposed without authentication: How zero trust can secure the AI agent revolution“, 11. Mai 2026; Knostic, „Exposing the Unseen: Mapping MCP Servers Across the Internet“ und „How to Find an MCP Server with Shodan“, 17. Juli 2025.
