mercor

Software Engineer, Identity

Listed by employer · Checked

Older posting · still listed ·

  • onsite
  • FullTime
  • Engineering
  • San Francisco
Work arrangement
onsite
Employment
FullTime
Stated compensation
USD 160,000–325,000 1 YEAR
Apply on company website ↗
01 / A QUICK CHECK BEFORE YOU APPLY

Does the location policy fit?

Choose where you would work from. We’ll compare it with the posting’s stated requirements.

Choose the country you will work from. You can change this anytime.

Country and sponsorship changes take effect when you click Check eligibility.

Choose a country to check geographic compatibility. The source requirements are available below.

Source: ashbyChecked Original posting ↗
This is an older posting.

The employer’s posting date is more than 60 days ago. It remained listed at our last successful check; it may be a long-running or evergreen opening. Confirm availability on the original posting before applying.

Browse jobs posted in the past 60 days →

Requirements

1 with evidence8 unclear or unstated
Remote policy
onsite
“Provider workplace type: onsite”
From employer posting metadata
Employment type
FullTime
Compensation
USD 160,000–325,000 1 YEAR
8 fields not stated in this posting
Employer sponsorship
Not specified
Geographic scope
Not specified
Degree requirement
Not specified
Security clearance
Not mentioned
Timezone / hours
Not specified
Citizenship requirement
Not mentioned
Minimum experience (years)
Not specified
Work authorization
Not specified

These details were not stated in the tracked posting. Confirm with the employer.

READ IT IN THE EMPLOYER’S OWN WORDS

Original job description

Reading view uses normalized posting text so exact evidence excerpts can be highlighted.

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.
Read full descriptionShow less description
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. 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 Bachelor’s Degree in Computer Science or a related technical degree such as Electrical Engineering, Physics, Mathematics, Computer Engineering, Information Systems or Statistics 2–5 years in engineering 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 integrations (SAML, OIDC/OAuth 2.0), or an internal IdP integration layer Operating Slack Enterprise Grid, Google Workspace, or GitHub Enterprise at multi-tenant scale, or across hundreds of thousands of live access grants DLP, data governance, or insider-risk tooling deployed across a large and largely external population Work on workload or machine identity: SPIFFE/SPIRE, short-lived credentials, service-to-service authz Having migrated an org onto a managed identity provider, or replaced a role-based permission system with a relationship-based one, and lived through it Benefits Generous equity, vested over 4 years Up to $15K relocation bonus $10K housing bonus (if you live within 0.5 miles of the office) $1,500/month meals stipend Free Equinox membership $200/month laundry reimbursement $200/month personal wellness reimbursement Health, Dental, and Vision insurance
Original formatting and links
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.


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

  • Bachelor’s Degree in Computer Science or a related technical degree such as Electrical Engineering, Physics, Mathematics, Computer Engineering, Information Systems or Statistics

  • 2–5 years in engineering

  • 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 integrations (SAML, OIDC/OAuth 2.0), or an internal IdP integration layer

  • Operating Slack Enterprise Grid, Google Workspace, or GitHub Enterprise at multi-tenant scale, or across hundreds of thousands of live access grants

  • DLP, data governance, or insider-risk tooling deployed across a large and largely external population

  • Work on workload or machine identity: SPIFFE/SPIRE, short-lived credentials, service-to-service authz

  • Having migrated an org onto a managed identity provider, or replaced a role-based permission system with a relationship-based one, and lived through it


Benefits

  • Generous equity, vested over 4 years

  • Up to $15K relocation bonus

  • $10K housing bonus (if you live within 0.5 miles of the office)

  • $1,500/month meals stipend

  • Free Equinox membership

  • $200/month laundry reimbursement

  • $200/month personal wellness reimbursement

  • Health, Dental, and Vision insurance

Similar roles

All mercor jobs →

Matched by role category. Review each posting’s requirements before applying.

THE JOB ELIGIBILITY CHECKER

Check a job