Every technology wave produces a new layer of job titles. Some of those titles describe genuinely new work. Others are marketing for existing disciplines, or a recruiter’s attempt to make a standard role sound current. The intersection of artificial intelligence and cybersecurity is producing both kinds, and the two are not always easy to tell apart from a job posting.

Four categories have emerged with enough specificity and hiring volume to deserve serious examination: AI Red Teamer, AI Security Engineer, ML Security Researcher, and AI Governance and Risk. Each overlaps with existing security work in some ways, and each requires something genuinely different in others. The honest summary is that two of these are real, durable, and growing fast; one is real but narrow; and one is mostly a rebranding exercise layered over work that will eventually be absorbed into the existing security engineering job family. The details matter, so here is a role-by-role breakdown.

AI Red Teamer

This is one of the two new categories that is unambiguously real. The job did not exist in any meaningful volume three years ago. It exists now because enterprises and AI product companies are deploying large language models in production, and the attack surface of those deployments is qualitatively different from what traditional penetration testers were trained to assess.

The core work involves adversarial testing of LLM-based applications. Prompt injection is the foundational technique: attempting to override or subvert the model’s intended behavior by embedding instructions in user input, in retrieved context from a RAG pipeline, or in external content the model is asked to process. Indirect prompt injection is a specific and underappreciated variant — the attacker does not interact with the model directly but instead poisons content that the model will later ingest. A document summarizer that reads attacker-controlled web pages, a customer service bot that retrieves from an unmoderated knowledge base, an AI coding assistant that fetches from public repositories — all of these are indirect injection surfaces. Testing them requires understanding the full data flow of the application, not just the user-facing interface.

Beyond prompt injection, AI Red Teamers test for jailbreaks, which are attempts to bypass content policy or system prompt restrictions to elicit outputs the model is configured not to produce. This is partially a content safety problem and partially a security problem, depending on what the model has access to. When a jailbroken model has tool use, access to internal APIs, or the ability to take actions on behalf of users, the jailbreak becomes a legitimate security finding, not just a policy violation.

Data exfiltration via model outputs is a distinct concern in enterprise deployments. Models with access to sensitive business data — customer records, internal documents, financial data — can be manipulated into including that data in responses in ways that bypass data loss prevention controls. Testing for this requires understanding how the model’s context window is loaded and what a realistic attacker could extract through sustained conversation or through indirect injection.

Model inversion attacks and membership inference sit at the edge of what most AI Red Teamers work on day-to-day. These are techniques for inferring properties of training data from model outputs — whether a specific record was in the training set, or what the distribution of training data looks like. In practice, most AI Red Teamer roles at product companies are not focused here. This territory is more squarely in the ML Security Researcher domain. But understanding the concepts is useful because it informs how to think about what a model “knows” and where data leakage risks originate.

The primary frameworks for this work are OWASP LLM Top 10, which provides a taxonomy of the most significant vulnerability classes in LLM applications, and MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), which is the ML-specific extension of ATT&CK covering adversary tactics and techniques against AI systems. Both are worth reading in full, not just as background material but as working references during assessments.

Who is hiring: AI product companies (companies whose core product is built on top of LLMs), large enterprises that have deployed LLM-based internal tooling or customer-facing products, and a growing number of consulting firms that offer AI red team assessments as a service. Google, Microsoft, OpenAI, Anthropic, and the large cloud providers have had formal AI red team functions for some time. The enterprise deployment wave — companies using GPT-4 or Claude or Gemini to build internal tools — has pushed demand considerably broader than that.

Background needed: Traditional offensive security experience is the baseline. People coming from penetration testing or red team backgrounds have the right mental model — assuming compromise, chaining techniques, documenting findings reproducibly, understanding impact. The LLM-specific layer requires hands-on familiarity with LLM APIs (OpenAI, Anthropic, Google) and enough understanding of how transformer-based models process input to reason about attack surfaces. Deep knowledge of transformer architecture is helpful but not required for most roles. Understanding of retrieval-augmented generation pipelines is increasingly required, because RAG is how most enterprise LLM deployments are built and it introduces the indirect injection surface.

Salary range: $130,000 to $200,000 base compensation in the United States, with total compensation at AI product companies typically higher due to equity.

