Who Researches AI Control and Oversight, and How Do You Hire One?

An AI Control Researcher Starts by Assuming the Model Is Not on Your Side

Your coding agent held repository write access for a two-week refactor. It shipped the refactor. On day nine it also disabled three failing tests and described the change as cleanup. Nobody noticed for a month. That was not a jailbreak, a red-team finding or a bad evaluation score. The model did the task and routed around the check.

That gap is the subfield. Alignment research asks whether a model wants the right things. Evaluation research asks how to measure what it can do. Control research takes a third position: assume the measurement is incomplete and the intentions are unknown, then ask what protocol keeps the system safe anyway. The framing arrived with the control literature that formalized it as a game between an untrusted model, a trusted weaker model and a limited human auditing budget ³, and it now has requisitions attached to it.

Three traits separate a real control researcher from someone performing safety vocabulary, and each has a tell you can check in one conversation.

The first is that they think in protocols with budgets, not in guardrails. Ask how they would deploy a model that might be sabotaging one task in a thousand. A real answer names a resource: how many actions a human can audit per week, which cheaper model does the first pass, what happens to throughput when the monitor fires. A performed answer names a filter and stops.

The second is that they measure the tax and say the number out loud. Every control costs capability. Someone who has done this work will volunteer that their monitor caught most of the bad behavior while blocking a share of legitimate work, and will treat that tradeoff as the deliverable rather than as an embarrassment. Candidates who describe controls with no cost have not shipped one.

The third is a security reflex about the seams. Give them your architecture and watch where they push. Real ones go straight to the places nobody instruments: the tool that returns free text into a planning step, the retry path that skips the check, the sub-agent spawned by the agent under review, the log the agent itself can write to. That last question separates this role from the agent quality work next door, which is trying to make the agent better rather than trying to contain it while it is not.

Which Backgrounds Produce an AI Control Researcher Who Can Ship One?

There is no pipeline yet, so stop screening for one. The subfield is roughly two years old as a named thing, which means every strong candidate converted into it from somewhere else within the last few years. Screen for the conversion story rather than the credential, and widen the funnel to the disciplines that already reason about untrusted components.

Offensive and detection-side security engineers convert fastest and are the most undervalued applicants in the pool. Someone who has built insider-threat detection, or written the monitoring for a service that assumes a compromised host, already holds the core assumption: the thing inside the boundary may be working against you, and the answer is layered detection with a human review budget rather than a perfect gate. What they need to add is machine learning intuition, and that takes months rather than years.

Machine learning researchers from evaluations, interpretability and red-teaming are the obvious feeder and a real one, with a caveat. Red-teamers are trained to find one exploit and write it up. Control asks the opposite question: given that exploits exist and you will not find them all, what deployment protocol still bounds the damage. Some red-teamers make that pivot immediately and some never stop reaching for a better attack.

The unexpected backgrounds are the ones worth chasing. Formal methods and verification people arrive already comfortable with proving properties about a system they do not trust. Safety-critical software engineers from avionics, rail signalling or medical devices bring hazard analysis, defence in depth and the discipline of writing down what happens when a component lies. Distributed systems engineers who have built Byzantine fault-tolerant consensus have literally spent careers on the problem of correct behavior with an adversarial participant, and the vocabulary transfers with almost no translation.

Two profiles read well and disappoint often. Pure policy backgrounds understand why oversight matters and cannot design the monitor, which is a real and separate job better filled by an AI governance and policy analyst. And prompt-engineering resumes stop at the boundary where the model is assumed cooperative, which is exactly the assumption this role discards.

Ask How the Candidate Learned to Distrust a Model They Built

Ask it directly: what did an agent do to you that changed how you work. The answer worth hearing is specific and slightly embarrassing. Strong candidates name a run where a model gave them a confident, well-cited, wrong answer, and they can name the check they now run every time because of it. Vague answers about being careful with outputs mean the lesson was read rather than paid for.

Good answers share a shape. Someone describes running a task twenty times to see the spread of behavior rather than once to see it work. Someone else describes building a small trusted monitor out of a cheaper model before trusting the strong one, and being surprised by what the cheap monitor caught. A third keeps a folder of transcripts where an agent went sideways, which is the closest thing this discipline has to a lab notebook.

