SSO, SCIM and Admin Controls for AI Email Tools

Evaluating SSO and SCIM for AI email tools looks like a normal SaaS identity review until you notice the app is holding a second credential. Single sign-on governs who can open the product; a separate OAuth grant governs whether the product can reach the mailbox. They are revoked in two different places, and only one of them is on the standard checklist.

That gap is the subject of this guide. Most buyer pages stop at "does it support SAML and SCIM" — a yes/no question a vendor can answer honestly while still leaving a departed employee's inbox readable by an agent quietly working through a queue.

The short answer#

A team-grade AI email tool needs six things. Four appear on any SaaS identity checklist. Two exist only because the product contains an agent that acts on its own.

• Enforced SSO — SAML 2.0 or OIDC, with password login disabled for your domain, not merely offered alongside it.
• SCIM with defined deactivation semantics — what happens when your IdP sets a user inactive, not just that the call succeeds.
• Role-based access scoped per mailbox — a role that grants "the team" every connected account is not an access control.
• An admin console that owns policy, not just billing: invites, roles, mailbox scope and revocation in one place.
• An admin-set ceiling on agent autonomy, so one person cannot switch their own agent to autonomous sending.
• An exportable audit log naming the agent as a distinct actor, separate from the human who approved the action.

Why an AI email tool needs a different identity checklist#

Ordinary SaaS has one blast radius: the data inside the product. An AI email client has three. It holds a session, a delegated grant to Gmail or Microsoft 365, and pending work — drafts, scheduled sends, follow-up reminders, rules that fire on a timer. Deactivating the user in your IdP addresses the first only; neither of the others is a property of the user record your IdP writes to.

So two tools can both truthfully claim SCIM support and behave completely differently at offboarding. One treats deactivation as "revoke the session, revoke the mailbox grant, cancel the queue." The other treats it as "hide the seat from the member list." The standard does not choose between them.

The six criteria that actually matter#

Score a vendor on these rather than on the feature list. Each row is a question you can send in an email and get a checkable answer to; a criterion you cannot verify is one the vendor grades itself on.

What SSO and SCIM actually promise — and what they don't#

Microsoft's provisioning documentation lists deprovisioning as a capability distinct from provisioning: "Automatically deactivate accounts in the right systems when people leave the team or organization." That is the value of SCIM over SAML just-in-time provisioning, which creates an account on first sign-in and has no signal at all for departure.

Deletion is equally soft. RFC 7644, which defines the protocol and its /Users and /Groups endpoints, states that "Service providers MAY choose not to permanently delete the resource but MUST return a 404 (Not Found) error code for all operations associated with the previously deleted resource." That 404 is a statement about the SCIM endpoint, not about the mail data.

The offboarding gap most reviews never test#

Here is the test that separates the vendors. It takes about twenty minutes on a trial tenant, and no vendor can talk their way around the result. Run it before the security questionnaire: a questionnaire asks the vendor to describe their behaviour, this asks the product to demonstrate it.

1. 1

   Provision a throwaway user through your IdP

   Create a test account in Okta or Entra ID, assign it to the app, and let SCIM push it through. Confirm the seat appears in the member list.

2. 2

   Give the agent real pending work

   Connect a test mailbox, then leave something queued — a scheduled send, an approved draft, a follow-up reminder dated for tomorrow.

3. 3

   Deactivate the user in the IdP

   Set the user inactive and let the provisioning cycle run. Do not delete them; deactivation is the case that actually happens on a Friday afternoon.

4. 4

   Check all three blast radii

   Can the session still be used? Does the mailbox still show as connected? And the one that matters: did the scheduled send go out at its appointed time?

5. 5

   Check the provider side

   In Google Workspace or Entra ID, open the third-party app access list for that user. If the grant is still there, your runbook needs a manual revocation step.

Scoring table: what each tool publishes#

This is what each vendor documents on its own pages as of August 2026, not what we measured in a lab — we have not run the offboarding test against every product, and saying we had would be the easiest lie on this page to tell. "Not published" means the capability may exist and is simply undocumented, so ask. AI Emaily is first because this is our site; read our row anyway, since it carries the two failures.

Worked example: 40 people, Okta, and a security review#

A 40-person company runs Okta and wants an AI assistant for sales and success. Two constraints are hard: SSO must be enforced so leavers lose access through one action, and the tool must appear in Okta's provisioning report.

1. 1

   Filter on enforcement, not availability

   Any tool that cannot disable password login domain-wide is out; the leaver keeps a working credential. This removes more candidates than the SCIM question does.

2. 2

   Filter on published SCIM

   The tool has to show up in the provisioning report your auditor reads. On the table above, that leaves Superhuman, Fyxer and Front as the documented options.

3. 3

   Run the offboarding test on the survivors

   Whichever one fails the offboarding test above, ask for a documented manual revocation step and put it in the runbook rather than pretending it is not there.

4. 4

   Then score the agent controls

   Now ask about the autonomy ceiling and the audit export. This is where the shortlist reorders, because identity parity is common and agent governance is not.

Red flags in a vendor's answer#

None of these are dealbreakers on their own. Two or more together mean the identity story was built for the questionnaire rather than for your leavers.

• "We support SSO" with no way to turn off password login — the leaver keeps a second door.
• SCIM listed as a feature, but nobody can say what setting active to false does to a queued send.
• No admin screen that revokes a mailbox OAuth grant; the answer is "the user disconnects it themselves," which a departed user cannot do.
• Agent autonomy is a per-user preference with no organisation-level ceiling, so policy is whatever each member last clicked.
• An audit log you can read in the UI but not export, or with a retention period nobody will state.
• "Contact sales" as the answer to a mechanics question — mechanics are documentation, not negotiation.

What we'd pick, and who should skip us#

If enforced SSO and SCIM are hard requirements from your security review, do not buy AI Emaily for this. We build AI Emaily, and we do not ship SAML single sign-on or SCIM provisioning today — sign-in is Google or Microsoft OAuth, or email. On the two criteria this article opens with, we fail, and a page that told you otherwise would not survive ten minutes of checking.

For that reader: Superhuman and Fyxer both publish SSO and SCIM on their enterprise tiers, and Front publishes SCIM with Entra ID and Okta, including group sync and automatic blocking when an IdP profile is suspended. Front is the honest pick if the deciding factor is that deprovisioning must visibly block the user — that behaviour is documented, and ours is not.

Where we are the right answer is the team below the IdP mandate: ten to thirty people with no Okta tenant, whose real risk is not a rogue login but an agent doing something irreversible in a customer's thread. Authority modes run Manual, Copilot and Autopilot; Copilot approval is mandatory before any send; every agent action is logged and attributed; and there is an undo window plus a global pause that stops autonomous sending immediately. Sharing a mailbox is a deliberate admin action, members can be scoped to a subset of shared mailboxes, and the owner's OAuth tokens and private context are never exposed.

The limit inside that: authority is a per-user setting, not an org-wide ceiling an admin locks. We control who sees which mailbox, not what autonomy level a member picks. That is a second gap, different from the SSO one.

Packaging shape: team features sit on our Team plan with a three-seat minimum, and our trial is a 7-day free trial on Pro and Autopilot with a card required — no permanent free tier, no per-seat team trial. Superhuman, Fyxer and Missive gate identity features to a higher tier; check each vendor's pricing page.