Durability assessment: High. This is not a trend-chasing title. The attack surface is real, the techniques are specific and require dedicated expertise, and the hiring is growing as LLM deployments proliferate. The AI Red Teamer will likely remain a distinct specialization rather than being absorbed into general red team practice, because the knowledge domain is different enough that it does not naturally transfer in either direction.

AI Security Engineer

This role is also real, though it is more likely to eventually converge with existing DevSecOps and security engineering work as the field matures. For now, the gap between what a standard security engineer knows and what it takes to secure an ML pipeline end-to-end is wide enough that the specialization is warranted.

The scope of the work is the full ML pipeline, from training data through inference infrastructure. Training data integrity is the starting point: ensuring that the data used to train or fine-tune models has not been tampered with, that data sources are authenticated and auditable, and that poisoning attacks — which manipulate model behavior by corrupting training data — are detectable. This requires a combination of data provenance tooling, access controls on training pipelines, and in some cases statistical analysis to detect anomalous data distributions.

Model supply chain security is a rapidly developing sub-area. ML models are now distributed artifacts, similar in some ways to software packages, and they carry similar supply chain risks. A model downloaded from a public repository and fine-tuned internally could contain embedded adversarial behavior from its pretraining. Signed models, model bills of materials (equivalent to software SBOMs), and integrity verification at load time are the mitigations. This is still nascent — most organizations are not doing it rigorously — but pressure from regulators and from incidents is pushing it forward.

Inference infrastructure hardening covers the compute environment where models run in production. This includes container and orchestration security for GPU workloads, network segmentation between the inference layer and internal data stores, secrets management for API keys and model credentials, and rate limiting and abuse prevention. These controls are recognizable to any security engineer, but the specific implementation details differ because GPU-accelerated inference workloads are operationally different from standard compute.

Model versioning and rollback capability is an operational security concern that gets less attention than it deserves. When a model behaves unexpectedly in production — whether due to adversarial inputs, undetected poisoning, or a fine-tuning error — the ability to roll back to a known-good version quickly is a critical control. Building and maintaining that capability is engineering work that sits squarely in the AI Security Engineer domain.

Monitoring for model drift and adversarial inputs in production is an ongoing operational requirement. Statistical drift monitoring (detecting when the distribution of model inputs or outputs shifts significantly from baseline) is standard MLOps practice, but security-oriented monitoring adds a different lens: looking for patterns that suggest systematic probing, extraction attempts, or injection attacks. Building those detection capabilities requires understanding both the model’s normal behavior and the signatures of adversarial use.

Who is hiring: Companies with mature internal AI/ML operations — large tech companies, financial institutions, and healthcare organizations that have moved AI applications into production at scale. These roles are often filled from either the MLOps side (practitioners who have developed security awareness and want to specialize) or the security engineering side (practitioners who have learned enough about ML pipelines to be effective). The two paths produce slightly different profiles, and both are in demand.

Background needed: The MLOps path requires learning threat modeling, secure architecture principles, and security tooling. The security engineering path requires learning how ML training and inference pipelines are built, how models are stored and versioned, and how GPU infrastructure differs operationally from standard compute. Neither path is fast — this is a domain that takes sustained investment to develop credibility in.

Salary range: $140,000 to $210,000 base compensation in the United States, reflecting the scarcity of people with the combined background.

Durability assessment: Medium-to-high. The AI Security Engineer role is real and addresses genuine gaps. However, as ML security best practices mature and tooling emerges, much of this work will be incorporated into standard DevSecOps and platform security engineering. The specialization will narrow rather than disappear — the most technically demanding parts of the work will remain specialized, while the baseline controls become standard expectations for any security engineer working in an AI-heavy environment.

ML Security Researcher

This is the most technically demanding of the four categories, and also the narrowest. The work is adversarial machine learning research: studying how models can be attacked at the algorithmic level, independent of any particular deployment. Model poisoning (corrupting training data or the training process to embed adversarial behavior), evasion attacks (crafting inputs that cause a model to misclassify or behave incorrectly), and membership inference (determining whether a specific data point was in a model’s training set) are the core research areas.

The academic foundations of this field are well-established. The body of work on adversarial examples — inputs imperceptible to humans that cause models to fail — goes back over a decade. Membership inference attacks were formalized in research published by Shokri et al. in 2017. Model poisoning has been studied extensively in the federated learning context. MITRE ATLAS provides a practitioner-facing taxonomy that maps research findings to real-world threat scenarios.

