The roles
Job titles are inconsistent across the industry. The same work appears as "AI security engineer", "ML security engineer", "product security, AI" or "trust and safety engineer". Read the responsibilities, then map them to one of these shapes.
AI security engineer
Secures LLM features and agents that the company builds or adopts: design reviews, guardrails, tool permission models, gateways, detection and incident response for AI systems. The broadest role and the most common.
Prepare: the agent design round, prompt injection mechanics and defences, excessive agency, secure output handling, RAG access control, logging and incident response. Start with the agentic AI security guide.
AI red teamer
Attacks models and AI products before release: jailbreaks, injection chains through tools and data, sensitive data leakage, and, at model developers, probes for dangerous capabilities. Often works alongside policy and safety teams.
Prepare: engagement planning, manual and automated attack methods, measuring success as rates, writing findings that lead to fixes, and a live exercise against a target application. See the red teaming questions.
Product security engineer for AI features
An application security engineer whose scope now includes AI features. The work is classic AppSec applied to systems with a model in the middle: authorization, injection into downstream interpreters, secrets, abuse and rate limits.
Prepare: web and API security fundamentals, mapping LLM risks to known vulnerability classes, secure code review of LLM integrations. See the application security questions.
ML security researcher
Studies attacks and defences at the model level: adversarial examples, poisoning and backdoors, membership inference and extraction, robustness evaluation and interpretability-based detection. Usually expects publications or equivalent research output.
Prepare: the key papers and their threat models, experiment design, evaluation pitfalls, and a discussion of your own research. See the privacy and model attack questions.
AI security architect
Sets the patterns other teams build on: identity and credentials for agents, isolation and sandboxing, model gateways, approved-model registries, logging standards and approval flows. Works across many teams rather than on one product.
Prepare: platform-level design questions, trade-offs between safety and capability, supply chain and provenance, and how to make the secure path the easy one for product teams.
AI risk and governance lead
Connects AI systems to policy and law: risk assessments, model inventories, mapping obligations under the EU AI Act, building programmes on the NIST AI RMF or ISO/IEC 42001, and working with legal, privacy and engineering.
Prepare: what each framework is for, scenario questions on classifying and assessing an AI system, and how governance requirements become engineering controls. See the frameworks question.
The rounds
Most AI security loops are assembled from the round types below. Which ones you meet, and how many, depends on the role.
| Round | What happens | Most relevant for |
|---|---|---|
| Threat modeling or design | You are given an AI feature or agent and asked to find the risks and design controls, usually on a whiteboard or in a shared document. | Engineers, architects, product security |
| Hands-on attack exercise | You attack a deliberately vulnerable LLM application, often capture-the-flag style, and explain your method as you go. | Red teamers, engineers |
| Secure code review | You review code that integrates a model, such as a tool handler or a RAG pipeline, and find the vulnerabilities. | Product security, engineers |
| Security fundamentals | Classic security depth: authentication and authorization, web vulnerabilities, cloud and network security, cryptography basics. | All engineering roles |
| ML and LLM fundamentals | How models are trained and served, embeddings and retrieval, fine-tuning, sampling, and why those details create risk. | Researchers, red teamers, engineers |
| Research discussion | A deep conversation on papers you know or your own work, including threat models and evaluation methodology. | Researchers |
| Governance scenario | An AI system and a regulatory or policy context; you assess risk and propose a programme. | Governance leads, architects |
| Behavioural and incident | Past incidents you handled, disagreements with product teams, and how you prioritise risk against delivery. | All roles |
A four-week preparation plan
For an experienced security engineer moving into AI security. Shift the weight toward research or governance if that is the role.
Week 1: How LLM systems work and fail
- Learn the mechanics: context windows, system prompts, tool calling, retrieval, agents and memory.
- Read the OWASP Top 10 for LLM Applications in full and map each risk to a classic vulnerability class.
- Work through the prompt injection questions until you can explain why there is no complete fix.
Week 2: Agents and tools
- Read the agentic AI security guide and the design patterns paper it cites.
- Practise the six-step design answer on the practice prompts, out loud and timed.
- Build a small agent with one tool, then attack it with indirect injection through a document it reads.
Week 3: Attack practice and evaluation
- Play public prompt injection challenges and capture-the-flag exercises, and write up each technique.
- Run an automated scanner such as garak or PyRIT against a local model, and learn to read the results as rates.
- Study the supply chain and privacy rounds: unsafe model files, poisoning, membership inference, extraction.
Week 4: Frameworks, stories and mock interviews
- Learn what MITRE ATLAS, the NIST AI RMF, ISO/IEC 42001 and the EU AI Act are each for.
- Prepare three incident or influence stories in a situation, action, result format, with at least one involving an AI system.
- Do two mock design rounds with a peer and ask them to score you against the weak, hire and strong hire lines.
What transfers from traditional security
Most of it. Threat modeling, least privilege, input and output validation, isolation, logging and incident response are exactly the tools agent security needs. The new parts are narrower than they look: accepting that one component in the system cannot be made to follow rules reliably, learning the attack classes that follow from that, and knowing enough about models to reason about training data, fine-tuning and evaluation. The glossary covers the vocabulary.