KI-Agenten scheitern nicht allein: Wie Legacy-Infrastruktur sie...

Ein großer Teil der aktuellen KI-Sicherheitsdebatte konzentriert sich auf Prompt Injection, Modellmissbrauch und Datenabfluss auf Anwendungsebene. Diese Risiken sind real, aber sie erzählen nur einen Teil der Geschichte. Enterprise-KI-Agenten sind keine isolierten Systeme. Sie sitzen auf Identitätsprovidern, Cloud-Speichern, Server-Workloads, SaaS-Konnektoren, serverlosen Funktionen und privilegierten Service-Accounts. Wenn diese unteren Schichten schwach sind, wird der Agent eher zum Verstärker alter Infrastrukturprobleme als zu einer völlig neuen Klasse von Kompromittierung.

Genau deshalb ist die praktisch wichtigste Lehre aus dem jüngsten Thought-Leadership-Beitrag zu diesem Thema nicht die Marketinghülle, sondern die architektonische Warnung dahinter: Ein ungepatchter Server, eine zu offene Active-Directory-Berechtigung, ein zwischengespeichertes Entwickler-Credential oder eine zu breite IAM-Rolle können Angreifern alles liefern, was sie brauchen, um die Systeme zu erreichen, denen ein KI-Agent vertraut. In diesem Szenario müssen Angreifer das Modell nicht direkt angreifen. Das Umfeld erledigt die Arbeit für sie.

Warum KI-Agenten Legacy-Risiken standardmäßig erben

Die meisten Unternehmen führen KI-Agenten in Umgebungen ein, die lange vor den ersten Copilots oder Automationsassistenten entstanden sind. Diese Umgebungen wurden um menschliche Workflows, ältere Integrationen und operative Abkürzungen herum aufgebaut, die sich über Jahre angesammelt haben. KI löscht diese Vorgeschichte nicht. Sie erbt sie.

Agenten authentifizieren sich über bestehende Identitätssysteme und Service-Accounts.
Sie ziehen Daten aus Cloud-Buckets, Wissensspeichern und APIs, die oft bereits zu offen sind.
Sie führen Aktionen über Lambda-Funktionen, Automationsjobs oder SaaS-Integrationen mit geerbten Rechten aus.
Sie erhalten häufig mehr Zugriff, als ein vergleichbarer menschlicher Workflow jemals brauchen würde.

Wie ein realistischer Angriffspfad aussieht

1) Die Schwachstelle beginnt außerhalb des KI-Systems

In einem realistischen Enterprise-Szenario kann die Erstkompromittierung mit etwas ganz Gewöhnlichem beginnen: einem nicht rechtzeitig gepatchten internetseitigen Server, einer Entwickler-Workstation mit wiederverwendbaren Credentials oder einer zu breit gebliebenen Directory-Berechtigung aus Bequemlichkeit. Nichts davon klingt nach einer KI-spezifischen Schwachstelle. Trotzdem kann genau dort der Einstieg in einen KI-gestützten Workflow liegen.

2) Identität und Rechte machen aus einem lokalen Problem ein Plattformproblem

Sobald ein Angreifer einen Domain-gebundenen Server, einen Service-Account oder einen Entwicklerkontext erreicht, folgt oft die Ausweitung der Rechte. Zwischengespeicherte Credentials, schwache Delegationspfade, geerbte Rollenbeziehungen oder zu weitreichende Cloud-Identitäten öffnen dann den Zugriff auf Storage-Buckets, Automationsfunktionen und sensible Anwendungsdaten. Ab diesem Punkt ist der KI-Agent nicht mehr das Ziel. Er ist die Brücke zwischen bestehenden Berechtigungen und wertvollen Geschäftsdaten.

3) Der Agent operationalisiert die Reichweite des Angreifers

