Identity & Access Management liefert das vollständige Leistungsspektrum, das ein Unternehmen von einer zentralen Zugriffsinstanz erwartet. Es stellt Benutzerkonten bereit und verwaltet sie, hält Profildetails, Kontaktinformationen und Kontostatus vor und unterscheidet klar zwischen der administrativen Verwaltung eines beliebigen Kontos und der Selbstbedienungspflege des eigenen Profils. Die Authentifizierung erfolgt anmeldedatenbasiert mit starkem Passwort-Hashing, ergänzt durch eine zeitbasierte Zwei-Faktor-Authentifizierung und einen Satz einmalig verwendbarer Wiederherstellungscodes, die verschlüsselt aufbewahrt werden, für den Fall, dass ein zweiter Faktor verloren geht.

Über den Anmeldezeitpunkt hinaus führt das Modul eine Live-Sitzungssteuerung, sodass aktive Sitzungen sichtbar, einem Principal zurechenbar, durch einen Ablaufzeitpunkt begrenzt und einzeln widerrufbar sind. Die Autorisierung wird über benannte Rollen ausgedrückt, die fein granulierte Berechtigungen tragen, und diese Berechtigungen reichen bis in jedes Subjekt, das die Plattform bereitstellt. Single Sign-on steht über Identity-Provider-Konnektoren zur Verfügung und erlaubt der Organisation, die Authentifizierung an ihr bestehendes Verzeichnis zu föderieren, während Autorisierungsentscheidungen innerhalb der Suite verbleiben. Die Rollen- und Berechtigungsverwaltung ist Teil dieses Moduls und gibt Administratoren einen einzigen Ort, um festzulegen, was jede Benutzerklasse tun darf.

Im Zentrum der Domäne steht der Principal: ein verifizierter Akteur auf der Plattform, ob namentlich benannter Mitarbeiter oder AI Worker, mit einer eindeutigen Identität, Kontaktdaten und einem Kontostatus, der bestimmt, ob er überhaupt handeln darf. Jeder Principal ist an genau eine Rolle gebunden, und es ist die Rolle, nicht die einzelne Person, die Berechtigungen trägt. Diese bewusste Trennung hält Zugriffsentscheidungen konsistent und prüfbar: Ändert man eine Rolle, so bewegt sich jeder Principal, der sie innehat, gemeinsam mit, statt in ein Flickwerk individueller Ausnahmen abzudriften.

Eine Rolle wird durch ihren Berechtigungssatz definiert, einen strukturierten Ausdruck dessen, welche Aktionen die Rolle gegenüber welchen Teilen der Plattform ausführen darf. Aktionen wie Lesen, Erstellen, Aktualisieren, Löschen und Zugreifen werden mit den fachlichen Subjekten gepaart, auf die sie sich beziehen, und die Plattform kennt Subjekte für jeden funktionalen Bereich, den sie abdeckt. Die integrierten Rollen reichen von einem uneingeschränkten Administrator über fachliche und technische Manager bis zu einem reinen Lese-Standardbenutzer, und diese grundlegenden Rollen sind vor dem Löschen geschützt, damit das System stets eine kohärente Ausgangsbasis behält. Das letzte Konzept ist die Sitzung, der Nachweis der authentifizierten Präsenz eines Principals, der ein eigenes Token, seinen Inhaber und seinen Ablaufzeitpunkt trägt. Zusammen beschreiben diese vier Begriffe sauber und vollständig, wer jemand ist, was er tun darf und ob er aktuell angemeldet ist.

Der häufigste Workflow ist die Bereitstellung. Ein Administrator erstellt ein Konto, legt dessen anfängliches Profil fest und weist eine Rolle zu, und der neue Principal unterliegt sofort den Berechtigungen dieser Rolle, ohne weitere Konfiguration. Passwortzurücksetzungen folgen demselben administrativen Weg, während gewöhnliche Benutzer ihr eigenes Profil pflegen und ihren zweiten Faktor per Selbstbedienung einrichten. Die Zwei-Faktor-Einrichtung koppelt eine Authenticator-App mit dem Konto und stellt Wiederherstellungscodes aus, und der Kontoinhaber kann diese Codes neu erzeugen oder den Faktor neu konfigurieren, wenn sich die Umstände ändern.

Die Zugriffsüberprüfung ist ein eigenständiger Workflow. Administratoren prüfen, wer welche Rolle innehat, passen den Berechtigungssatz einer Rolle über einen Editor an, der Subjekte unter ihrem zugehörigen Modul gruppiert, und sehen, wie diese Änderungen plattformweit wirksam werden, ohne dass etwas neu bereitgestellt werden muss. Die Sitzungsaufsicht erlaubt einem Administrator, aktive Sitzungen einzusehen und alle zu widerrufen, die nicht länger bestehen sollen, was die unmittelbare Reaktion auf ein verlorenes Gerät oder einen ausscheidenden Mitarbeiter darstellt. Die Deaktivierung schließt den Kreis: Ein Konto kann deaktiviert werden, sodass es seine Historie und seinen Prüfpfad behält, aber die Fähigkeit zur Authentifizierung verliert, wodurch der Nachweis erhalten bleibt, ohne den Zugriff zu erhalten.

