SSO & SCIM: Griffin AI vs Mythos

Identity is the unglamorous center of enterprise software. Every access decision, every audit log entry, every compliance control, and every incident investigation eventually traces back to the question of who was logged in and what they were entitled to do. For a security AI platform that reads sensitive data and takes consequential actions, getting identity right is not a checkbox. It is the foundation.

Griffin AI inside Safeguard treats SSO and SCIM as default capabilities available on every tier. Mythos-class pure-LLM competitors frequently treat them as enterprise upsells or as partial implementations that satisfy a procurement form without satisfying an identity team. This piece walks through what good looks like, where the gaps tend to open, and why the identity story is a reliable signal of overall enterprise seriousness.

The two halves of enterprise identity

Enterprise identity for a SaaS or on-prem product breaks cleanly into two concerns:

• Authentication. Users prove who they are using the customer's identity provider. The practical standard is SAML 2.0 or OpenID Connect, federated against Okta, Entra ID, Ping, Google Workspace, or a customer-hosted IdP such as Keycloak or ADFS.
• Lifecycle. Users, groups, and entitlements are provisioned and deprovisioned automatically as their status in the source-of-truth directory changes. The practical standard is SCIM 2.0, which lets the IdP push changes rather than requiring the application to poll.

Both halves are necessary. SSO without SCIM leaves a trail of stale accounts that outlive the employees attached to them. SCIM without SSO creates a provisioning pipeline for credentials that cannot be rotated centrally. A credible enterprise product does both, on every tier, without a special contract.

What Mythos-class vendors typically ship

Pure-LLM security assistants often reach general availability with a permissive auth model designed for rapid adoption: email magic links, Google sign-in, or a single-tenant OAuth app. SSO is added later, usually as an "Enterprise" tier feature priced to recover the engineering cost.

The common shortfalls follow a pattern:

• SSO is paywalled. Customers who pay for security software are asked to pay again for the ability to enforce their own identity policy. This is a well-known anti-pattern and it reliably signals a product that was not designed with enterprise buyers in mind.
• SCIM is partial. Many vendors implement enough SCIM to satisfy an Okta app directory listing but not enough to handle edge cases: group changes, nested groups, deactivation versus deletion, or attribute synchronization. The result is a provisioning pipeline that works on the demo and breaks on the tenth user change.
• Just-in-time provisioning is over-eager. Some products auto-create accounts on first SSO login without honoring group-based entitlements, producing a pool of unexpected users with unexpected access.
• Role mapping is ad hoc. IdP group claims are ignored, or mapped through a brittle UI that only administrators can edit. Moving a user between roles requires a manual change inside the product rather than a change in the directory.
• Session and token lifetimes drift. The product's session does not follow the IdP's session, so revoking a user in the directory leaves an active session alive for hours.

Any one of these issues is survivable. Stacked together, they produce an identity posture that looks fine in a procurement spreadsheet and fails in an audit.

How Safeguard and Griffin AI handle it

Safeguard ships SSO and SCIM as standard features, in every tier, with the same fidelity across SaaS, on-prem, and air-gapped deployments. The design follows a few principles:

• One identity model across the product. Griffin AI, the Safeguard UI, the APIs, and the MCP integrations all resolve identity through the same authentication layer. A role grant in the directory becomes an access decision in Griffin AI without a separate configuration surface.
• SAML 2.0 and OIDC as peers. Customers choose the protocol that matches their IdP. Both are first-class, with metadata-driven configuration, signed assertions, encrypted attributes, and IdP-initiated or SP-initiated flows.
• Full SCIM 2.0. Users, groups, and group memberships sync bidirectionally. Deactivation flips the user into a reversible state that preserves audit history; deletion is supported separately for customers with retention policies that require it.
• Group-to-role mapping as code. Role assignments are driven by group claims and documented in configuration, not clicked into a UI. This makes them auditable and reviewable through the customer's change management process.
• Session lifetime honors the IdP. When the directory revokes a user, Safeguard terminates active sessions within seconds, and Griffin AI's in-flight requests fail closed.

Why this matters for a security AI

An AI that reads your SBOMs, opens your source repositories, drafts your Jira tickets, and proposes remediations is an AI with a lot of reach. Every one of those actions needs to be attributable to a specific human, scoped by that human's entitlements, and revocable the instant their status changes.

Griffin AI inherits Safeguard's identity model directly. A Griffin AI conversation belongs to a user. A tool call made by Griffin AI runs under that user's permissions, not a shared service account. An audit log entry carries the user's identity, the group claims in effect at the time, and the trace ID that links the action to the original request. Deprovisioning a user in the IdP immediately revokes Griffin AI's ability to act on their behalf.

Mythos-class vendors, because they often layer the assistant on top of a separately owned identity system, struggle to carry identity through to the AI tier with the same fidelity. Tool calls run under service accounts. Audit logs show "Mythos" as the actor. Conversation history outlives the user. These are not theoretical problems; they are the first three findings of every serious audit.

SCIM is the quiet part

SSO gets the marketing attention. SCIM is where the operational reality lives. An identity team managing ten thousand employees across a dozen contractor agreements cannot tolerate manual provisioning. They need the directory to be the source of truth and the application to be a faithful consumer of it.

Safeguard's SCIM implementation has been hardened against the real edge cases: rapid group membership churn, users who appear in multiple relevant groups, transient IdP failures, and directory migrations. The provisioning flow is idempotent, and the system exposes a reconciliation endpoint so that operators can detect and correct any drift.

What to verify in a procurement evaluation

A short test covers most of the gap between vendors that do identity seriously and vendors that do it as marketing:

• Is SSO available on every paid tier, with no upcharge?
• Is SCIM 2.0 supported for both user and group provisioning?
• Do role assignments come from IdP group claims, by default?
• Does user deactivation in the IdP terminate active sessions quickly and revoke tool-call capability?
• Do audit logs record the user identity for every AI action, including tool invocations?
• Does the product support on-prem IdPs such as ADFS and Keycloak with equal fidelity to cloud IdPs?

Safeguard answers yes to each. Mythos-class competitors frequently answer no to two or three, and those are the ones that matter most when the auditor shows up.

Closing

Enterprise identity is not glamorous, but it is decisive. A security AI platform that gets identity right gives its customers a straight line from their directory to their audit log. A platform that gets it wrong forces customers to paper over the gaps with process, which works until it does not. Griffin AI inside Safeguard is built on the first model. For any organization whose identity team will be involved in the decision, that is the detail that ends most comparisons early.