Examples of What We Build
IAM-Service is our authorization service for first-party surfaces. It sits in the hot path of every request across our own products, backed by SpiceDB, an open-source implementation of Google’s Zanzibar. We model access as relationships rather than roles (ReBAC instead of RBAC), which is what lets us answer “can this person see this channel, in this workspace, on this project?” consistently and fast. Every millisecond here is felt across the platform.
Audiences is our rule engine for identity orchestration across third-party services. You declare who should have access to what; Audiences resolves that into concrete grants, pushes them into twenty downstream providers (Slack, Google Workspace, GitHub, and the rest), and keeps them reconciled as membership changes underneath. It turns “this expert joined this project” into working access everywhere within minutes, and “this contract ended” into revocation everywhere.
One Slack workspace per client project. It’s provisioned automatically on Slack Enterprise Grid, and experts join as multi-channel guests scoped only to the channels their work requires, so a project brief in the morning can be a staffed workspace by the afternoon, and no expert carries information across client boundaries. More than 2,000 workspaces, over 85,000 active Okta accounts, one administrator. Slack wrote up how it works: How Mercor Coordinates a Global AI Workforce With Slack.
First-party authentication on WorkOS. Sign-in, session handling, and directory data for our own products move onto WorkOS, so they have one owner instead of being handled in several places. The interesting part is the migration: no flag day, no single moment where everything switches. People are logging in the whole time, so the existing paths keep serving traffic while the new one runs alongside them.
Moving GitHub to Enterprise Managed Users. EMU makes our IdP the source of truth for GitHub accounts: identities are provisioned, deprovisioned, and auditable the same way they are everywhere else we govern, and removing someone from the directory removes their GitHub access. The hard part is the cutover: mapping existing accounts to the identities we govern, and keeping a live engineering org and a large external contributor population pushing code the whole way through.
Data-loss prevention across thousands of workspaces. Each client engagement carries its own confidentiality terms, so there is no single ruleset. There are thousands of overlapping ones, scoped per grid, per workspace, per project, and those are created and torn down automatically. The hard part is distributing and evaluating policy at that scale: getting the right rules onto every new workspace, channel, and DM as it appears, re-scoping when a project changes shape, and enforcing consistently without slowing communication down. Audiences decides who gets into a workspace; the same rule engine has to decide what can be said inside it.