Das Autorisierungsmodell ist attributbasiert und keine grobe Liste von Privilegien. Berechtigungen werden als explizite Regeln geführt, die eine Aktion mit einem Subjekt paaren, und die Plattform trägt ein reichhaltiges Register von Subjekten über jedes Modul hinweg, sodass Berechtigungen so umfassend wie die vollständige Kontrolle über einen funktionalen Bereich oder so eng wie die reine Lesesicht auf ein einzelnes Subjekt sein können. Diese Granularität ist es, die einem technischen Manager und einem fachlichen Manager ein Nebeneinander erlaubt, jeder mit Autorität über seine eigene Domäne und reiner Lesesicht auf die des anderen. Wenn sich ein Principal authentifiziert, wird der wirksame Berechtigungssatz aufgelöst und in einem signierten Token getragen, und dieses Token wird in einem kurzen Zyklus erneuert, sodass sich eine Rollenänderung innerhalb von Minuten auf laufende Sitzungen fortpflanzt, statt bis zur nächsten Anmeldung fortzubestehen.

Das Modul ist auf etablierte Sicherheitskontrollen ausgelegt. Anmeldedaten werden niemals im Klartext gespeichert, Wiederherstellungsmaterial wird ruhend verschlüsselt, und Sitzungscookies werden mit den schützenden Flags ausgestellt, die einen clientseitigen Zugriff und eine seitenübergreifende Übertragung verhindern. Die Anmeldung wird ratenbegrenzt, um Brute-Force-Versuche abzustumpfen, und jede Zugriffsentscheidung wird an der Schnittstellengrenze durchgesetzt, sodass eine Berechtigungsprüfung nicht durch den direkten Aufruf einer Operation umgangen werden kann. Da dasselbe Durchsetzungstor sowohl den interaktiven Gebrauch als auch den programmatischen Zugriff abdeckt, gelten die Garantien unabhängig davon, ob eine Anfrage von einem Browser, einer Integration oder einem autonomen Agenten eintrifft.

Identity & Access Management ist die Abhängigkeit, die jedes andere Modul teilt. Es arbeitet Hand in Hand mit dem Security Management, das die Sicherheitslage der Plattform prüft und das Zugriffsmodell heranzieht, wenn es über Angriffsflächen nachdenkt, sowie mit dem Privacy Management und dem Compliance Management, die sich darauf verlassen, um nachzuweisen, dass der Zugriff auf personenbezogene und regulierte Daten auf berechtigte Principals beschränkt ist. Das Connector Management liefert die Identity-Provider-Integrationen, die Single Sign-on möglich machen, indem sie die Authentifizierung an das Verzeichnis der Organisation föderieren. Die Notification Engine trägt die sicherheitsrelevanten Ereignisse, die dieses Modul auslöst, etwa eine neue Sitzung oder eine Rollenänderung, zu den Personen, die sie sehen müssen.

Jedes Fachmodul, von Accounting & Control über Marketing & Sales, Fleet Management, Human Resource Management bis zur Wissensdatenbank, drückt seine eigenen Zugriffsregeln als Subjekte innerhalb des Berechtigungsmodells dieses Moduls aus, sodass es eine einzige Instanz und ein einziges Vokabular für Berechtigungen über die gesamte Suite hinweg gibt. Das Module Management und der weiter gefasste Bereich der System Administration behandeln Identität als das Substrat, auf dem jede administrative Tätigkeit autorisiert wird.

AI Workers sind hier Principals wie jeder andere, bereitgestellt mit ihrer eigenen Identität, an eine Rolle gebunden und durch genau die Berechtigungen eingeschränkt, die diese Rolle gewährt, was bedeutet, dass ein Agent niemals über die ihm verliehene Autorität hinaus handeln kann. Im Gespräch kann ein Administrator einen AI Worker bitten zu berichten, wer eine bestimmte Rolle innehat, welche Konten über Zwei-Faktor verfügen oder welche Sitzungen aktuell aktiv sind, und der Worker antwortet, indem er die eigenen Daten des Moduls abfragt. Bei entsprechender Berechtigung führt er auch Aktionen aus: das Bereitstellen eines Kontos, das Zuweisen oder Anpassen einer Rolle, das Zurücksetzen einer Anmeldeinformation oder das Widerrufen einer Sitzung auf Anfrage.

Die Workers beobachten ebenso, wie sie handeln. Sie machen Anomalien und Ausnahmen sichtbar, kennzeichnen Konten, denen ein zweiter Faktor fehlt, Sitzungen, die sich ungewöhnlich verhalten, oder Rollen, deren Berechtigungen von der Richtlinie abgedriftet sind, und melden diese über den Benachrichtigungspfad zur menschlichen Aufmerksamkeit. Sie extrahieren Struktur aus unterstützenden Dokumenten und verwandeln eine Liste von Zu- und Abgängen oder ein Zugriffsanforderungsformular in konkrete Vorschläge zur Bereitstellung und Deprovisionierung, und sie bieten Entscheidungsunterstützung, wenn eine Rollenänderung erwogen wird, indem sie erläutern, was ein bestimmter Berechtigungssatz erlauben würde. Am wichtigsten ist, dass ein AI Worker als Freigabe- oder Prüfknoten in einem Zugriffs-Workflow stehen kann, sodass eine sensible Rollenzuweisung oder eine privilegierte Bereitstellungsanforderung für seine Prüfung pausiert, wobei jede Beurteilung im Prüfpfad gegen die eigene Identität des Workers festgehalten wird.