Agentic-AI-Sicherheit 2026: Die IAM-Kontrollen, die wirklich funktionieren

Identity- und Access-Management wurde um eine bestimmte Choreografie herum entworfen: Ein Mensch sitzt am Browser, weist seine Identität per MFA oder SSO nach, und eine Sitzung erhält einen an diesen Nachweis gebundenen Scope. Ein LLM-Agent bricht jeden Teil dieser Choreografie gleichzeitig — es sitzt kein Mensch für jede einzelne Aktion an der Tastatur, die "Sitzung" kann stundenlang oder tagelang unbeaufsichtigt laufen, und die Zugangsdaten wurden oft einmalig beim Setup festgelegt und nie wieder überprüft.

Das ist keine kleinere Version desselben Problems. Ein Chatbot, der Fragen beantwortet, hat keinen dauerhaften Zugriff, um irgendetwas zu ändern. Ein Agent, der ein Ticket liest, einen Datenbankeintrag schreibt, drei interne APIs aufruft und eine Konfigurationsänderung ausrollt, trifft bei jedem dieser Schritte eine Autorisierungsentscheidung — und IAM-Tooling, das für menschliche Sitzungen gebaut wurde, kennt das Konzept "diese Entscheidung wurde von einem Modell getroffen, das auf eine fünf Minuten alte Anweisung reagiert, nicht von einer Person" schlicht nicht.

Die praktische Konsequenz: Der Review-Rhythmus für Zugriffsrechte, die MFA-Stufenerhöhung bei sensiblen Aktionen und der "Wer hat das gemacht"-Audit-Trail, den IAM-Programme über ein Jahrzehnt für Menschen aufgebaut haben, existieren für die Agenten, die ein Platform-Team in diesem Quartal ausrollt, größtenteils noch nicht.

Fünf Fehlermuster erklären den Großteil der realen Gefährdung, sobald ein Agent Schreibzugriff erhält. Sie verstärken sich gegenseitig — überprivilegierte Zugangsdaten plus fehlender Audit-Trail machen aus einem eingrenzbaren Vorfall einen nicht mehr nachvollziehbaren.

SSO und MFA sind darauf ausgelegt, im Moment des Zugriffs die Anwesenheit eines Menschen nachzuweisen — ein autonomer Agent ist in diesem Sinne nie anwesend, weshalb das gesamte Verifikationsmodell auf ihn nicht zutrifft. Ein Agent ist eine Non-Human Identity (NHI): ein Service-Account, eine Workload-Identität oder eine API-Zugangsberechtigung, die kontinuierlich handelt statt sich einmal pro Sitzung zu authentifizieren.

Non-Human Identities übersteigen die Zahl menschlicher Identitäten in den meisten Unternehmensumgebungen bereits deutlich — ein weit verbreitetes Beobachtungsmuster über Sicherheitsanbieter und Praxisbefragungen hinweg, keine einzelne gemessene Kennzahl, die dieser Artikel zitiert, und das Verhältnis variiert je nach Organisation. Konsistent an dieser Berichterstattung ist die Richtung: Die Zahl der NHIs wächst seit Jahren schneller als die Mitarbeiterzahl, größtenteils getrieben durch Service-Accounts und Automatisierung, und Agentic AI ist inzwischen die am schnellsten wachsende Kategorie innerhalb dieses Trends.

Die meisten Enterprise-IAM-Programme führen die Bereitstellung von NHIs noch über einen leichtgewichtigeren, weniger geprüften Prozess als das Onboarding von Menschen — ein neuer Mitarbeiter erhält einen Access-Review, eine Freigabe durch die Führungskraft und eine planmäßige Rezertifizierung; ein neuer Service-Account oder ein Agent-Credential erhält davon häufig nichts. Diese Lücke war tolerierbar, solange NHIs meist statische Skripte mit engem Scope waren. Sie ist nicht mehr tolerierbar, wenn die NHI ein Agent ist, der Tool-Aufrufe verketten, mehrdeutige Anweisungen interpretieren und Aktionen ausführen kann, die sein Provisionierer nicht vorab explizit aufgezählt hat.

