Jacob Ideskog, CTO von Curity – Interview-Serie

Jacob Ideskog ist ein Identity-Spezialist und CTO bei Curity. Den größten Teil seiner Zeit verbringt er damit, an Sicherheitslösungen im API- und Web-Bereich zu arbeiten. Er hat Erfahrungen bei der Konzeption und Implementierung von OAuth- und OpenID-Connect-Lösungen für große Unternehmensbereitstellungen sowie für kleine Start-ups gesammelt.

Curity ist eine moderne Identity- und Access-Management-Plattform (IAM), die auf dem Curity Identity Server basiert, einer standardsbasierten Lösung, die für die Sicherung von Authentifizierung und Autorisierung für Anwendungen, APIs und digitale Dienste im großen Maßstab konzipiert ist. Sie unterstützt Protokolle wie OAuth 2.0 und OpenID Connect, um Login-Flows zu zentralisieren, fein granulierte Zugriffsrichtlinien durchzusetzen und sichere Token für menschliche Benutzer und Maschinenclients, einschließlich APIs und Diensten, auszustellen. Die Plattform ist für Flexibilität und Skalierbarkeit konzipiert und ermöglicht es Organisationen, sie in Cloud-, Hybrid- oder On-Premises-Umgebungen bereitzustellen, in bestehende Systeme zu integrieren und sichere, nahtlose Benutzererfahrungen ohne auf maßgeschneiderte Sicherheitsinfrastrukturen zurückzugreifen, bereitzustellen.

Sie haben einen großen Teil Ihrer Karriere damit verbracht, Identitäts- und API-Sicherheitssysteme aufzubauen, von der Mitgründung von Curity bis hin zur Leitung als CTO während des Aufstiegs von Cloud und jetzt KI. Wie hat diese Reise Ihre Ansicht geprägt, dass KI-Agents als erste Klasse digitale Identitäten und nicht nur als weitere Software behandelt werden sollten?

Über alle Technologiebereiche, in denen ich gearbeitet habe, taucht ein Problem immer wieder auf. Ob es sich um Cloud-Computing oder jetzt KI handelt, wenn Software im Namen einer Person oder eines anderen Systems handelt, haben Sie ein Identitätsproblem.

Die massive Adoption von agenter KI verschärft dieses Problem. Ihr Verhalten ist nicht mehr streng skriptgesteuert, und sie operieren mit einem Grad an Autonomie, den Unternehmen noch nie zuvor gesehen haben. KI-Agents treffen Entscheidungen, rufen APIs auf und ketten Aktionen über Systeme hinweg – oft ohne direkte menschliche Aufsicht. Dieses Verhalten schafft Identitäts- und Zugriffsprobleme, die sich grundlegend von traditioneller Software unterscheiden.

Die Behandlung von KI-Agents als erste Klasse digitale Identitäten ist der einzige Weg, um dies ordnungsgemäß anzugehen. Wenn Organisationen sie als nur einen weiteren Prozess oder Dienstkonten behandeln, verlieren sie schnell die Sichtbarkeit und Kontrolle – und das ist ein Rezept für eine Sicherheitskrise.

Viele Unternehmen sind von agenter KI begeistert, aber stecken noch in der Experimentierphase fest. Was sind aus Ihrer Sicht die häufigsten Identitäts- und Governance-Lücken, die Organisationen daran hindern, Agents sicher zu skalieren?

Die meisten Experimente finden in isolierten Sandboxes statt, die ignorieren, was bei der Skalierung passiert. Während der frühen Pilotphasen geben Teams Agents oft breite API-Schlüssel, gemeinsam genutzte Anmeldeinformationen oder umfassende Cloud-Berechtigungen, nur um loszulegen.

Dieser Ansatz bricht zusammen, sobald Agents über Pilotprojekte hinaus bereitgestellt werden. Denn Sicherheitsteams können nicht sehen, auf welche Daten ein Agent zugreift, welche Aktionen er ausführt oder ob er seine beabsichtigte Reichweite überschritten hat – versehentlich oder böswillig. Diese blinden Flecken machen es unmöglich, Agents sicher zu regieren, was der Grund dafür ist, warum viele Organisationen Schwierigkeiten haben, über Pilotprojekte hinauszukommen.

