Jacob Ideskog, CTO von Curity – Interviewreihe

Jacob Ideskog ist Identity Specialist und CTO bei Curity. Er beschäftigt sich hauptsächlich mit Sicherheitslösungen im API- und Webbereich. Er hat sowohl OAuth- als auch OpenID Connect-Lösungen für große Unternehmen als auch für Startups konzipiert und implementiert.

Neugier ist eine moderne Identity- und Access-Management-Plattform (IAM), die auf dem Curity Identity Server basiert – einer standardbasierten Lösung für die sichere Authentifizierung und Autorisierung von Anwendungen, APIs und digitalen Diensten in großem Umfang. Sie unterstützt Protokolle wie OAuth 2.0 und OpenID Connect, um Anmeldeprozesse zu zentralisieren, differenzierte Zugriffsrichtlinien durchzusetzen und sichere Token für menschliche Benutzer und Maschinenclients, einschließlich APIs und Diensten, auszustellen. Die Plattform ist flexibel und skalierbar und ermöglicht es Unternehmen, sie in Cloud-, Hybrid- oder On-Premise-Umgebungen bereitzustellen, in bestehende Systeme zu integrieren und sichere, nahtlose Benutzererlebnisse zu bieten, ohne auf eine individuell entwickelte Sicherheitsinfrastruktur angewiesen zu sein.

Sie haben einen Großteil Ihrer Karriere dem Aufbau von Identitäts- und API-Sicherheitssystemen gewidmet, von der Mitgründung von Curity bis hin zur Leitung als CTO während des Aufstiegs von Cloud und nun KI. Wie hat dieser Werdegang Ihre Ansicht geprägt, dass KI-Agenten als vollwertige digitale Identitäten und nicht nur als weitere Software behandelt werden sollten?

In jedem Technologiebereich, in dem ich gearbeitet habe, taucht ein Problem immer wieder auf. Ob Cloud Computing oder jetzt KI: Wenn Software im Auftrag einer Person oder eines anderen Systems agiert, entsteht ein Identitätsproblem.

Mit der zunehmenden Verbreitung von KI-Agenten verschärft sich dieses Problem. Ihr Verhalten ist nicht mehr streng vorgegeben, und sie agieren mit einem Grad an Autonomie, den Unternehmen bisher nicht kannten. KI-Agenten treffen Entscheidungen, rufen APIs auf und verketten Aktionen systemübergreifend – oft ohne direkte menschliche Aufsicht. Dieses Verhalten führt zu Herausforderungen in Bezug auf Identität und Zugriff, die sich grundlegend von denen herkömmlicher Software unterscheiden.

Die Behandlung von KI-Agenten als vollwertige digitale Identitäten ist der einzige Weg, diesem Problem angemessen zu begegnen. Wenn Unternehmen sie lediglich als weitere Prozess- oder Servicekonten behandeln, verlieren sie sehr schnell an Transparenz und Kontrolle – und das ist ein Rezept für eine Sicherheitskrise.

Viele Unternehmen sind von agentenbasierter KI begeistert, befinden sich aber noch in der Experimentierphase. Welche Identitäts- und Governance-Lücken verhindern Ihrer Erfahrung nach am häufigsten, dass Unternehmen Agenten sicher skalieren können?

Die meisten Experimente finden in isolierten Testumgebungen statt, die die Auswirkungen im großen Maßstab außer Acht lassen. In frühen Pilotphasen erhalten die Anwender oft weitreichende API-Schlüssel, gemeinsame Zugangsdaten oder pauschale Cloud-Berechtigungen, nur um die Projekte überhaupt erst in Gang zu bringen.

Dieser Ansatz scheitert, sobald Agenten über die Pilotphase hinaus eingesetzt werden. Denn Sicherheitsteams können nicht einsehen, auf welche Daten ein Agent zugegriffen hat, welche Aktionen er durchgeführt hat oder ob er seinen vorgesehenen Aufgabenbereich überschritten hat – sei es versehentlich oder vorsätzlich. Diese blinden Flecken machen eine sichere Steuerung der Agenten unmöglich, weshalb viele Organisationen Schwierigkeiten haben, die Pilotphase zu beenden.

Sie haben argumentiert, dass strenge Leitplanken für agentenbasierte KI unerlässlich sind. Wie sieht ein „gutes“ Identitätsdesign für KI-Agenten in der Praxis aus, und wo machen Unternehmen typischerweise Fehler?