Bewerten Sie eine konkrete Agent-Bereitstellung anhand von fünf Dimensionen, um eine Blast-Radius-Stufe und eine passende Least-Privilege-Empfehlung zu erhalten. Das läuft vollständig in Ihrem Browser — es wird nichts übertragen.

Sechs Kontrollen erklären den Großteil der tatsächlichen Reduktion des Agent-Blast-Radius. Keine davon reicht allein — sie verstärken sich gegenseitig, genau wie die Fehlermuster des Bedrohungsmodells.

Das Modell eines Agenten auf selbst gehosteter Infrastruktur zu betreiben, beseitigt das Risiko der Datenweitergabe an Dritte und hält Prompts und Ausgaben im eigenen Netzwerk — es löst nicht das Identity- und Access-Problem, um das es in diesem Artikel geht. Ein sicherheitserfahrener Leser würde den Rest dieses Leitfadens abwerten, wenn diese Unterscheidung verwischt würde — deshalb sei sie hier klar benannt.

Lokale Bereitstellung löst kein Prompt-Injection-Problem. Injection ist ein Problem der Anwendungsebene und der Architektur — wie der Agent vertrauenswürdige Anweisungen von nicht vertrauenswürdigen, abgerufenen Inhalten unterscheidet — und ist identisch, egal ob das zugrunde liegende Modell auf einer Anbieter-API oder auf eigener Hardware läuft. Das Modell ins eigene Haus zu holen ändert nichts daran, wie der Agent eine Webseite oder ein Dokument verarbeitet, das er lesen soll.

Lokale Bereitstellung löst kein Problem überprivilegierter Zugangsdaten. Ein selbst gehostetes Modell, das einen überprivilegierten Service-Account aufruft, ist genauso gefährlich wie ein anbietergehostetes Modell, das denselben Account aufruft — der Scope der Zugangsdaten ist eine Eigenschaft der Zugriffsarchitektur des Agenten, nicht davon, wo die Modellgewichte laufen.

Lokale Bereitstellung löst kein Problem eines fehlenden Audit-Trails. Ob Inferenz auf einer gemieteten API oder einer eigenen GPU läuft, hat keinen Einfluss darauf, ob eine Aktion mit Zuordnung zu der autorisierenden Person protokolliert wird. Das ist eine separate Entscheidung zu Logging und Identitätsarchitektur.

Wofür lokale Bereitstellung in diesem Kontext tatsächlich gut ist: den Inhalt von Prompts und Tool-Ausgaben von der Infrastruktur Dritter fernzuhalten — relevant für Datenresidenz und Drittanbieterrisiko. Sie ist ein Baustein einer Agent-Sicherheitsarchitektur, kein Ersatz für die oben genannten Identity- und Access-Kontrollen.

Für in der EU tätige Unternehmen im Finanzsektor oder bei kritischer Infrastruktur können sich bei einem Agent-Deployment drei Regelwerke gleichzeitig überschneiden. NIS2 verlangt Vorfallmeldung, Lieferkettensicherheit und — für in den Anwendungsbereich fallende Einrichtungen — persönliche Verantwortlichkeit der Geschäftsleitung. DORA gilt speziell für Finanzunternehmen und verlangt ein Register der IKT-Drittparteirisiken; ein autonomer Agent, der externe APIs aufruft, ist unter DORA vertretbar als registrierungspflichtige IKT-Abhängigkeit, was die meisten Unternehmen bislang nicht bedacht haben. Der AI Act legt je nach Risikoeinstufung des Agenten eine weitere Schicht darüber.

Der praktische Effekt: Drei sich überschneidende Regelwerke, die gleichzeitig gelten können, erzeugen für Agent-Bereitstellungen in regulierten EU-Sektoren realen Druck in Richtung souveräner beziehungsweise On-Premise-Hosting-Architekturen — nicht als rechtliche Pflicht per se, sondern weil eine On-Premise-Architektur die Nachweispflichten unter allen drei Regelwerken vereinfacht.

Ob NIS2 und DORA für ein konkretes Unternehmen greifen, hängt von Sektor und Einrichtungsklassifizierung ab — dieser Abschnitt ist allgemeine Orientierung, keine Rechtsberatung. Klären Sie die Anwendbarkeit vor der finalen Architekturentscheidung mit einer auf NIS2/DORA/AI Act spezialisierten Kanzlei.