New AI Job Titles · Security
AI Red Team Researcher
An AI red team researcher attacks their own employer’s AI products before anyone outside does, targeting the model’s behaviour rather than the infrastructure it runs on: jailbreaks, elicitation of harmful output, and resilience against prompt injection. Microsoft’s AI Red Team, AIRT, is the clearest named example, and posts the work under titles including Principal AI Security and Safety Researcher and Security Researcher II. Its scope is the Copilot product surfaces and Microsoft’s own models, not a single model in isolation.
What does an AI red team researcher actually do?
They find the failures end to end, before launch, and then make them reproducible enough that someone can fix them. Microsoft’s postings describe discovering and exploiting generative AI vulnerabilities end to end to assess system safety, leading strategy across harm categories, and working alongside traditional offensive security engineers, adversarial machine learning experts and developers. The evidence a candidate is asked for is unusually direct: real examples of failures they caused in large AI systems.
The reason the seat is named rather than absorbed into an existing security org is that the bug class does not fit the existing one. A prompt-injection failure is not a memory-safety bug with a patch. It is a behaviour that emerges from the model, the surrounding application, and the untrusted content the application decided to feed in, and reproducing it reliably is itself research work.
How is this different from traditional security red teaming?
| AI red teaming | Traditional red teaming | |
|---|---|---|
| Target | Model behaviour in a product | Networks, identity, applications, infrastructure |
| Typical finding | Jailbreak, harmful output, prompt injection | Exploitable vulnerability, misconfiguration, weak path |
| Reproducibility | Probabilistic, needs statistical framing | Deterministic, a proof of concept either fires or does not |
| Fix | Training, policy, evaluation, guardrails | Patch, config change, control |
| Team make-up | Red teamers plus adversarial ML plus Responsible AI | Offensive security specialists |
Probabilistic reproducibility is the part that catches organisations out. A traditional finding is either exploitable or it is not. A model finding works some of the time, which means the report has to carry a rate rather than a yes, and the fix has to be measured the same way. Security teams that treat AI findings with a pass or fail bug workflow lose the information that mattered.
Why test the product surface rather than the model?
Because the same model behaves differently depending on what surrounds it. Microsoft’s scope spans Bing Copilot, Security Copilot, GitHub Copilot, Office Copilot and Windows Copilot, plus the Phi models, and those surfaces differ in what content reaches the model, what tools it can call, and what a successful attack would get. A model that refuses cleanly in a chat box can be walked into the same output through a document it was asked to summarise.
For a CTO, that is the transferable finding. Evaluating the vendor’s model card tells you very little about your deployment, because your retrieval sources, your tool permissions and your user population are the variables that decide the outcome. The prompt injection guide covers that attack path in detail, and the AI red teaming guide covers running the exercise rather than being hired into it.
Do the other labs have this seat?
They have the function under other names. OpenAI has posted an Offensive Security Engineer for agent products, and model-safety red teaming is established at Anthropic. Microsoft is the useful reference here because AIRT has a public identity and posts titles that describe the work plainly, which makes it citable in a way internal team names usually are not. Treat the Microsoft titles as the naming example, not as evidence that other companies use them.
This is the same pattern as the rest of this cluster. The job travels across companies and the label does not, which is why reading responsibilities beats searching titles. The Model Policy seat is the mirror image of this one: it specifies the behaviour that the red team then tries to break.
Should you build an AI red team internally?
Only if you ship AI products to people outside your company, or your internal deployment has real blast radius. Below that threshold the honest version is an exercise rather than a team: take the AI features you have shipped, get two people who did not build them to spend a week trying to make them misbehave through untrusted content, and record the rate rather than the anecdote. Most organisations have never done that once.
If you do build it, the composition matters more than the headcount. Microsoft’s team is deliberately interdisciplinary because the failures sit between security and harm, and a team drawn only from one side of that line reliably misses the other. The AI security cluster covers how this fits alongside the rest of the controls, and the Chief AI Officer guide covers who owns the outcome.
Team description and role scope verified against Security Researcher II, AI Red Team (open at time of writing) and Microsoft's own account of the team's work: 3 takeaways from red teaming 100 generative AI products (Microsoft Security Blog). Checked August 2026.
AI Red Team Researcher: common questions
Is AI red teaming the same as penetration testing?
No, and conflating them is the most common hiring mistake here. A penetration test targets infrastructure and application code: networks, identity, cloud configuration, the software around the model. AI red teaming targets the model’s behaviour, which means jailbreaks, elicitation of harmful output, and whether the system holds up against prompt injection arriving through the content it processes. The two disciplines overlap in mindset and almost nowhere in technique.
What is Microsoft’s AI Red Team?
AIRT is Microsoft’s internal team for finding failures across the company’s AI portfolio before launch. Its own description is an interdisciplinary group of red teamers, adversarial machine learning researchers, Safety and Responsible AI experts, AI researchers and software developers. That composition is the point: the failures being hunted are part security bug and part harm, and neither a security engineer nor a safety researcher finds all of them alone.
What does the team actually test?
Microsoft’s postings name the Copilot surfaces directly: Bing Copilot, Security Copilot, GitHub Copilot, Office Copilot and Windows Copilot, alongside the company’s own models including the Phi series. That is a product-surface scope rather than a model scope, which reflects how these failures behave. The same model can be safe in one product and exploitable in another because of what the surrounding application feeds it.
Do OpenAI and Anthropic have the same role?
They do the work, under different names. OpenAI has posted an Offensive Security Engineer for agent products, and model-safety red teaming is an established function at Anthropic. Microsoft is the clearest naming example because the team has a public identity and posts titles that say what the work is, so it is the reference point on this page. Do not assume the title transfers when you search other companies.
What does an AI red team researcher earn?
Not publicly benchmarked at the title level. The postings sit at senior and principal grades inside large security organisations, which sets a floor by grade rather than by title, and the sample of named AI red-team seats is still small. Any specific figure attached to this exact title should be treated as unverified.
