Das Souveränitätstheater
Ein DACH-Mittelständler verlagert seine LLM-Workload in ein Frankfurter Rechenzentrum, hakt die Sovereign-Cloud-Box ab und geht davon aus, das KI-Risiko adressiert zu haben. Währenddessen hält der Kundenservice-Agent, den das Unternehmen im letzten Quartal ausgerollt hat, weiterhin permanenten Schreibzugriff auf das CRM, Lesezugriff auf das ERP und die Fähigkeit, Freigabe-Workflows im Ticketing-System auszulösen. Keine Ablaufrichtlinie. Keine Scope-Prüfung. Kein Audit-Trail, der Aktionen auf die Aufgabe zurückführt, die den Zugriff ursprünglich rechtfertigte.
Die Souveränitätsdiskussion – wo die Berechnung stattfindet, welche Jurisdiktion die Daten regelt, ob der Hyperscaler in US-Besitz ist – ist relevant. Aber sie adressiert nur einen schmalen Ausschnitt des Enterprise-KI-Risikos. Das größere, unmittelbarere Governance-Versagen liegt eine Ebene darunter: nicht-menschliche Identitäten, die autonom handeln, Berechtigungen erben, die für Menschen konzipiert wurden, und außerhalb der Lifecycle-Kontrollen operieren, die IT-Teams ein Jahrzehnt lang für Mitarbeiter und Service-Accounts aufgebaut haben.
Ein kompromittierter Agent, ein über-berechtigter Agent oder ein Agent, der von seinem ursprünglichen Aufgaben-Scope abdriftet, wird seinen Schaden anrichten – unabhängig davon, ob die Inferenz in einem deutschen Rechenzentrum oder einer US-Region läuft. Das Risiko liegt nicht in den Modellgewichten oder der Hosting-Geografie. Das Risiko liegt darin, was der Agent tun darf – und wie schlecht die meisten Organisationen diese Frage steuern.
Was Agent-Identitäten anders macht
Service-Accounts sind seit Jahren ein Governance-Kopfschmerz. Sie vermehren sich, sie laufen selten ab, und sie halten oft mehr Berechtigungen, als jemals einem einzelnen Menschen gewährt würden. Aber sie sind wenigstens statisch. Ein Service-Account für einen nächtlichen ETL-Job macht jede Nacht dasselbe. Sein Verhalten ist vorhersehbar. Sein Scope ist eng.
KI-Agents brechen dieses Modell. Ein Agent, der Support-Tickets lösen soll, kann – wenn über Tool-Calling-Frameworks wie Function Calling oder ReAct-Patterns orchestriert – damit beginnen, Ticket-Metadaten zu lesen, dann zum Abruf von Kundendatensätzen eskalieren, dann das ERP nach Bestellhistorie abfragen, dann eine E-Mail entwerfen und dann – wenn die Aufgabe es erfordert – ein Feld im CRM aktualisieren. Die Sequenz ist dynamisch. Die berührten Daten sind kontextabhängig. Die erforderlichen Berechtigungen variieren je nach Aufgabe. Und weil der Agent autonom ist, trifft er diese Entscheidungen ohne einen Menschen in der Schleife.
Das schafft eine Governance-Oberfläche, für die traditionelle Identity-and-Access-Management-Systeme nie gebaut wurden. Die meisten IAM-Plattformen können eine Rolle zuweisen, Multi-Faktor-Authentifizierung durchsetzen und Zugriffsereignisse protokollieren. Sie haben Schwierigkeiten zu beantworten: Brauchte dieser Agent diese spezifische Berechtigung für diese spezifische Aufgabe in diesem spezifischen Moment? Und sie haben keinen Mechanismus, um Zugriff zu widerrufen, sobald die Aufgabe abgeschlossen ist.
Das Ergebnis ist in jeder Produktionsumgebung, die ich geprüft habe, dasselbe: Agents sind standardmäßig über-berechtigt. Entwickler gewähren während der Pilotphase breiten Zugriff, der Agent geht mit diesen Berechtigungen in Produktion, und niemand überprüft den Scope, bis etwas kaputtgeht – oder bis ein Regulator fragt, warum ein Agent, der Dokumente zusammenfassen soll, auch Schreibzugriff auf Finanzsysteme hat.
Die Runtime-Signale, die zählen
Wenn Sie Über-Berechtigungen nicht zur Design-Zeit verhindern können – und die meisten Organisationen können das nicht, weil Agent-Verhalten emergent und aufgabenspezifisch ist – brauchen Sie Runtime-Erkennung. Das bedeutet: protokollieren und analysieren, was Agents tatsächlich tun, nicht nur, was sie tun dürfen.
Credential- und Secret-Zugriff außerhalb des Aufgaben-Scope ist das erste Signal. Wenn ein Agent, der einen Rendering-Bug in einer Webanwendung behebt, plötzlich AWS-Credentials berührt, ist das keine legitime Eskalation – es ist entweder eine Kompromittierung oder ein Fehler im Task-Scoping. Least-Privilege-Architektur ist hier die Verteidigung, aber Monitoring für Credential-Zugriff außerhalb des Scope ist die Erkennungsschicht, die greift, wenn diese Architektur versagt.
Berechtigungsnutzungsmuster über Zeit sind das zweite Signal. Ein Agent, dem während der Entwicklung zehn Berechtigungen gewährt wurden, nutzt in Produktion vielleicht nur zwei. Diese Lücke – zwischen gewährten und ausgeübten Berechtigungen – ist ein Governance-Befund. Sie sagt Ihnen, dass der Agent über-provisioniert ist, und sie gibt Ihnen eine konkrete Liste von Berechtigungen zum Widerrufen. In einer typischen Analyse könnte sich zeigen, dass ein Agent über dreißig Tage nur eines der Tools und zwei der Berechtigungen nutzt, die ihm ursprünglich gewährt wurden. Das ist keine theoretische Übung; es ist ein direkter Input für Access-Reviews.
Verhaltens-Drift ist das dritte Signal. Ein Agent, der beginnt, Aktionen außerhalb seines dokumentierten Zwecks auszuführen – Datensätze abzufragen, für die er nie gescoped war, Workflows auszulösen, für die er nie konzipiert wurde – reagiert möglicherweise auf adversarielle Prompts, hat möglicherweise Berechtigungen von einer kompromittierten Identität geerbt oder verhält sich einfach auf Weisen, die der Entwickler nie antizipiert hat. Ohne persistente Sichtbarkeit dessen, was der Agent tut, können Sie weder Zugriff steuern, noch Missbrauch erkennen, noch Compliance nachweisen.
Die Lifecycle-Lücke
Die meisten Unternehmen haben Lifecycle-Richtlinien für Mitarbeiter: Onboarding, Access-Reviews, Offboarding. Einige haben Lifecycle-Richtlinien für Service-Accounts, obwohl die Durchsetzung oft schwach ist. Fast niemand hat Lifecycle-Richtlinien für KI-Agents.
Das bedeutet: Agents werden geboren – von einem Entwickler aufgesetzt, mit Berechtigungen ausgestattet, auf Produktionssysteme gerichtet – ohne in ein gesteuertes Inventar registriert zu werden. Sie leben ohne Ablaufrichtlinien, ohne Ownership-Records, ohne Reauthorisierungs-Trigger. Und sie sterben (oder vielmehr: sie werden nicht mehr genutzt) ohne Deprovisioning, sodass Credentials aktiv und Berechtigungen intakt bleiben, lange nachdem der Zweck des Agents abgelaufen ist.
Ein reifes Governance-Modell behandelt KI-Agents als erstklassige Identitäten mit durchsetzbaren Lifecycle-Zuständen. Das umfasst: Agents über Cloud-, SaaS- und Scripting-Umgebungen hinweg zu entdecken; sie in ein Inventar mit Ownership- und Zweck-Metadaten zu registrieren; Ablauf-, Review- und Reauthorisierungs-Richtlinien zuzuweisen; und Deprovisioning als Default-Zustand durchzusetzen. Ohne diese Struktur managen Security-Teams eine undokumentierte Parallel-Belegschaft – eine, die schneller skaliert, autonomer operiert und mehr Berechtigungen hält, als es die menschliche Belegschaft je tat.
Die Alternative ist das, was ich heute in den meisten DACH-Mittelstandsumgebungen sehe: Agents, die in einem Governance-Schatten existieren. IT weiß, dass sie laufen. Security weiß, dass sie Credentials halten. Aber niemand weiß, wie viele es sind, wer sie besitzt, was sie tun dürfen oder wann sie stillgelegt werden sollten. Das ist kein Sovereign-Cloud-Problem. Das ist ein Identity-Governance-Problem, und es wird Ihnen in jede Hosting-Jurisdiktion folgen.
Was Regulatoren fragen werden
NIS2, DORA und der EU AI Act schaffen alle Verpflichtungen, die Agent-Governance berühren, auch wenn sie Agents nicht explizit benennen. NIS2 verlangt, dass Einrichtungen ein Inventar von Assets führen, Zugriffskontrollen implementieren und Rechenschaftspflicht für Aktionen automatisierter Systeme sicherstellen. Ein Agent, der Produktionsdaten ändern, Finanztransaktionen auslösen oder auf Kundendaten zugreifen kann, ist ein Asset. Wenn Sie ihn nicht inventarisieren, seinen Zugriff nicht kontrollieren oder seine Aktionen nicht nachverfolgen können, sind Sie nicht compliant.
DORA verlangt von Finanzeinrichtungen, IKT-Risiken zu managen, einschließlich Drittanbieter- und operationeller Abhängigkeiten. Ein KI-Agent ist eine operationelle Abhängigkeit. Wenn er ausfällt, kompromittiert wird oder sich unvorhersehbar verhält, ist die Auswirkung operationell. Das Risikomanagement-Framework muss das berücksichtigen, und das Test-Regime muss validieren, dass Kontrollen unter Stress funktionieren. Sie können nicht testen, was Sie nicht inventarisiert haben, und Sie können nicht managen, was Sie nicht gescoped haben.
Der EU AI Act verlangt, insbesondere für Hochrisikosysteme, menschliche Aufsicht, Transparenz und die Fähigkeit zu intervenieren. Ein Agent, der autonom operiert, ohne Runtime-Monitoring, ohne Task-Level-Audit-Trails und ohne Mechanismus, Berechtigungen mid-task zu widerrufen, scheitert an der Aufsichtsanforderung. Souveränität behebt das nicht. Ein gesteuerter Identity-Lifecycle schon.
Die Engineering-Arbeit, die zählt
Das zu beheben ist keine Beschaffungsübung. Es ist eine Engineering- und Governance-Übung, und sie erfordert drei Fähigkeiten, die die meisten DACH-Mittelständler noch nicht etabliert haben.
Erstens: Sichtbarkeit. Sie brauchen ein Inventar jedes Agents, jeder Identität, die er nutzt, jeder Berechtigung, die er hält, und jedes Systems, das er berührt. Dieses Inventar muss live sein – aktualisiert, wenn Agents erstellt, modifiziert und stillgelegt werden – und es muss abfragbar sein, sodass Security- und Compliance-Teams Fragen beantworten können wie „welche Agents können ins ERP schreiben?" oder „welche Agents wurden in den letzten neunzig Tagen nicht geprüft?"
Zweitens: fein-granulare Zugriffskontrollen. Agents sollten nicht rollenbasierten Zugriff erben, der für Menschen konzipiert wurde. Sie brauchen task-scoped, zeitgebundene Berechtigungen, die auf die spezifischen Aktionen abbilden, für die sie konzipiert sind. Das bedeutet: weg von „dieser Agent ist ein Service-Account mit Contributor-Zugriff" hin zu „dieser Agent kann Kundendatensätze im CRM lesen, aber nur für Tickets, die ihm zugewiesen sind, und nur für die Dauer der Aufgabe."
Drittens: Lifecycle-Durchsetzung. Jeder Agent braucht einen Owner, ein Ablaufdatum und eine Reauthorisierungs-Richtlinie. Wenn der Agent nicht mehr benötigt wird, müssen seine Credentials widerrufen und seine Berechtigungen deprovisioned werden. Das klingt offensichtlich, aber es ist nicht der Default in irgendeiner Umgebung, die ich geprüft habe. Der Default ist, dass Agents für immer leben und ihre Berechtigungen sich akkumulieren.
Nichts davon wird gelöst, indem Sie einen Sovereign-Cloud-Anbieter wählen. Es wird gelöst, indem Sie Agents als neue Kategorie von Identität behandeln, mit Governance-Anforderungen, die strenger sind als die für Menschen und dynamischer als die für traditionelle Service-Accounts. Die Unternehmen, die das früh herausfinden, werden einen strukturellen Vorteil haben, wenn Regulatoren beginnen, KI-Risiko zu auditieren. Die Unternehmen, die annehmen, dass Souveränität ausreicht, werden zu spät entdecken, dass das Risiko nie im Hosting-Standort lag – es lag in den Berechtigungen.
Ein Diagnostic kartiert Ihr aktuelles Agent-Inventar, identifiziert über-berechtigte Identitäten und definiert die Lifecycle-Kontrollen, die Sie brauchen, bevor ein Regulator fragt – oder bevor ein Agent außerhalb seines Scope handelt.
References: Xu quoted in „Securing AI Agents Before They Go Rogue Is Next to Impossible," Dark Reading, 2026; „AI Agents Are Here. Security Must Be an Accelerator for AI Transformation," Infosecurity Magazine, 2026; Sokach, „AI Safety is About Smaller Permissions, Not Smarter Models," Hospitality Net, 2026; „Your AI agent could become your biggest insider threat," CyberScoop, 2026; „5 runtime signals for catching a compromised AI agent," CSO Online, 2026; „Sovereign cloud won't fix your AI risk. Identity governance will," CSO Online, 2026; „Shifting Budget Dynamics for Identity Security and AI Agents," Dark Reading, 2026; „The Lifecycle Crisis: Managing the Birth, Life, and Death of AI Agents," Dark Reading, 2026.