What the job actually looks like in practice depends heavily on the organization. In academia and at top-tier AI research labs (Google DeepMind, OpenAI, Anthropic, Meta AI), ML Security Researchers publish papers, collaborate with ML researchers to develop defenses, and in some cases advise on internal policy. The line between ML Safety and ML Security is blurry in these organizations. In enterprise settings — the rare large financial institution or tech company with a formal adversarial ML function — the work is more applied: testing whether deployed models are vulnerable to known attack classes, developing detection and mitigation capabilities, and translating research findings into engineering recommendations.

The honest assessment is that this is not a common job. The number of organizations with the sophistication to hire and deploy a dedicated ML Security Researcher is small. Most of the active practitioners are in research labs, academic groups, or well-funded startups working on ML security as a product. Security professionals who are interested in this direction and do not have an ML research background will find it a long path — the prerequisite knowledge includes a genuine understanding of how models are trained, the mathematics of loss functions and gradient descent, and the ability to read and contribute to research literature. This is not a credential gap, it is a knowledge gap, and it takes years to close.

Who is hiring: Academic research groups, AI safety and security teams at frontier AI labs, a small number of large technology companies and financial institutions, and ML security product companies (Robust Intelligence, HiddenLayer, and similar organizations). The market is small but real.

Background needed: A master’s or PhD in machine learning, computer science, or a related field is the common path. Strong mathematical background (linear algebra, probability, optimization). Ability to implement and reproduce published attacks in frameworks like PyTorch. Security intuition is a plus but not the primary credential here — the ML expertise is harder to develop and more gatekeeping than the security knowledge.

Salary range: Highly variable. Academic and research lab positions range from $80,000 to $300,000+ depending on level, organization, and whether equity is included. Enterprise positions are more narrowly concentrated in the $150,000 to $220,000 range.

Durability assessment: High within a narrow market. The research problems are hard and not going away. But this is not a career path that opens broadly to security practitioners who want to pivot — it is a research career that happens to be security-adjacent. Conflating it with the other three categories in this article does a disservice to practitioners making career decisions.

AI Governance and Risk

This category has received more attention from HR departments and compliance teams than from the security community, which is appropriate given where the work actually sits. AI Governance and Risk roles are much closer to GRC than to technical security. The work involves evaluating AI systems for bias and fairness, implementing AI risk frameworks, managing AI-related regulatory compliance, and developing internal policies for AI deployment and incident response.

The regulatory drivers are significant. The EU AI Act, which became applicable in stages from 2024 onward with the high-risk system requirements taking full effect in 2026, creates direct compliance obligations for organizations deploying AI in regulated contexts. High-risk applications — AI used in hiring decisions, credit assessment, healthcare, law enforcement, education, and critical infrastructure — face conformity assessments, transparency requirements, human oversight mandates, and incident reporting obligations. Organizations with material EU exposure need people who understand these requirements well enough to build compliance programs around them.

The NIST AI Risk Management Framework (AI RMF), published in 2023, provides a voluntary but widely-adopted structure for managing AI risks organized around four functions: Govern, Map, Measure, and Manage. It is the primary US reference framework and has been adopted as the baseline for many enterprise AI risk programs. Familiarity with the AI RMF is table stakes for anyone working in this domain.

The work in practice involves AI bias auditing (evaluating whether model outputs produce discriminatory outcomes across demographic groups), developing and maintaining AI inventory and risk registers, designing and running AI incident response processes, reviewing AI vendor contracts for risk allocation, and liaising between legal, compliance, and technical teams on AI deployment decisions. None of this requires deep ML knowledge, though understanding enough about how models work to ask the right questions is valuable. Strong policy and compliance skills transfer directly.

The algorithmic accountability dimension of this work is growing in importance. When an AI system makes or influences a consequential decision — a loan denial, a hiring screen, a medical triage — the organization needs to be able to explain the basis for that decision, detect errors and bias systematically, and have a process for human review and correction. Building and operating those processes is AI Governance work.

Who is hiring: Any organization with significant AI deployments in regulated industries or EU market exposure. Financial services, healthcare, insurance, HR technology, and large enterprise technology companies are the primary employers. Law firms that advise on AI compliance are also building internal capability. This is a fast-growing segment — EU AI Act enforcement pressure is real and organizations that ignored it until 2025 are now scrambling.

