Overview#

AI Workforce OS includes real, implemented security capabilities: multi-factor authentication (TOTP), single sign-on (SAML 2.0 and OIDC), SCIM user provisioning, a tamper-evident audit log, threat protection, and data-protection/GDPR tooling.

Purpose#

Give System/IT Administrators and security/compliance stakeholders a clear, accurate picture of what security controls exist and how to turn them on.

Prerequisites#

  • A System/IT Administrator account.
  • For SSO/SCIM: administrative access to your identity provider (e.g., your SAML or OIDC IdP).

Step-by-Step Instructions#

Multi-factor authentication (MFA)#

  1. Go to Security → MFA and enable enrollment for your organization, or let individual users enroll from their own account settings.
  2. A user scans the enrollment QR code with a TOTP authenticator app (e.g., Google Authenticator, Authy).
  3. The user saves their 10 single-use recovery codes somewhere safe, in case they lose access to their authenticator.
  4. On future logins, the user enters a time-based one-time code from their authenticator app after their password.

Single sign-on (SSO)#

  1. Go to Security → Identity Providers and add your identity provider — SAML 2.0 or OIDC are both supported.
  2. Configure the connection using your IdP’s metadata (SAML) or client credentials (OIDC).
  3. Test the login flow. New users can be just-in-time (JIT) provisioned on first SSO login, depending on configuration.

SCIM user provisioning#

  1. Configure your identity provider to push user provisioning events to AI Workforce OS via SCIM 2.0.
  2. User create/list/update (patch) operations are supported and map onto AI Workforce OS user accounts.
Group provisioning is limited

SCIM Group creation is explicitly out of scope in this release. If your IdP pushes a group, it must match a Role that an administrator has already created by name in AI Workforce OS — SCIM cannot create new roles/groups on the fly.

Audit log#

  1. Go to Audit (in HR Admin or Security) to review the audit log.
  2. Each entry is chained with a rolling SHA-256 hash, so the log is tamper-evident.
  3. Use the chain-verification tool to confirm the log has not been altered, and export audit data for compliance reporting.

Threat protection and data protection#

  1. Threat protection covers brute-force login protection, suspicious-activity detection, tamper detection, bot detection, IP allow/deny rules, and rate-limit policies — review the security alert dashboard for flagged activity.
  2. Data protection covers PII classification/masking, encryption-key management, data retention with automated purge, GDPR data-export requests, and malware scanning on uploaded files.
  3. Compliance tooling covers a controls catalogue, a GDPR register, consent management, risk scoring, incident tracking, evidence collection, and access reviews.

Screens Involved#

📷
[Screenshot: Security dashboard]
📷
[Screenshot: MFA management]
📷
[Screenshot: Identity providers (SSO)]
📷
[Screenshot: Session management]
📷
[Screenshot: Audit log]
📷
[Screenshot: Data requests (GDPR)]
📷
[Screenshot: Threat-protection dashboard]

Expected Results#

Users can enroll in MFA and/or sign in via your corporate SSO, provisioning flows through SCIM as configured, and every sensitive action is recorded in a verifiable audit trail.

Common Mistakes#

  • Assuming SCIM can create new roles/groups automatically — it cannot; a matching Role must already exist by name.
  • Not saving MFA recovery codes, then getting locked out after losing access to an authenticator app.
  • Disabling MFA/SSO enforcement "temporarily" for convenience and forgetting to re-enable it.

Troubleshooting#

A SCIM-provisioned user is not getting the right access.#

Confirm the group name pushed by your IdP exactly matches an existing Role name in AI Workforce OS — SCIM group creation is not supported, so mismatched names silently fail to grant the intended access.

I lost my authenticator device and cannot sign in.#

Use one of your saved MFA recovery codes to sign in, then re-enroll a new authenticator device from Security → MFA. If you did not save recovery codes, contact your System Administrator for account recovery.

I need to prove the audit log has not been tampered with.#

Use the audit log’s chain-verification tool, which reports whether every entry’s hash chain is intact and flags the point of any break.

FAQ#

Is MFA real TOTP, or just an email code?

Real TOTP (time-based one-time passcode) via a standard authenticator app, with encrypted secret storage and single-use recovery codes.

Which SSO protocols are supported?

SAML 2.0 and OIDC, both fully implemented, including just-in-time user provisioning.

Can SCIM create new roles automatically?

No. SCIM Group creation is explicitly out of scope — a matching Role must already exist by name in AI Workforce OS for group-based access to apply correctly.

Is the audit log tamper-proof?

It is tamper-evident: entries are chained with a rolling SHA-256 hash, and a verification tool detects and locates any break in the chain.

Best Practices#

  • Require MFA for all administrator accounts at minimum, even if not yet organization-wide.
  • Pre-create the Roles your IdP will reference before turning on SCIM group provisioning.
  • Run audit-chain verification on a regular schedule, not only when an incident is suspected.