Becoming an AI security engineer

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.

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

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

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.

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

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.