Cyber, Risk & Internal Audit
AI Security & Assurance
The newest archetype in this atlas, and the one where the gap between demand and supply is widest. AI appears in 92% of security postings; the practice to govern it in 9%.
This role barely existed two years ago. It exists now because every organisation has shipped something with a model in it, and somebody has to answer whether that was safe. There are very few people who can, which is why a competent generalist who learns this material properly can enter it laterally — a claim that is not true of most senior security specialisms.
A day that is actually representative
| Time | What you are actually doing |
|---|---|
| 09:30 | Review an architecture for a customer-facing assistant. You are not looking at the model. You are looking at what the retrieval index contains, whether it filters by the asking user's permissions, and what the tools can write to. |
| 11:00 | Red-team a feature. Forty minutes trying indirect prompt injection through a document the agent ingests. You get it to call a tool it should not, and you write that up with the exact payload. |
| 13:30 | A model-risk committee paper. Two pages: what the system does, what happens when it is wrong, what the eval says, and what you are recommending. It will be read by people who do not write code. |
| 15:00 | Build. You are writing an eval harness that runs adversarial cases against every release, because manual red-teaming does not scale and the committee wants evidence, not anecdotes. |
| 16:30 | Advise a team that wants to fine-tune on customer records. Ten minutes of questions establishes they actually want retrieval, which is cheaper, better and does not create an erasure problem. |
A real posting, decoded — Elastic, “AI Security — Principal Security Research Engineer”, United States
Live in the corpus behind this site. Paraphrased, then translated.
| What the posting says | What it actually means | So you should |
|---|---|---|
| Research and develop detections for AI-specific threats | Detection engineering pointed at a new class of attack. You need to know what an attack on an AI system actually looks like in telemetry. | Be able to describe what indirect prompt injection looks like in logs: an unexpected tool call, an egress to an unfamiliar host, a sudden change in output shape. |
| Evaluate model behaviour under adversarial conditions | Structured red-teaming, repeatable and evidenced — not a one-off exercise. | Build an adversarial eval suite and be able to show it. This is the single most valuable artefact for this role. |
| Partner with product and engineering to define guardrails | Advisory work with delivery teams who can ignore you. | Bring a story where you replaced a blanket 'no' with a specific mitigation that let a feature ship. |
| Contribute to responsible AI and governance frameworks | You will be asked to map to NIST AI RMF, ISO 42001 or the EU AI Act. | Know which of the three is law, which is certifiable, and which is a thinking structure. Most candidates cannot separate them. |
The decisive round
“Our team wants to ship an agent that can email customers. Sign it off.”
Interviewer: “Product wants an agent that reads support tickets and replies to customers by email. Board demo is in three weeks. What do you say?”
A weak answer. “I'd want to do a full risk assessment first, and I'd have concerns about prompt injection and data leakage. We'd need to see the model card, the vendor's security documentation, and probably run it past legal before I could approve outbound customer communication.” Everything is defensible and the net effect is a three-week delay with no path to yes. This candidate will be routed around.
A strong answer. “I'd sign it off in a form that ships. The thing I actually care about is that the agent reads untrusted content — support tickets are written by strangers — and also holds a credential that can send email externally. Those two capabilities in one process is the whole risk, because a ticket containing instructions can make it act.
So: split it. The component that reads tickets gets read-only access to one queue and no send capability. The send is a separate step with a human approving the draft, at least until we have data. That is a one-sprint change, not a redesign, and it makes injection survivable rather than trying to prevent it.
For the demo I'd want three things in place: tool-call logging so we can reconstruct anything odd, an egress restriction so it can only reach our mail gateway, and about forty adversarial eval cases — tickets with embedded instructions — run before release with the results recorded. I can write those cases this week.
Then I'd tell them what I'm not worried about, because it matters: the model provider's security posture is contractually handled, and this is not high-risk under the AI Act since it's customer service rather than a consequential decision. Those two are cleared, which is why I can move fast on the one that isn't.”
The strong answer ships the product. It also demonstrates the whole book in ninety seconds: blast radius over prevention, evidence over assertion, and explicitly clearing what does not matter to earn credibility on what does.
What to build
- An adversarial eval suite. Forty cases of indirect prompt injection against a RAG or agent system you control. Score them, record a baseline, re-run on change. This one artefact answers most of the interview.
- One system you successfully attacked, written up: the payload, what it achieved, and the control that would have stopped it. Use your own build or a deliberately vulnerable one like Gandalf or an OWASP LLM Top 10 lab.
- A two-page model-risk paper for something real. Purpose, tiering, what happens when wrong, evidence, recommendation. Writing for a non-technical committee is a distinct skill and this role is half writing.
- A mapping exercise — take one system and map its controls to NIST AI RMF. Two hours, and it makes the frameworks concrete rather than abstract.
Real cases worth being able to discuss
A tribunal held the airline liable for incorrect bereavement-fare advice its chatbot gave a customer. The airline argued the chatbot was a separate entity responsible for its own statements. That argument failed.
Use it to say: “This is why I treat model output as company statement. The legal position is that we said it, which changes the review from a technical question to a controls question about what it is allowed to assert.”
Engineers pasted proprietary source code into a public chatbot; the company responded with a ban. The ban is the interesting part — it pushed usage onto personal devices rather than stopping it.
Use it to say: “It's my standard argument against prohibition. A sanctioned tool with logging and a DPA is safer than a ban, because a ban only removes your visibility.”
A dealership's website assistant was talked into agreeing to sell a vehicle for one dollar and calling it legally binding. No exploit, just an assistant with no constraints on what it could assert.
Use it to say: “This is the cheapest possible demonstration that the control belongs on what the system is allowed to commit to, not on the prompt.”
A three-week plan
Week 1 — learn the mechanism
Days 1–2: Read the AI foundations book here end to end. You need chapters 1, 5 and 6 cold — model, RAG, agents.
Days 3–4: Build a small RAG assistant over documents you control. You cannot attack what you have not built.
Day 5: Attack it. Plant instructions in a document and get the assistant to follow them.
Week 2 — make it evidence
Days 1–3: Turn your attacks into forty scored eval cases with a recorded baseline. Automate the run.
Days 4–5: Write the two-page model-risk paper for your own system, as if for a committee.
Week 3 — the frameworks and the room
Days 1–2: Map your system to NIST AI RMF. Read enough of the EU AI Act to tier a use case correctly.
Days 3–4: Rehearse the sign-off transcript above out loud, with your own system as the subject.
Day 5: Prepare the five stories: a mitigation that let something ship, an attack you found, a time you cleared a concern, a committee you convinced, a thing you got wrong.
Red flags
AI security with no engineering. If the role is questionnaire review with no build component, you will not develop the skills that make this specialism valuable, and the questionnaires will be obsolete in a year.
No relationship with the teams shipping AI. Ask who you sit with. If the answer is compliance rather than engineering, you will find out about systems after they launch.
Framework-first job descriptions. A posting that names ISO 42001 five times and never mentions a system suggests a certification project, not a security function.
Compensation
| Market | Band | Notes |
|---|---|---|
| United States | $170k – $290k base | Scarcity-priced. Frontier labs and regulated employers pay at the top |
| India | ₹30L – ₹70L total | Concentrated in GCCs of regulated multinationals — banking, pharma, insurance |
| Both | — | This is the least crowded senior security specialism in the corpus. That will not last |
What this role tests
Themes, and where to learn them
These chapters are shared across every role that tests them, so preparation here compounds rather than being spent once.
Practice questions across all themes → · Back to Cyber, Risk & Internal Audit →