How to become an AI security engineer

There are three common starting points, and each has a different gap. Software engineers who have shipped LLM features understand the systems and need security method: threat modeling, the classic vulnerability classes and how controls fail. Security engineers have the method and need to learn how language model applications, retrieval and agents move data. Machine learning engineers know the models and usually need both the security method and the application-layer view.

Whichever you are, the route below runs in the same order. Skip a stage only if you could teach it.

AI security interviews still test classic security, and candidates who skip it fail rounds they expected to pass. Learn to threat-model a system: draw its data flows, mark its trust boundaries and say what an attacker could do at each one. Learn the web and API vulnerability classes, because model output that reaches a browser, shell or database recreates them. Learn identity well enough to explain OAuth, scoped tokens and why an agent should not run with a user's full session.

Add the cryptography an engineer uses rather than designs: what hashing, MACs, signatures and TLS each guarantee, and how code signing and certificates work. Model signing and supply chain questions build on exactly this.

You do not need to train models. You need to know what a token and a context window are, how a chat template turns system, user and tool messages into one sequence, how retrieval-augmented generation adds documents to that sequence, and how tool calling lets a model request actions that application code then runs. With that picture, every AI security risk becomes a question about which text reaches the model and which actions its output can trigger.

Learn at a high level how models are trained and aligned, because it explains why refusals are probabilistic and why jailbreaks keep working.

This is the material every AI security loop tests. Prompt injection, direct and indirect, and why it remains unsolved. Improper handling of model output and the channels data can leave through, such as rendered images and links. Access control and poisoning in retrieval. Then agents: excessive agency, the lethal trifecta, MCP and tool poisoning, human approval that people do not rubber-stamp, and design patterns that limit what injected text can do.

Learn the reference frameworks well enough to use them, not recite them: the OWASP Top 10 for LLM Applications and MITRE ATLAS.

After the core, the field branches. AI red teaming and evaluation suits people who enjoy finding failures and measuring them properly. Adversarial machine learning and privacy suits people with a maths or ML background. Supply chain security for models and data builds on software supply chain work. Governance and risk suits people who like turning frameworks such as the NIST AI RMF, ISO/IEC 42001 and the EU AI Act into controls. Pick one to go deep on; interviews reward depth in one area more than a survey of all of them.

Postings ask for evidence, not just knowledge. Anthropic's Safeguards red team posting asks for public work such as CVEs, blog posts or bug bounty findings. Write up a defensive design for a realistic agent, with its threat model and the controls you chose. Contribute to open-source evaluation tools such as garak, PyRIT or Inspect. Report issues through AI bug bounty programmes, and test only systems you own or are explicitly authorised to test.

For most working engineers studying part-time, the first three stages take months, not years. The fastest route is to practise answering out loud: a design question answered from a threat model in three minutes is the skill every loop scores.