Identity & Access Management delivers the complete set of capabilities an enterprise expects from a central access authority. It provisions and manages user accounts, holding profile details, contact information and account state, and it distinguishes clearly between administrative management of any account and self-service editing of one's own profile. Authentication is credential-based with strong password hashing, augmented by time-based two-factor authentication and a set of single-use recovery codes held under encryption for the case where a second factor is lost.

Beyond the point of sign-in, the module maintains live session control, so that active sessions are visible, attributable to a principal, bounded by expiry and individually revocable. Authorisation is expressed through named roles that carry fine-grained permissions, and those permissions reach into every subject the platform exposes. Single sign-on is available through identity-provider connectors, allowing the organisation to federate authentication to its existing directory while keeping authorisation decisions local to the suite. Role and permission management is part of this module, giving administrators one place to define what each class of user may do.

At the centre of the domain sits the principal: a verified actor on the platform, whether a named employee or an AI Worker, holding a unique identity, contact details and an account state that determines whether it may act at all. Each principal is bound to exactly one role, and it is the role, not the individual, that carries entitlements. This deliberate separation keeps access decisions consistent and auditable: change a role and every principal who holds it moves together, rather than drifting into a patchwork of individual exceptions.

A role is defined by its permission set, a structured expression of which actions the role may take against which parts of the platform. Actions such as reading, creating, updating, deleting and accessing are paired with the business subjects they apply to, and the platform recognises subjects for every functional area it covers. Built-in roles range from an unrestricted administrator through functional and technical managers to a read-only standard user, and these foundational roles are protected from deletion so the system always retains a coherent baseline. The final concept is the session, the record of a principal's authenticated presence, carrying its own token, its owner and its expiry. Together these four ideas describe, cleanly and completely, who someone is, what they may do, and whether they are currently signed in.

The most frequent workflow is provisioning. An administrator creates an account, sets its initial profile and assigns a role, and the new principal is immediately governed by that role's entitlements without further configuration. Password resets follow the same administrative path, while ordinary users maintain their own profile and enrol their second factor through self-service. Two-factor setup pairs an authenticator application with the account and issues recovery codes, and the account holder can regenerate those codes or reconfigure the factor as circumstances change.

Access review is a workflow in its own right. Administrators inspect who holds which role, adjust a role's permission set through an editor that groups subjects under their owning module, and see those changes take effect across the platform without redeploying anything. Session oversight lets an administrator view active sessions and revoke any that should no longer persist, which is the immediate response to a lost device or a departing employee. Deactivation closes the loop: an account can be disabled so that it retains its history and audit trail while losing the ability to authenticate, preserving the record without preserving the access.

The authorisation model is attribute-based rather than a coarse list of privileges. Permissions are held as explicit rules pairing an action with a subject, and the platform carries a rich registry of subjects spanning every module, so entitlements can be as broad as full control of a functional area or as narrow as read-only visibility of a single subject. This granularity is what allows a technical manager and a functional manager to coexist, each with authority over their own domain and read-only sight of the other. When a principal authenticates, the effective permission set is resolved and carried in a signed token, and that token is refreshed on a short cycle so that a change to a role propagates to serving sessions within minutes rather than lingering until the next sign-in.

The module is built to established security controls. Credentials are never stored in the clear, recovery material is encrypted at rest, and session cookies are issued with the protective flags that prevent client-side access and cross-site transmission. Sign-in is rate-limited to blunt brute-force attempts, and every access decision is enforced at the interface boundary so that a permission check cannot be bypassed by calling an operation directly. Because the same enforcement gate covers both interactive use and programmatic access, the guarantees hold whether a request arrives from a browser, an integration or an autonomous agent.

Identity & Access Management is the dependency every other module shares. It works hand in hand with Security Management, which audits the platform's posture and consumes the access model when reasoning about exposure, and with Privacy Management and Compliance Management, which rely on it to prove that access to personal and regulated data is confined to entitled principals. Connector Management supplies the identity-provider integrations that make single sign-on possible, federating authentication to the organisation's directory. The Notification Engine carries the security-relevant events this module raises, such as a new session or a change of role, to the people who need to see them.

Every business module, from Accounting & Control through Marketing & Sales, Fleet Management, Human Resource Management and the Knowledge Base, expresses its own access rules as subjects within this module's permission model, so there is one authority and one vocabulary for entitlement across the whole suite. Module Management and the wider System Administration area treat identity as the substrate on which all administrative activity is authorised.

AI Workers are principals here like any other, provisioned with their own identity, bound to a role and constrained by exactly the permissions that role grants, which means an agent can never act beyond the authority it has been given. Working conversationally, an administrator can ask an AI Worker to report who holds a particular role, which accounts have two-factor enabled, or which sessions are currently active, and the Worker answers by querying the module's own data. Given the appropriate entitlement, it also executes actions: provisioning an account, assigning or adjusting a role, resetting a credential or revoking a session on request.

The Workers watch as well as act. They surface anomalies and exceptions, flagging accounts that lack a second factor, sessions that behave unusually or roles whose entitlements have drifted from policy, and they raise these through the notification path for human attention. They extract structure from supporting documents, turning a joiners-and-leavers list or an access-request form into concrete provisioning and deprovisioning proposals, and they offer decision support when a role change is contemplated by explaining what a given permission set would allow. Most importantly, an AI Worker can stand as an approval or review node in an access workflow, so a sensitive role assignment or a privileged provisioning request pauses for its scrutiny, with every judgement recorded against the Worker's own identity in the audit trail.