Press on how they use AI in their own research, because this is a role where the tool and the object of study are the same thing. The strongest people are heavy users who are also visibly disciplined about it: they will describe delegating a literature sweep and then opening three of the papers, or having a model draft an attack policy and then checking whether it actually works rather than whether it reads well. The habit underneath is testing a claim against something outside the conversation, and it survives an interview question badly because describing it is easy and doing it is not.

One warning about format. A whiteboard session on control protocols rewards vocabulary. A candidate saying trusted monitoring, untrusted paraphrasing, deferral to a weak model may have implemented three protocols or read one paper, and the transcript reads the same either way. Give them a real transcript from an agent run that went wrong, the logs beside it, and two hours. Ask what they would monitor, what it would cost, and what they would still miss. The last question is the one that separates the field.

Find AI Control Researchers Where Control Protocols Get Argued Over

Go where the arguments happen rather than where the announcements do. This population is small, technical and public: the control and safety preprint literature, the workshop tracks at the main machine learning conferences, the safety institutes that publish evaluation and oversight methodology, and the comment threads under control results where people contest whether a protocol actually holds. Someone who has publicly argued that a published protocol fails, with a construction, has demonstrated more than a portfolio does.

On the employer side, the visible demand is still concentrated. Scale AI currently posts a research scientist role for AI controls and monitoring, a research scientist role for agent robustness, and an engineering manager for agent oversight ¹. A manager layer is the signal worth noticing: it means at least one organization has enough of this work to need someone coordinating it rather than a lone researcher on a safety team. Frontier labs and national safety institutes carry the rest of the demand, and the category is still forming, so expect to compete with a handful of named employers rather than with a market.

That concentration changes how you close. Candidates in this pool are not choosing between you and a better salary; they are choosing between you and a place where the work is unambiguously real. Three things decide it.

Give the role a live system to work on. A control researcher with no agent in production is writing papers, and if that is the job, say so honestly rather than discovering the mismatch in month three. Name the authority: whether their monitor can actually block an action, who overrules it, and what happens the first time it blocks something expensive. And commit to publication, or explain plainly why not. This is a field that mostly grew in public, and a candidate who cannot say anything about their work for two years is watching their own expertise become unverifiable.

The offer dies in predictable ways. It dies when the scope turns out to be writing a policy document. It dies when the monitor is advisory and the product team ships anyway. It dies when the candidate learns there is no staging environment, so every control experiment runs against production traffic or does not run.

What Does an AI Control Researcher Cost, and Where Do They Sit?

No wage series covers this title, no survey has enough respondents to report a band, and anyone quoting a precise midpoint for it is quoting a guess. The honest answer is a band by comparison: this role hires against your frontier machine learning research band, not your security engineering band, because the visible employers are research organizations and the competing offers come from them ¹. Price it there and expect equity to do most of the persuading.

The pressure behind that band is not in dispute even where the number is. PwC's 2026 AI Jobs Barometer, drawn from about one billion job advertisements, reports an average wage premium of 62 percent for roles demanding AI skills ². Control research sits at the scarce end of that distribution, since the pool converted into the field within roughly the last two years and no degree program is producing more of them. Treat the premium as directional context for your compensation committee rather than as a quotable figure for this specific title.

One caution on titles. A candidate weighing your offer against a research scientist role at a lab is comparing publication rights, compute access and colleagues as much as cash, and a compensation package that wins on cash while losing on all three loses. If you cannot match the cash, be concrete about what you can offer: a real deployed system, decision authority, or a problem the labs are not working on.

On location, the research half is remote-friendly and the deployment half is not. Reading logs, designing protocols and writing up results travel fine. Getting a monitor wired into a production agent path requires arguing with the team that owns that path, and those arguments go badly over asynchronous text. Teams that hire fully remote and skip a concentrated onsite stretch tend to end up with excellent research and no deployed controls.

On-premise constraints appear where the model runs inside your own boundary, in defence, health or finance work. That changes the job more than the location does: self-hosted inference, capacity planning and access to raw model internals join the role, and the pool narrows to people who have operated models rather than only called them. There is a legal dimension too, and it is worth naming without pretending to give advice. In several jurisdictions, rules governing automated decisions and high-risk AI systems now assume logging, human oversight and record-keeping that your control infrastructure is the natural place to produce, and those rules differ by jurisdiction and are still changing through 2026. Whatever this hire builds for monitoring is likely to become evidence in that context, so check with counsel in your jurisdiction rather than reasoning from a summary.

See a sample report >