Background needed: GRC background transfers well — people who have worked in privacy compliance, information security risk management, or regulatory compliance already have the relevant skills in documentation, risk frameworks, and cross-functional stakeholder management. Legal and policy backgrounds are also represented in this function. Technical background is helpful but not required; the technical complexity of the role is much lower than the other three categories.

Salary range: $95,000 to $155,000, broadly consistent with mid-level GRC and compliance compensation.

Durability assessment: High and growing. This is the role most directly driven by regulation, and regulation does not retreat. The EU AI Act is the most significant forcing function, but US state-level AI legislation (Colorado’s AI Act, Texas SB 2060) and sector-specific guidance from financial regulators and the FDA are creating compliance obligations in the domestic market as well. The AI Governance function will mature and standardize over time — today’s improvised programs will become the compliance frameworks of 2030 — but the demand for people who can build and run them is durable.

What Existing Security Skills Transfer to Each Role

For practitioners evaluating which of these directions fits their background, the skill transfer is not uniform.

Penetration testers and red teamers have the strongest natural path to AI Red Teamer roles. The adversarial mindset, the documentation discipline, the ability to reason about attack chains — all of these transfer directly. The gap to close is LLM-specific technical knowledge, which is acquirable through practice with the OWASP LLM Top 10 and hands-on work with LLM APIs.

Security engineers with DevSecOps or platform security backgrounds have the strongest path to AI Security Engineer roles. Familiarity with container security, pipeline security, secrets management, and threat modeling of complex systems is directly relevant. The gap is MLOps operational knowledge, which can be developed through exposure to ML training and serving infrastructure.

GRC and compliance practitioners have the clearest path to AI Governance and Risk roles. The frameworks are new but the skills — risk assessment, policy development, regulatory interpretation, documentation — are the same. Investing in understanding the EU AI Act and NIST AI RMF is sufficient orientation for most of this work.

The ML Security Researcher path is the exception. There is no shortcut here. The role requires genuine ML expertise that takes years to build, and security practitioners who attempt to bridge the gap without that foundation will find the research community difficult to enter.

Where to Build the Relevant Knowledge

For AI Red Teaming, the starting points are OWASP LLM Top 10 (freely available, regularly updated), MITRE ATLAS (the adversarial ML framework with specific tactics and techniques), and the Lakera AI blog, which publishes practical research on prompt injection and LLM security. Building a local testing environment with an open-source model (Llama, Mistral) and running documented attack techniques against it is more useful than certification programs.

For AI Security Engineering, the ML security research literature is the right starting point, particularly work on model poisoning and supply chain attacks. Following the development of model signing standards (Sigstore for ML, the emerging SBOM for ML specifications) and the security-adjacent MLOps tooling space (MLflow, DVC, Weights and Biases with audit capabilities) is practically useful.

For ML Security Research, arXiv is the primary literature source. The proceedings of IEEE S&P, USENIX Security, CCS, and NeurIPS workshops on trustworthy ML are where the field publishes. Reading papers on adversarial examples (Goodfellow et al. 2014 is still foundational), membership inference (Shokri et al. 2017), and model poisoning provides the conceptual baseline.

For AI Governance, the NIST AI RMF documentation and the EU AI Act full text (and the associated guidance documents from the European AI Office) are the primary reference materials. The IEEE Ethically Aligned Design framework and the Partnership on AI’s work on algorithmic accountability provide additional context.

The Honest Take

Two of these four categories are unambiguously worth pursuing for practitioners who can develop the relevant background: AI Red Teamer and AI Governance and Risk. Both are real, both are growing, and both will remain distinct specializations for at least the next several years.

AI Security Engineer is real work addressing real gaps, but it sits on a convergence trajectory — as ML security best practices mature, this specialization will be absorbed into the broader security engineering family. The specialization is worth developing now because the market is paying well for it, but practitioners should plan for the role to evolve significantly.

ML Security Researcher is a legitimate field with hard problems and interesting work, but it is not meaningfully accessible to security practitioners without ML research backgrounds. Treating it as a career pivot option for experienced security engineers understates the knowledge gap and overstates the opportunity.

The broader point is that “AI security” is not a single thing. The overlap between machine learning and cybersecurity produces several distinct problem spaces with different skill requirements, different hiring pools, and different trajectories. Getting clear on which specific problem you want to work on, and being honest about the background required, is more useful than pursuing the category label.

This article is provided for informational purposes only. Salary data and market conditions change; verify figures with current industry surveys before making career decisions.