Sie haben argumentiert, dass strenge Sicherheitsvorkehrungen für agente KI unerlässlich sind. Was sieht “gute” Identitätsdesign für KI-Agents in der Praxis aus, und wo machen Unternehmen typischerweise Fehler?

Gutes Identitätsdesign beginnt mit dem Prinzip der geringsten Privilegien und Berechtigungen, die an explizite Absichten gebunden sind. Jeder KI-Agent sollte seine eigene Identität haben, eng umschriebene Berechtigungen und klar definierte Vertrauensbeziehungen (explizite Regeln, mit welchen Systemen er interagieren darf). Grundlegend sollte der Zugriff zweckgebunden, zeitlich begrenzt und leicht widerrufbar sein.

Wo Unternehmen dies falsch machen, ist, wenn sie bestehende Dienstkonten wiederverwenden oder annehmen, dass interne Agents per Definition sicher sind. Diese Annahme hält nicht gegenüber realen Bedrohungen stand. Böswillige Akteure suchen aktiv nach genau diesen schwachen Stellen, und KI-Agents erhöhen das potenzielle Schadensausmaß dramatisch, wenn das Identitätsdesign schlampig ist.

Curity hat lange mit Standards wie OAuth und OpenID Connect gearbeitet. Wie kritisch sind offene Identitätsstandards für die Erreichung der Interoperabilität und Sicherheit von agenter KI in komplexen Unternehmensumgebungen?

Offene Standards sind absolut kritisch. Unternehmen betreiben bereits komplexe Identitätsstrukturen, die Cloud-Plattformen, SaaS-Dienste und interne APIs umspannen. Agente KI fügen nur mehr Komplexität hinzu.

Ohne Standards wird jeder Agent zu einer eigenen Integration und einer permanenten Sicherheitsausnahme. Mit Standards wie OAuth und OpenID Connect können Agents authentifiziert, autorisiert und auditiert werden, genau wie jede andere Workload. Dies ist der einzige Ansatz, der eine sichere Skalierung über reale Unternehmensumgebungen hinweg ermöglichen kann.

Nicht-menschliche Identitäten werden immer häufiger, von Dienstkonten bis hin zu Maschinenidentitäten. Was macht KI-Agents im Hinblick auf die Sicherheit grundlegend anders als vorherige nicht-menschliche Identitäten?

Der Schlüsselunterschied zwischen modernen KI-Agents und älteren nicht-menschlichen Identitäten (NHIs) liegt in der Autonomie. Ein traditionelles Dienstkonto tut genau das, was sein Code ihm sagt, streng an seine Aufgabe gebunden. Ein KI-Agent interpretiert Anweisungen, passt sein Verhalten an und nimmt Aktionen, die nie explizit skriptgesteuert wurden – was das potenzielle Gefahr erhöht, wenn es keine angemessenen Sicherheitsvorkehrungen gibt.

Ein kleiner Identitäts- oder Zugriffsfehler kann schnell zu einer Katastrophe werden, da ein Agent schnell und über mehrere Systeme hinweg handeln kann. Aus Sicherheitssicht stellt dies ein großes Risiko dar.

Wie wichtig sind Audit-Protokolle und identitätsbasiertes Logging für die Regulierung von agenter KI, insbesondere in regulierten Branchen?

Audit-Protokolle sollten kein “nice to have” sein. Sie müssen von Anfang an implementiert werden. In regulierten Umgebungen werden Organisationen erwartet, einfache aber kritische Fragen zu beantworten: Was hat dieser Agent zugänglich gemacht, wann ist es passiert und wer hat es autorisiert?

Identitätsbasiertes Logging ist der einzige zuverlässige Weg, um diese Art von Rechenschaftspflicht zu erhalten. Es spielt auch eine wichtige Rolle bei der Reaktion auf Vorfälle. Ohne klaren Identitätskontext ist es fast unmöglich zu wissen, ob ein Problem von einem fehlverhaltenden Agent, einer kompromittierten Identität oder einfach einem schlechten Prompt stammt.

Welche realen Risiken sehen Sie entstehen, wenn Organisationen über-privilegierte oder schlecht überwachte KI-Agents in der Produktion bereitstellen?