Gutes Identitätsdesign basiert auf dem Prinzip der minimalen Berechtigungen und Berechtigungen, die an einen expliziten Zweck geknüpft sind. Jeder KI-Agent sollte eine eigene Identität, eng definierte Berechtigungen und klar definierte Vertrauensbeziehungen (explizite Regeln, mit welchen Systemen er interagieren darf) besitzen. Grundsätzlich sollte der Zugriff zweckgebunden, zeitlich begrenzt und leicht widerrufbar sein.

Unternehmen begehen den Fehler, bestehende Servicekonten wiederzuverwenden oder anzunehmen, interne Agenten seien standardmäßig sicher. Diese Annahme hält realen Bedrohungen nicht stand. Angreifer suchen aktiv nach genau diesen Schwachstellen, und KI-Agenten vergrößern das potenzielle Ausmaß von Angriffen dramatisch, wenn das Identitätsdesign mangelhaft ist.

Curity arbeitet seit langem mit Standards wie OAuth und OpenID Connect. Wie wichtig sind offene Identitätsstandards für die Interoperabilität und Sicherheit von agentenbasierter KI in komplexen Unternehmensumgebungen?

Offene Standards sind absolut unerlässlich. Unternehmen betreiben bereits komplexe Identitätsarchitekturen, die Cloud-Plattformen, SaaS-Dienste und interne APIs umfassen. Agentische KI erhöht die Komplexität nur noch weiter.

Ohne Standards wird jeder Agent zu einer eigenen Integration und einer permanenten Sicherheitslücke. Mit Standards wie OAuth und OpenID Connect lassen sich Agenten wie jede andere Arbeitslast authentifizieren, autorisieren und prüfen. Nur so ist eine sichere Skalierung in realen Unternehmensumgebungen möglich.

Nicht-menschliche Identitäten werden immer häufiger, von Servicekonten bis hin zu Maschinenidentitäten. Was unterscheidet KI-Agenten aus Sicherheitssicht grundlegend von früheren nicht-menschlichen Identitäten?

Der entscheidende Unterschied zwischen modernen KI-Agenten und älteren nicht-menschlichen Identitäten (NHIs) liegt in ihrer Autonomie. Ein herkömmlicher Dienstaccount führt exakt die Anweisungen seines Codes aus und ist strikt an seine Aufgabe gebunden. Ein KI-Agent hingegen interpretiert Anweisungen, passt sein Verhalten an und führt Aktionen aus, die nie explizit programmiert wurden – was das Gefahrenpotenzial erhöht, wenn keine angemessenen Schutzmechanismen vorhanden sind.

Ein kleiner Fehler bei der Identitäts- oder Zugriffsverwaltung kann schnell zu einer Katastrophe führen, da ein Angreifer blitzschnell und systemübergreifend agieren kann. Aus Sicherheitssicht stellt dies ein erhebliches Risiko dar.

Wie wichtig sind Prüfprotokolle und identitätsbasierte Protokollierung für die Steuerung agentenbasierter KI, insbesondere in regulierten Branchen?

Audit-Trails sollten kein optionales Extra sein, sondern von Anfang an integriert werden. In regulierten Umgebungen wird von Organisationen erwartet, dass sie einfache, aber entscheidende Fragen beantworten: Worauf hat dieser Agent zugegriffen, wann geschah dies und wer hat es autorisiert?

Identitätsbasierte Protokollierung ist die einzige zuverlässige Methode, um diese Transparenz und Nachvollziehbarkeit zu gewährleisten. Sie spielt auch eine Schlüsselrolle bei der Reaktion auf Sicherheitsvorfälle. Ohne einen klaren Identitätskontext ist es nahezu unmöglich festzustellen, ob ein Problem durch einen fehlerhaften Agenten, eine kompromittierte Identität oder lediglich eine fehlerhafte Eingabeaufforderung verursacht wurde.

Welche realen Risiken sehen Sie entstehen, wenn Unternehmen überprivilegierte oder schlecht überwachte KI-Agenten in der Produktion einsetzen?

Ein häufiges Risiko ist die stille Datenaggregation. Ein überprivilegierter Agent kann sensible Informationen aus verschiedenen Systemen (Kundendatensätze, interne Dokumente, Protokolle) abrufen und diese Daten anschließend über Eingabeaufforderungen, Zusammenfassungen oder externe Integrationen offenlegen.

