AI security jobs, mapped

Postings for "AI Security Engineer" describe at least three roles with different daily work and different hiring bars. Reading which one a company means is the first filter to apply, because preparing for the wrong one wastes the interview.

The confusion is understandable — the field is young and titles have not settled. But the skills barely overlap, and a candidate who prepares for adversarial testing and is interviewed on cloud controls will not do well.

The reliable tell is in the responsibilities rather than the title. Mentions of red teaming and agent permissions indicate the first; alert triage and detection indicate the second; policy, audit and evidence indicate the third.

• Securing AI systems — protecting models, prompts, context and tool access from misuse
• AI for security — applying models to detection, triage and response in a SOC
• Governance and assurance — policy, risk assessment, audit and compliance evidence

This is the most technical of the three and the closest to application security. The work is reasoning about a system that takes instructions from untrusted text and can invoke real actions, then finding the paths where that goes wrong.

The novel part is that the attack surface includes content. A document your retrieval system ingests can carry instructions. An email your agent summarises can attempt to redirect it. Conventional input validation assumes data and instructions are separable, and here they are not.

That single property is what makes the role genuinely new rather than a rebranding. Every other control you know still applies; what changes is that you can no longer sanitise your way out, because the malicious content and the legitimate content are the same kind of thing.

• Prompt injection, direct and indirect through retrieved content
• Tool and agent permission scoping, and confirming irreversible actions
• Data leakage through context windows and logs
• Model supply chain — weights, adapters and third-party components
• Output handling where generated text reaches a shell, query or browser

This role sits inside a security team and uses models to reduce alert volume, draft incident summaries and accelerate triage. The centre of gravity is security operations experience; the AI is a tool applied to a problem you already understand.

Hiring managers here screen for detection engineering and incident response first. Candidates who lead with model knowledge and cannot discuss how an alert becomes an investigation tend not to progress.

It is also the variant with the clearest measurable value, which makes it easier to justify internally. Reducing time-to-triage on a queue nobody can keep up with is a number a security leader can take to a budget conversation.

As AI regulation has firmed up, organisations need people who can document what a system does, assess its risks and produce evidence an auditor accepts. This is closer to GRC than to engineering, and it is hiring steadily in regulated sectors.

It suits people with audit, risk or compliance backgrounds who have learned enough about model behaviour to ask useful questions. Deep engineering is not required; the ability to write precisely and hold a position under pressure is.

The demand here is less cyclical than the engineering roles, because it is driven by obligation rather than by product ambition. Where a regulator requires documented assessment, that work happens regardless of whether the AI programme is going well.

Treat any specific figure sceptically — the sample is small and the titles are inconsistent. The pattern that holds is that AI security roles sit at or slightly above equivalent-seniority application security roles at the same company, and the premium comes from scarcity rather than from the work being harder.

That premium will compress as supply catches up, which argues for entering on genuine capability rather than on title arbitrage. The durable position is being a strong security engineer who also understands these systems, not someone whose only asset is being early.

Sector matters more than the AI label. Finance, healthcare and defence pay a premium for security work generally, and that differential is larger than the difference between an AI security role and a conventional one at the same employer.

Worth setting expectations: a large share of this work is not adversarial testing. It is reviewing designs before they are built, arguing for narrower tool permissions, and explaining to a product team why the mitigation they proposed is a prompt instruction rather than a control.

The genuinely adversarial portion is smaller and concentrated in specific weeks. Most of the time you are the person asking what happens if this document contains instructions, and being the only one in the room who thinks that question is urgent.

That makes communication a larger part of the job than the title suggests. A finding nobody acts on has no value, and in a field where most engineers have not yet internalised the threat model, the persuading is frequently harder than the finding.

From security, you already have the mental model; add hands-on familiarity with how these systems are built. From engineering, you have the build knowledge; add structured threat modelling and the habit of thinking about misuse rather than use.

Either way the evidence that travels is a written finding: a system you tested, what you found, why it mattered, what you recommended. One clear write-up outperforms a list of courses on a CV.

The fastest internal route is to become the person who reviews AI features at your current employer. Almost every organisation is shipping something and almost none has assigned anyone to look at it, so the role frequently exists before anyone has written a job description for it.