ABOUT MERCOR Mercor's mission is to organize human intelligence to power the AI economy. We're a leading AI data company, building the layer between human expertise and frontier models. Millions of domain experts on the platform are paid over $4 million per day to train frontier AI models. Mercor's APEX benchmark family measures AI's real-world impact on professional work. Mercor Enterprise brings this same infrastructure to Fortune 500 companies: helping companies capture how their best people actually work, translating that expertise directly back into agents.   Mercor is creating a new category of work where expertise powers AI advancement. Achieving this requires an ambitious, fast-paced and deeply committed team. You’ll work alongside researchers, operators, and AI companies at the forefront of shaping the systems that are redefining society. Mercor is a profitable Series C company valued at $10 billion. We work in-person five days a week in our San Francisco, NYC, or London offices. WHY THIS ROLE We build systems that make billions of authorization decisions a week for hundreds of thousands of users, most of them contractors and experts rather than employees. A typical company's IdP models a few thousand employees. Ours models a global expert network where membership turns over constantly, every client engagement needs its own isolation boundary, and a wrong permission can expose a frontier lab's data. The team is small, led by one of Mercor's earliest engineers, and operates with a high degree of ownership. There's no spec handed to you: you own the product scope and direction, with the team weighing in on prioritization and technical detail. 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 https://slack.com/customer-stories/mercor-story. 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. WHAT YOU'LL DO - Keep a billion-plus weekly permission checks correct and fast. Own the hot path: the SpiceDB schema, the relationship graph, and the caching, denormalization, and consistency tradeoffs that decide whether authorization is invisible or the reason a page is slow - Model authorization in SpiceDB. Design the definitions, relations, and permissions expressing how experts, employees, workspaces, channels, projects, and client engagements relate, and evolve that schema without breaking live checks - Extend the Audiences rule engine. Add providers, express new access rules, and make the fan-out reliable enough that operations trusts it without a human checking - Scale the downstream providers themselves (Slack Enterprise Grid, GitHub, Google Workspace, DLP and monitoring), including the bulk operations, quota engineering, and reconciliation that none of them make easy - Own provisioning fan-out end to end, with reconciliation that catches drift rather than trusting that every write succeeded - Close the gap between HR truth and system truth. Joiner/mover/leaver is driven by upstream systems that lag real org change. Build lifecycle automation that degrades safely when the source of truth is wrong or late, because at our scale it will be - Extend identity to non-human principals. Agents and services increasingly need first-class identities, scoped credentials, and auditable authorization: the same rigor as human access, with none of the same assumptions - Talk directly with ops teams to understand business requirements, then translate them into large-scale distributed systems designed with security in mind from the start - Design for the security implications of what you're building. Not auditing after the fact, but thinking through how gaps in system design compound at scale WHAT WE'RE LOOKING FOR - Strong product engineering fundamentals. You've built and operated systems in production, you care about correctness and reliability, and you're comfortable owning scope without a lot of hand-holding - Large-scale distributed systems experience. This is the most identifiable signal on a resume and a strong filter; the problems here are genuinely unprecedented in scale - Comfort with data modeling under consistency constraints. You've reasoned about stale reads, cache invalidation, and eventual consistency in a system where being wrong has real consequences - Experience pushing third-party platforms past their intended limits. Rate limits, quotas, bulk APIs, and the reconciliation you build when a vendor's guarantees run out - Security-minded thinking. Not a formal background necessarily, but the instinct to ask "how does this break, and what are the consequences?" when designing a system - Adaptability. We don't want someone who will come in and replicate what they've done before; Mercor's landscape is unique and requires genuine intellectual flexibility BONUS, NOT REQUIRED None of these are prerequisites. We hire strong product engineers into this team and teach the domain. But any will accelerate you: - Direct experience with SpiceDB, Zanzibar, OpenFGA, Ory Keto, or an in-house ReBAC/policy engine (Cedar, OPA, Oso) - Having built or operated SCIM provisioning, SSO…