Ein weiteres Risiko besteht darin, dass Agenten mit Administratorrechten in Windeseile gravierende Änderungen vornehmen und so in kurzer Zeit weitaus größeren Schaden anrichten können, als es ein Mensch je könnte. Dies kann die Modifizierung von Cloud-Ressourcen, die Deaktivierung von Sicherheitskontrollen oder das Auslösen automatisierter Arbeitsabläufe ohne Aufsicht umfassen.

Diese Vorfälle können böswillig sein, müssen es aber nicht. Ein übermäßig privilegierter oder schlecht überwachter Agent könnte einfach mit veralteten oder falschen Annahmen arbeiten und so Fehler in mehreren Systemen verstärken, bevor es jemand bemerkt.

Aus der Sicht eines Angreifers ist eine kompromittierte Agentenidentität jedoch äußerst wertvoll. Sie ermöglicht die laterale Bewegung über APIs und Dienste hinweg, oft mit Zugriffsrechten, die keinem menschlichen Benutzer jemals gewährt würden. Ohne strenge Identitätskontrollen und -überwachung entdecken Unternehmen diese Schwachstellen oft erst, nachdem bereits erheblicher Schaden entstanden ist.

Welche Entscheidungen bezüglich Identität und Zugriff sollten Unternehmen, die von Pilotprojekten zu realen agentenbasierten Implementierungen übergehen, frühzeitig treffen, um spätere kostspielige Neugestaltungen zu vermeiden?

Organisationen sollten frühzeitig festlegen, wie Agenten Identitäten zugewiesen bekommen, wie Berechtigungen erteilt werden und wie der Zugriff im Laufe der Zeit überprüft wird, und dabei die Grenzen der Identität im Voraus definieren.

Die nachträgliche Einführung von Identitätskontrollen ist fast immer problematisch. Mitarbeiter sind oft tief in Arbeitsabläufe eingebunden und nutzen gemeinsame Anmeldeinformationen oder weitreichende Rollen. Eine nachträgliche Verschärfung der Zugriffsrechte verletzt daher die Systemgrundlagen. Dies führt letztendlich zum Scheitern von Arbeitsabläufen und untergräbt das Vertrauen in die Technologie. Es ist wesentlich kostengünstiger und vor allem sicherer, von Anfang an geeignete Identitäten, Berechtigungen und Zugriffsgrenzen zu definieren.

Wo stellt die Identitätsintegration bei der Einführung agentenbasierter KI am häufigsten einen Engpass dar, und welche Best Practices tragen zur Verringerung dieser Reibungsverluste bei?

Identitätsmanagement kann zum Engpass werden, aber nur dann, wenn es vernachlässigt wird. Teams konzentrieren sich zunächst auf die Entwicklung beeindruckender Agentenfunktionen, nur um später festzustellen, dass diese für echte Sicherheit in IAM-Systeme, API-Gateways und Protokollierungsplattformen integriert werden müssen.

Der beste Ansatz besteht darin, zunächst ein klares Verständnis und die korrekte Implementierung von Identitätsplattformen zu entwickeln und anschließend Agenten zu entwerfen, die sich nahtlos in diese Plattformen einfügen. Organisationen sollten bestehende Standards und Infrastrukturen wiederverwenden, anstatt sie zu umgehen; ein solcher Kompromiss führt unweigerlich zu späteren Problemen. Wenn Identität von Anfang an integriert wird, beschleunigt dies die Bereitstellung, anstatt sie zu verlangsamen.

Welchen Rat würden Sie Sicherheits- und Engineering-Leitern geben, die agentenbasierte KI einsetzen möchten, aber Bedenken hinsichtlich Governance und Risiko haben, wenn sie ihre Roadmap planen?

Nehmen Sie sich ausreichend Zeit, um die Grundlagen zu schaffen. KI-Agenten müssen als eigenständige Personen behandelt werden. Daher müssen Sie dieselben Governance-Richtlinien anwenden wie für Menschen und von Anfang an auf Transparenz bestehen. Wenn ein Unternehmen dies beachtet, wird die Skalierung von KI-Agenten zu einer Frage der Sicherheit und nicht zu einem blinden und riskanten Vertrauensvorschuss.

Vielen Dank für das tolle Interview, Leser, die mehr erfahren möchten, sollten vorbeischauen Neugier.