Key takeaways
- Deepen the half you already have — almost nobody arrives with both security and AI system knowledge.
- Learn deployment, not training. The attack surface is in context assembly, tools, output and credentials.
- Build one system first; you cannot reason about misuse of an architecture you have never assembled.
- A written assessment in professional report form is the most persuasive artefact available to you.
- Interviews test structured reasoning about trust boundaries, not memorised jailbreak strings.
Start from whichever half you already have
This role sits at the intersection of security thinking and AI system knowledge. Almost nobody arrives with both, and the sensible move is to deepen the half you have rather than restarting.
From a security background, you already know how to think about trust boundaries and misuse. What you are missing is a concrete picture of how these systems are assembled. From an engineering background, you know the assembly; what you are missing is the discipline of asking how it breaks on purpose.
The security half is the harder one to acquire, which is worth knowing if you are choosing where to invest. Learning how a retrieval pipeline works takes weeks; developing the instinct to ask who else can reach this takes considerably longer.
Learn how the systems are built, not how models are trained
The most common misdirection is spending months on model training. It is interesting and almost never relevant. The attack surface lives in deployment: how context is assembled, what tools the model can call, where output ends up, and which credentials are in play.
Build a small retrieval-augmented system with at least one tool that has a real effect. You need the builder’s view before the attacker’s view is worth anything, because you cannot reason about misuse of an architecture you have never assembled.
Pay particular attention to the seams. Every point where text from one trust level meets text from another is a place something can go wrong, and those seams are invisible in an architecture diagram but obvious once you have wired one up yourself.
- Assemble a retrieval pipeline end to end and read the final rendered context
- Give an agent a tool that writes somewhere, then reason about who can trigger it
- Trace one request from user input to model call to side effect
- Note every place text from one trust level meets text from another
Then learn the specific attack classes
Once you can build one, study how they fail. The categories are reasonably stable now, and each has a clear underlying mechanism rather than being a bag of tricks.
Work through them practically on your own system. Reading about indirect prompt injection is abstract; watching your own agent follow instructions planted in a document you retrieved is not, and it is the moment the threat model becomes intuitive.
Learn the mechanism rather than the payload. Specific jailbreak strings stop working within weeks and are worthless in an interview; understanding why a model cannot distinguish your instructions from instructions inside data you supplied is permanent.
- Direct prompt injection — the user instructs the model against its operator
- Indirect injection — instructions arrive inside retrieved or fetched content
- Excessive agency — the model can invoke more than the task requires
- Sensitive disclosure — context or system instructions leak into output
- Insecure output handling — generated text reaches a shell, query or renderer
- Supply chain — weights, adapters and packages of uncertain provenance
Get the security fundamentals if you lack them
Engineers moving in often skip this and it shows in interviews. AI-specific attacks sit on top of ordinary ones — authentication, authorisation, secrets handling, logging, least privilege. An agent with an over-scoped API key is a credentials problem before it is an AI problem.
You do not need a certification, though one helps if your CV lacks security signal. What you need is to be able to threat model a system out loud, coherently, when asked.
A useful self-test: describe an ordinary web application and enumerate what could go wrong at each boundary without reaching for a checklist. If that feels hard, the fundamentals are the gap, and no amount of AI-specific knowledge will cover for it.
| Starting from | Spend most time on | Skip for now |
|---|---|---|
| Application security | Building a RAG system with tools | Model training and architectures |
| Backend engineering | Threat modelling, least privilege, authz | Fine-tuning, embeddings theory |
| SOC / detection | How agents and tools are wired | Offensive tooling for web apps |
| Compliance / audit | Concrete system walkthroughs | Hands-on exploitation |
| Neither half | General security fundamentals first | Everything AI-specific |
Build evidence, because credentials do not exist yet
With no established qualification, hiring rests on demonstrated capability. The highest-leverage artefact is a written security assessment of a system you built or were permitted to test: what you looked at, what you found, why it mattered, what you would change.
Keep it honest and scoped. A three-page assessment of a deliberately small system, written the way a professional report is written, reads as far more credible than a long list of tools you have opened. Only ever test systems you own or have explicit written permission to test.
Include the findings that were not exploitable as well as the ones that were. Saying that you attempted something, it failed, and here is the control that prevented it demonstrates the same reasoning and signals that you are not overstating results — which is exactly what a security hiring manager is checking for.
- A written assessment of your own system, in professional report form
- A reproducible demo of indirect injection and the control that stops it
- A short threat model diagram for an agent with tool access
- Contributions to an open-source AI security project, however small
What interviews actually test
Expect a system to be described and to be asked how you would attack it, then how you would defend it. Interviewers are listening for structured reasoning about trust boundaries, not for memorised jailbreak strings, which date within weeks.
The strongest answers separate the layers: what the model can be talked into, what the surrounding system permits regardless, and which control belongs where. Candidates who say "the real fix is that the tool should never have had that permission" tend to progress.
Expect at least one question about proportionality. Recommending that everything require human confirmation is as unhelpful as recommending nothing, and interviewers are checking whether you can rank risks rather than enumerate them.
Frequently asked questions
Do I need a degree or certification to become an AI security engineer?
No established qualification exists yet. A general security certification helps if your CV shows no security background, but demonstrated capability — a written assessment, a reproducible finding — carries more weight in interviews.
How long does it take to move into AI security?
From a security or engineering background, several months of focused work is realistic because you are adding one half rather than both. Starting from neither, plan on longer and build general security fundamentals first.
Should I learn to train models first?
No. Almost all of the attack surface is in deployment — context assembly, tool permissions, output handling and credentials. Training knowledge is interesting but rarely used in the role.
How do I practise AI attacks legally?
Build your own system and attack that, or use platforms that explicitly invite testing. Never test a system you do not own without written permission — unauthorised testing is a criminal matter regardless of intent.
Is it worth memorising jailbreak techniques?
No. Specific payloads stop working within weeks. Understanding why a model cannot separate your instructions from instructions inside supplied data is what lasts and what interviews test.
Which half is harder to acquire?
The security instinct. Learning how a retrieval pipeline works takes weeks; developing the habit of asking who else can reach this takes considerably longer.
Further reading
Check this against your own resume
Scan your CV against a real job description, or build a parse-safe one from scratch. Your first scan costs nothing.