Ein häufiges Risiko ist die stille Datenaggregation. Ein über-privilegierter Agent kann sensible Informationen aus mehreren Systemen (Kundendaten, interne Dokumente, Protokolle) sammeln und diese Daten dann durch Prompts, Zusammenfassungen oder externe Integrationen offenlegen.

Ein weiteres Risiko ist, dass Agents mit administrativen Zugriffsrechten große Änderungen mit Maschinengeschwindigkeit vornehmen, was weit mehr Schaden anrichten kann als ein Mensch in kurzer Zeit. Dies kann die Änderung von Cloud-Ressourcen, die Deaktivierung von Sicherheitskontrollen oder das Auslösen automatisierter Workflows ohne Aufsicht umfassen.

Diese Vorfälle müssen nicht böswillig sein. Ein über-privilegierter oder schlecht überwachter Agent könnte einfach auf veralteten oder falschen Annahmen operieren und Fehler über mehrere Systeme hinweg vergrößern, bevor jemand es bemerkt.

Aber aus der Sicht eines Angreifers ist eine kompromittierte Agenten-Identität extrem wertvoll. Sie ermöglicht laterale Bewegung über APIs und Dienste, oft mit einem Zugriff, den kein menschlicher Benutzer jemals erhalten würde. Ohne starke Identitätskontrollen und Überwachung entdecken Organisationen diese Ausfälle oft erst, nachdem realer Schaden angerichtet wurde.

Für Unternehmen, die von Pilotprojekten zu realen agenter KI-Bereitstellungen übergehen, welche Identitäts- und Zugriffsentscheidungen sollten frühzeitig getroffen werden, um teure Neukonzeptionen später zu vermeiden?

Organisationen sollten frühzeitig entscheiden, wie Agents Identitäten erhalten, wie Berechtigungen genehmigt und wie der Zugriff über die Zeit hinweg überprüft wird, indem sie Identitätsgrenzen im Voraus definieren.

Die Einführung von Identitätskontrollen nachträglich ist fast immer problematisch. Agents sind oft tief in Workflows eingebettet, die gemeinsam genutzte Anmeldeinformationen oder breite Rollen verwenden, sodass die Einschränkung des Zugriffs nachträglich die Annahmen, auf denen das System basiert, bricht. Dies führt letztendlich dazu, dass Workflows fehlschlagen und das Vertrauen in die Technologie untergräbt. Es ist viel billiger, nicht zu erwähnen sicherer, ordnungsgemäße Identitäten, Berechtigungen und Zugriffsgrenzen von Anfang an zu konzipieren.

Wo wird die Identitätsintegration am häufigsten zu einem Engpass, wenn agente KI bereitgestellt wird, und welche Best Practices helfen, Reibungsverluste zu reduzieren?

Die Identitätsverwaltung kann zu einem Engpass werden, aber nur, wenn sie als Nachgedanke behandelt wird. Teams konzentrieren sich darauf, beeindruckende Agentenfähigkeiten aufzubauen, nur um später zu realisieren, dass sie in IAM-Systeme, API-Gateways und Logging-Plattformen integriert werden müssen, um wirklich sicher zu sein.

Der beste Ansatz ist, mit einem klaren Verständnis und einer ordnungsgemäßen Implementierung von Identitätsplattformen zu beginnen und dann Agents zu entwerfen, die in diese Plattformen passen. Organisationen sollten bestehende Standards und Infrastrukturen wiederverwenden, anstatt sie zu umgehen; das Umgehen dieser Ecke wird unweigerlich zu Problemen führen. Wenn die Identität von Anfang an implementiert wird, beschleunigt sie die Bereitstellung, anstatt sie zu verlangsamen.

Für Sicherheits- und Engineering-Führungskräfte, die agente KI umarmen möchten, aber Bedenken hinsichtlich der Regulierung und des Risikos haben, welche Ratschläge würden Sie geben, während sie ihre Roadmap planen?

Langsam genug abbremsen, um die Grundlagen richtig zu machen. KI-Agents müssen als Identitäten behandelt werden, und so müssen Sie die gleiche Regulierung anwenden, die Sie für Menschen erwarten, und von Anfang an auf Sichtbarkeit bestehen. Wenn eine Organisation das tut, dann wird die Skalierung von agenter KI zu einer Sicherheitsübung und nicht zu einem blinden und riskanten Sprung des Glaubens.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Curity besuchen.