Genau diesen Teil unterschätzen viele Teams. Wenn der Agent bereits vertrauenswürdigen Zugriff auf Kundendaten, Dokumentation, Cloud-Speicher oder interne Systeme hat, muss sich der Angreifer möglicherweise kaum noch weiterbewegen. Der Integrations-Footprint des Agenten kann Daten offenlegen, Aktionen auslösen oder eine bequeme Schicht für unauffälligen Missbrauch bieten. Die Legacy-Infrastruktur schafft also den Einstieg, und der KI-Stack vervielfacht die Wirkung.

Wo Security-Teams zuerst hinschauen sollten

Die richtige Reaktion ist nicht, KI-Projekte einzufrieren. Die richtige Reaktion ist, KI-Sicherheit nicht als eigene Blase getrennt von Identität, Infrastruktur und Cloud-Governance zu behandeln. Die schnellsten Verbesserungen entstehen meist dadurch, dass die geerbte Kontrollschicht rund um den Agenten sauberer gemacht wird.

Patch- und Exposure-Management	Ein ungepatchter Perimeter- oder interner Server kann der erste Schritt in Agent-Abhängigkeiten sein	Internet-facing Assets, AD-gebundene Server und an Agent-Workflows gekoppelte Systeme priorisieren
Identität und Directory-Berechtigungen	Zu breite AD- und IAM-Rechte erlauben den Pivot in vertrauenswürdige Systeme des Agenten	Delegierte Rechte, Service-Accounts, Rollenvererbung und Lateral-Movement-Pfade überprüfen
Cloud-Speicher und Secrets	Buckets, Wissensspeicher und Credentials enthalten oft die Datenbasis der Agenten	Standardzugriff reduzieren, Secrets rotieren und Produktionsdaten von Entwicklerkontexten trennen
Entwickler- und Operator-Workstations	Zwischengespeicherte Credentials und lokale Tools öffnen häufig privilegierte Wege	Endpoints härten, unnötig gespeicherte Credentials entfernen und privilegierte Sessions strenger absichern
Privilege-Design des Agenten	Viele Agenten erhalten deutlich mehr Rechte als der Workflow braucht	Least Privilege durchsetzen, Aktionsumfänge begrenzen und Lese- von Schreib- oder Ausführungsrechten trennen

Ein besseres Denkmodell für KI-Sicherheit

Ein reifes KI-Sicherheitsprogramm sollte das Modell nur als eine Schicht in einer größeren Betriebskette betrachten. Wenn ein Unternehmen Prompts absichert, aber Directory-Hygiene ignoriert, Inferenz schützt, aber Bucket-Zugriffe offenlässt, oder über Datenabfluss spricht, während Service-Accounts überprivilegiert bleiben, ist das Kontrollmodell unvollständig. Die eigentliche Frage ist nicht nur, ob sich die KI täuschen lässt. Entscheidend ist, ob die umgebende Infrastruktur das KI-Umfeld nach einer klassischen Kompromittierung leicht vererbbar, missbrauchbar oder umnutzbar macht.

Das gilt besonders für Teams, die Copilots schnell in Support-, Operations-, Finanz- oder Engineering-Workflows ausrollen. Solche Agenten sitzen oft nahe an sensiblen Datensätzen und mächtigen Automationshaken. Je größer die Reichweite des Workflows, desto wichtiger wird es, versteckte Vertrauenspfade zu reduzieren, bevor der Agent geschäftskritisch wird.

Fazit

Enterprise-KI-Agenten sind nur so vertrauenswürdig wie die Infrastruktur, Identitäten und Berechtigungen unter ihnen. Das praktische Risiko ist nicht nur Prompt-Missbrauch oder Modellmanipulation. Es besteht auch darin, dass alte Schwächen in Servern, Active Directory, Cloud-Speicher und Credentials zu einem KI-Vorfall mit hoher Wirkung verkettet werden können. Der sicherste Weg ist, zuerst die umgebende Kontrollschicht zu härten: aggressiv patchen, Rechte reduzieren, sensible Datenpfade isolieren und jeden Agenten so entwerfen, als würde sein geerbter Zugriff irgendwann aktiv geprüft werden.