How to get hired as an AI security engineer in 2026-27

What an AI security engineer actually does, and which of the five jobs the posting means

The title is only a few years old, so the job behind it is not standardised and two postings with the same header can share almost no content. Before you prepare for a loop, work out which of five jobs you are applying to, because each weights the interview differently and each rewards a different artefact. Read the responsibilities, never the title.

The common core across all five is one sentence worth memorising, because it is also the answer to the opening interview question. An AI security engineer secures systems that take instructions from text nobody controls, act on them with real credentials, and cannot be made to behave deterministically. Every interesting problem in the role falls out of that: the model cannot reliably distinguish data from instruction, so authority has to live outside the model; the system is non-deterministic, so a test that passes once proves nothing and you need a measured attack suite instead; the model's output is attacker-influenced, so whatever renders or executes it is part of the attack surface.

The weekly shape, in the product-side version of the job, is less exotic than the title suggests. You read design documents for features that are two weeks from launch and write back the three things that must change. You review the pull request that adds a tool to an agent and find that the tool takes the account id from the model's text rather than from the authenticated session. You argue with a product manager about whether a refund agent needs a human click above fifty dollars. You maintain the attack suite that runs in continuous integration and explain to a team why their change moved attack success rate in the wrong direction, and by how much. You write the risk acceptance for the residual injection exposure, because it will not go to zero and someone senior has to sign that sentence. Perhaps one day a fortnight looks anything like research.

Be clear about what the job is not, because the mismatch burns screens. It is not trust and safety, which owns content policy, abuse and user harm with a largely non-engineering toolkit. It is not AI governance or AI assurance, which produces model cards, inventories and audit evidence and is hired against a GRC rubric. It is not machine learning research, and a candidate who talks mostly about adversarial examples on image classifiers reads as a decade out of date on what employers are paying to fix. And it is not prompt engineering: writing a clever jailbreak is the cheapest skill in this market and nearly every applicant has it.

• Product or feature AI security. You review the AI features your employer ships: chat assistants, copilots, agents with tools, retrieval over customer data. The interview weights threat modelling and code review. This is the most common version and the best first target if you come from application security.
• AI platform and pipeline security (sometimes posted as MLSecOps). You secure training and serving infrastructure: the model registry, the feature store, notebook environments, GPU cluster multi-tenancy, artefact signing, who can promote a model to production. The interview weights cloud identity, Kubernetes, supply chain and the dull question of who can push weights. Strongest fit if you come from cloud security or platform engineering.
• AI red team and adversarial testing. You break things on purpose, at a lab, a large technology company, a consultancy or a security vendor. The interview weights a live exercise and a written report, and the writing matters as much as the finding. Expect a portfolio requirement: they will want to read something you have already broken.
• Enterprise AI adoption security. You secure the AI your employer buys and connects rather than builds: assistant deployments across the document estate, third-party tool and connector review, agent identities in the directory, data loss paths, logging and retention of prompts. Common at banks, insurers, healthcare systems and government. The interview weights identity, data classification, vendor review and the ability to say no readably.
• Vendor side, building AI security products. You build the detection, the gateway or the posture-management product other companies buy. The interview weights software engineering more heavily and includes a real coding round. Pay is competitive and the work is narrower than the title implies.
• The recognisable tell for each: look at the first three responsibilities. Threat model and review mean variant one. Pipeline, registry and cluster mean variant two. Adversarial, evaluate and report mean variant three. Policy, inventory, connector and data loss mean variant four. Design, build and ship mean variant five.
• A warning on variant four. Some postings in this shape are a governance job with an engineering title, and you will spend the year in a spreadsheet of model inventories. That is a legitimate job and it pays, but ask in the hiring manager call what the team shipped last quarter. If the answer is a policy and a register, believe it.

The four routes in, and the half of the job each one has to fix

Almost everyone arrives with half of this job and loses the loop on the other half. Naming your half honestly, in week one, is worth more than any reading list, because the fix is different in kind and in duration.

Route A, by far the most common, is a security engineer moving across: application security, cloud security, product security, penetration testing, detection engineering. You already have the instincts the role is built on, which is the single most important thing: trust boundaries, authorization thinking, blast radius, the habit of asking who can reach this. What you are missing is mechanics, and the gap shows up in specific, catchable ways. You cannot say what a context window is in tokens, how retrieval actually selects documents, what fine-tuning changes that prompting does not, why temperature breaks your regression test, or what a guardrail model is and what it costs in latency and false refusals. Interviewers probe this not to test trivia but because without it your threat model will be confidently wrong: you will propose input sanitisation for prompt injection, which is the clearest single signal that someone has read the headlines and not the systems.

Route B is a machine learning or platform engineer moving into security. You know the mechanics cold, and you will lose the loop on fundamentals that feel beneath the title. You will be asked how you would design authorization for a tool that queries customer orders, and the answer has to include where the tenant identifier comes from and what verifies it. You will be asked what is wrong with a token, a redirect or a session, and a vague answer ends that round. The hardest part is cultural rather than technical: security engineering grades you on what an adversary can do with your design, not on whether your design works, and candidates from machine learning tend to narrate the happy path. Three to six months of deliberate web and cloud security work fixes the knowledge. The adversarial reflex takes longer and is best built by actually breaking things and writing them up.

Route C is a penetration tester or red teamer specialising into AI. The hands-on round will be your strongest and the constructive half your weakest. The prompt that catches route C is simple: fine, you got the agent to exfiltrate the key, now design the fix, and do not say sanitise the input. If your answer is a filter rather than a change in where authority lives, you will be read as a tester rather than an engineer, and the offer comes in at tester level.

Route D is GRC, audit or privacy moving in. Be honest with yourself: this is the longest road, and the shortest version of it is not a certificate. Target variant four (enterprise AI adoption security) rather than variant one, where your existing fluency in data classification, vendor review and regulatory mapping is genuinely scarce, and fix code fluency in parallel because the loop will still open a file and ask you what is wrong with it. Twelve to twenty-four months is realistic, and an internal move inside the employer you already have is much more likely than an external hire.

One structural fact beats all of this advice. Most of these roles are filled internally or from one step away, because the hiring manager is trying to find someone who can be trusted to say no to an engineering director in month two. If your current employer is standing up an AI programme, and most employers of size now are, you are already closer to the job than an external applicant with a better portfolio. Volunteer to be the person who reviews the first agent. Do it well, write it down, and you have both the experience and the reference.

• Route A fix list (security to AI), three to nine months: build and ship one small LLM application yourself, with authentication, multi-tenant retrieval and at least two tools, so that the mechanics stop being abstract. Then read the OWASP Top 10 for LLM Applications and MITRE ATLAS and map each item to something in the thing you built.
• Route A trap: proposing input filtering or an allowlist of phrases as the mitigation for prompt injection. The correct answer lives in architecture and authority, not in text inspection.
• Route B fix list (ML to security), six to twelve months: web application security to the level of being able to find broken access control in unfamiliar code, OAuth 2.x with the authorization code flow and PKCE plus OpenID Connect well enough to say what goes wrong, cloud identity in your employer's cloud, and secrets and key management. Then break something and write it up.
• Route B trap: narrating the happy path. Practise describing every design as what an attacker gets if each assumption is false.
• Route C fix list: for every finding you have ever written, write the control that removes the class, then the detection that catches it if the control fails. Publish three of those as paired findings and fixes.
• Route D fix list: aim at enterprise AI adoption security, learn one scripting language to real working fluency, and get your hands on the actual connector and agent configuration in your own tenant rather than the policy about it.
• Everyone, regardless of route: be able to say in one minute what changes about the security model when a system takes instructions from text it does not control. That sentence is the interview's organising idea and most candidates never say it.

How hiring works, stage by stage, and how it differs by employer

The loop is a security loop with two AI-specific rounds inserted, not a new kind of process. Knowing what each stage screens for tells you what to rehearse, and the two rounds people fail are predictable.

Two structural features are worth going in knowing. First, many employers have moved the exercise from a take-home to a live shared screen, for the obvious reason that a take-home about AI security is trivially completed by an AI. Expect a smaller exercise, watched, with harder questioning. Second, you will be asked how you use model assistance in your own work, and this is not a trap: the answer that lands is a working practice with a verification step attached, named tools, and one thing you no longer let it do. A flat refusal reads as unserious in this role specifically, and unqualified enthusiasm reads as someone who has not been burned yet.

The loop tests both halves of the role on purpose, and that is the design, not an accident. There will be a round that assumes you know what a model is and a round that assumes you know what authorization is. Candidates prepare one. The hiring bar is approximately: can this person sit between an AI team and a security team and be believed by both.

Employer type changes the loop more than seniority does. A frontier lab or a well-funded AI company runs the most rigorous version, often with a written exercise, a strong emphasis on measurement, and a values or mission round that is real rather than ceremonial. A large technology company runs five to seven rounds over a month, including a general security engineering round and often a classic coding round. An AI startup makes an offer in a week off two conversations and a short exercise, and the job will be AI security plus cloud security plus the compliance questionnaire plus whatever breaks. A bank, insurer or healthcare system adds background screening and a panel that cares about regulatory mapping, model inventories and third-party risk. A consultancy weights the writing sample heaviest, because the deliverable is a document a client pays for. Defence and government work is gated on clearance before any of this matters.

• Recruiter screen, 15 to 30 minutes. Keyword matching against the requisition, plus location, compensation and clearance. Have one sentence on what you do and one concrete thing you shipped or broke. Ask here which of the five variants the job is, and whether the hands-on round is a code review or a live exercise.
• Hiring manager, 45 to 60 minutes. The real filter. Expect: walk me through an AI security issue you found end to end including the fix; what did your last AI design review change; how do you handle a launch date against an unmitigated risk; what do you think is overhyped in this field. The last question is a genuine signal check and the right answer is specific, not cynical.
• Agentic threat model, 45 to 60 minutes. A system described verbally, a shared document or whiteboard, a ranked set of threats and controls expected by the end. Covered in detail below. This round decides more offers than any other.
• Hands-on round, 60 to 90 minutes live. Either a secure code review of a small LLM application or agent, or a live red-team exercise against a sandboxed target, usually ending with a written finding. Some employers run both.
• Classic security depth, 45 to 60 minutes. Authentication and authorization, OAuth and OpenID Connect failure modes, web fundamentals, cloud identity, secrets, network egress, cryptographic misuse. Route B candidates lose here.
• AI mechanics depth, 30 to 60 minutes. Tokens and context windows, embeddings and retrieval, fine-tuning against retrieval against prompting, what a guardrail or classifier model is, how an eval set works, why non-determinism changes testing, what an agent loop and a tool call actually are, what the Model Context Protocol is and what it exposes. Route A candidates lose here.
• Coding round where the employer builds tooling, 45 to 60 minutes. Usually Python. Usually practical: parse these logs, build a small harness that replays an attack set, correlate tool calls to a session.
• Writing exercise at labs, consultancies and some large companies. A one-page threat model or a finding write-up, sometimes as a take-home with an explicit assistance policy. Follow that policy literally and say what you used if asked.
• Influence or cross-functional round. How you get a mitigation landed without authority, how you word a risk acceptance, how you tell a product team their launch needs a human in the loop. Prepare three stories with the decision in each, not the outcome.
• Ask the assistance policy before any exercise. Some employers want you unassisted, some want you to work as you normally would and declare it, and some moved to live rounds precisely to stop having the conversation. Guessing is an avoidable way to lose an offer.

The agentic threat model round, worked end to end

This is the round that decides the job, so rehearse it until it is boring. The prompt is some version of: we are shipping an agent that reads inbound customer support tickets, can look up orders, search our knowledge base, and issue a refund, and it drafts replies that a human support agent sends. Threat model it. You have roughly 40 minutes and the grader is watching your process, not collecting a list.

Spend the first five minutes asking questions, and ask about money, data and reversibility rather than about technology. Who can create a ticket, and does that include anyone on the internet. What identity do the tools run as: the agent's own service account, or the support agent who is in the loop. Is the refund synchronous and irreversible, and is there a cap. Does order lookup take an order id or a customer identifier, and where does that value come from. Is the knowledge base single-tenant. Does anything render the model's draft as HTML or markdown, and can it contain a link or an image. Where do prompts and completions get logged, who can read that store, and for how long. What is the worst single loss you can imagine from this feature. Those questions alone put you ahead of most candidates, because most start drawing immediately.

Then draw the flow and mark exactly one thing first: the boundary where untrusted text enters the model's context. In this system it is the ticket body, and that is the whole game. A customer writes the ticket, so an attacker writes part of the prompt. Say out loud that from the model's point of view there is no reliable distinction between the instruction you wrote and the instruction the attacker pasted, and that you are therefore going to treat the model as a confused deputy and design the controls around it rather than inside it. The framing that has stuck in the field, usually credited to Simon Willison, is the lethal trifecta: access to private data, exposure to untrusted content, and a way to communicate outward. This system has all three legs, and your job is to remove or bound at least one of them on every path that matters.

Now walk the threats and rank them by who can reach them and what is lost, not by cleverness. The ranked top of the list should be: an instruction in a ticket body causes a refund to an attacker-chosen destination (reachable by anyone, direct financial loss); the order lookup tool accepts an identifier supplied by the model, so an injected ticket reads another customer's order history (reachable by anyone, cross-tenant data loss, likely reportable); exfiltration outward, where injected text makes the draft contain a link or image pointing at an attacker host with another customer's data in the query string, and the support console fetches it or the human clicks it; the prompt and completion log becomes an unclassified copy of customer personal data with wider access and longer retention than the ticket system it came from; cost and availability abuse through long inputs and loops; and the knowledge base as a poisoning target if anyone outside a small group can edit it. Say which of these you cannot assess from what you were told.

Controls are where mid separates from senior, and the rule is that a control must be a property of the system rather than something a future engineer has to remember. Take the authority out of the model: the refund tool receives the order id and the destination from the authenticated ticket record, server-side, and ignores anything the model says about either, so the model's only influence is the decision to call it. Bound the loss: a hard server-side cap per refund and per day, and a human click required above a threshold, enforced by the API and not by the prompt. Scope every tool call to the tenant from the ticket record at query time, not by filtering results afterwards. Close the outward leg: deny-by-default egress from the tool runtime, no fetching of model-supplied URLs, and render drafts as plain text with links stripped or explicitly reviewed. Classify the prompt log at the same level as the ticket store, with the same retention and the same access controls, and scrub it. Cap tokens, steps and spend per session. Then give the detection: alert on a refund issued without a matching human confirmation event, on tool-call sequences the design does not expect, and on retrieval that returned a document outside the ticket's tenant. Finish with the eval: a fixed suite of injection attempts for this feature running in continuous integration with attack success rate tracked per release, plus a rotating held-out set so the suite does not become the thing you optimise against.

Close by accepting a risk out loud, because that is the sentence that reads as senior. Something like: prompt injection on the ticket path cannot be eliminated, so I accept residual injection risk on the read-only low-value tools, bound it to a bad draft that a human reads, and I do not accept it on the refund path, which is why the cap and the confirmation are non-negotiable and why I would hold the launch over them. Then name what you want logged so that an incident can be reconstructed. The three most common failures in this round are a diagram with no boundary marked, an unranked list of threats, and a mitigation plan that amounts to better prompting and a filter.

• Open with five questions about money, data, reversibility, tenancy and rendering. Not about which model or framework they use.
• Mark the untrusted-text boundary explicitly and say the word deputy. The model holds credentials and takes instructions from strangers.
• Rank by reachability and loss. Defend your top two and say what you cannot assess from the information given.
• Never let the model supply a parameter that determines who or what an action affects. Identifiers come from the authenticated context.
• Bound irreversible actions with server-side caps and a human confirmation, and say plainly that the prompt is not an enforcement point.
• Close one leg of the trifecta on every path: private data, untrusted content, outward communication. Removing the outward path is usually the cheapest.
• Treat prompt and completion logs as a new personal data store with its own classification, retention and access review. Interviewers notice when a candidate remembers this.
• End with a measured eval and a detection, then accept a residual risk in one sentence and name the thing you would hold the launch for.

The hands-on round: reviewing an LLM application, or breaking one live

The hands-on round comes in two shapes and some employers run both. The code review version hands you a few hundred lines of an agent or retrieval application, usually Python, usually with a framework you have seen, and asks what is wrong with it. The red-team version gives you a sandboxed target, a goal such as make the agent reveal the contents of a file it should not read or get it to call the payment tool, and between 45 and 90 minutes, ending in a written finding. Both are graded on process far more than on the count of issues found.

In the code review version, the planted flaws are drawn from a stable set. Retrieval that queries a shared index with no tenant predicate, or that filters results after retrieval instead of scoping the query. A tool whose parameters come straight out of the model's output and into a subprocess, a file path, an SQL string or an HTTP request. Generated code passed to eval or exec outside a sandbox. A system prompt holding a secret, or holding the authorization rule as a sentence of English. A tool description loaded from a third-party or remote source, so the thing that instructs your model is controlled by someone else. The response rendered as HTML or markdown with attacker-influenced links and images intact. An agent loop with no step, token or cost ceiling. A model artefact loaded from a user-supplied path in a format that deserialises arbitrary objects. No logging of tool calls, so an incident cannot be reconstructed. And a guardrail that is a regular expression or a keyword list, often with a comment above it claiming it blocks jailbreaks.

There will also be deliberate decoys, and calling them critical costs you. A low temperature setting is not a security control, but it is not a vulnerability either. A system prompt that is visible is usually not a finding worth a release hold, and saying so, with the reason that a system prompt is not a secret boundary, scores. Using a hosted model rather than a local one is a procurement question. Candidates who rate everything critical get read as someone engineering teams will learn to ignore, which is the most expensive reputation in this job.

Grading, as hiring managers describe it, follows a pattern. Did you ask about context before reviewing: who the users are, whether the data is multi-tenant, what the tools can do. Did you find the authority bug, meaning the one where the model decides something it should not. Did your severity reasoning mention reachability and loss rather than vulnerability class. Were your fixes controls rather than patches. Did you notice the missing observability, which most candidates do not. And would the way you phrased the feedback make the author defensive. Finding four issues with clean reasoning and systemic fixes beats finding eight and ranking them all critical.

In the red-team version, the mistake is to go straight to prompt tricks. Start by mapping what the agent can do, because the attack is almost always through a tool rather than through clever phrasing: list the tools, look for one that fetches, reads, writes or spends, and find out what reaches the model's context from outside your own messages. Try indirect injection before direct: plant the instruction in a document, a ticket, a filename, a web page, an image caption, wherever the system ingests content, because direct injection in your own chat turn is both the easiest to filter and the least interesting finding. Then chain it to something that leaves the system, which is where a real finding lives. And instrument yourself: keep the exact transcript, note how many attempts a technique needed, and when you have it working, run it three times, because a one-shot success against a non-deterministic system is an anecdote and interviewers know it.

The write-up is scored and most candidates rush it. A good one is short and has six parts: what the system is and which boundary failed; the reproduction, with the exact inputs and the success rate across attempts; what an attacker gets, in terms of data, money or access; the severity argument, naming reachability, prerequisites and blast radius; the fix at the level of a control, with the instance-level patch mentioned second; and what you would detect if the control fails. If you only have 10 minutes left, write that rather than find one more bug.

To practise this before anyone tests you, build the target yourself and break it, which teaches more than any range. Public practice does exist, and prompt-injection puzzle games and the HackAPrompt competition data are worth an evening to calibrate what phrasing does, but they train the cheap half of the skill. The expensive half is chaining an injection to a tool with real side effects, and you can only get that on a system you own or one you have written permission to test.

• Ask three context questions before reading the first line: who the users are, whether data is multi-tenant, what the tools are allowed to do.
• Find the authority bug first. Trace every tool parameter back to where it came from and flag anything the model decided that affects who or what is touched.
• Check retrieval for tenancy at query time, not post-filtering, and check whether the documents in the index carry the permissions of their source system.
• Check what consumes the output: a shell, a database, an HTML renderer, a browser, another agent. Model output is untrusted input to all of them.
• Check for a budget: steps, tokens, spend, wall clock. Unbounded agent loops are both an availability and a cost finding.
• Check what gets logged, who can read it, and how long it lives. Prompt and completion logs are usually both a gap and a liability in the same file.
• Say plainly which findings are not findings, and why. A visible system prompt is the most common decoy.
• In the live exercise, prefer indirect injection through ingested content over clever direct phrasing, and chain to something that exits the system.
• Measure your own attack: attempts, success rate across at least three runs, and what changed between the failures and the success.
• Reserve the last 10 minutes for the write-up. Boundary, reproduction with success rate, impact, severity argument, control-level fix, detection.
• Never test a production AI system you do not have written permission to test, including a vendor's public chatbot. Read the current scope page first, every time.

The technical ground the interview actually covers

This section is the study list, ordered by how often it comes up rather than by how interesting it is. Nothing here is exotic, which is itself the point: most of the role is ordinary security applied to an unfamiliar substrate, plus a small number of genuinely new problems.

Retrieval tenancy is the broken access control of AI security, and it is where real incidents cluster. Documents get indexed into a vector store stripped of the permissions they had in their source system, so an assistant answers a question using a file the asker could never have opened. Ask about it in every design review and look for it in every code review. The correct control is that retrieval is scoped by the caller's identity at query time, through a predicate the query cannot omit, and that the index records the source permissions rather than a copy of the text alone. Post-filtering is a bug, because the model has already seen the content by the time you filter.

Agent identity and authority is the other load-bearing area. Know the difference between an agent acting as its own service principal and an agent acting on behalf of a user, and be able to argue for which one a given feature needs and what each costs. Know why long-lived credentials in an agent runtime are worse than they look (the agent is reachable by attacker-influenced text, so its credentials are effectively internet-adjacent), and be ready with short-lived scoped tokens, per-tool scopes rather than one broad role, deny-by-default egress, a sandbox for anything that executes, and a human confirmation on irreversible actions. On the last one, have a view on where the threshold goes and why, because the product manager will push.

The supply chain has three parts and candidates usually know one. Model weights: formats that deserialise arbitrary objects on load are a remote code execution primitive, which is why the safer tensor-only formats exist and why loading weights from an untrusted source is a code execution decision, not a download. Model provenance and signing, and whether your registry can tell you which artefact is running in production and who approved it. Third-party tools and connectors, which in practice now means Model Context Protocol servers: the tool descriptions are instructions to your model, so a server you do not control is an injection channel, an update to a server you trusted yesterday is unreviewed code today, and the tokens those servers hold are a concentrated credential store. Add the dependency problem where assistants confidently recommend package names that were never published and attackers register them, a pattern the field has taken to calling slopsquatting.

Evaluation is the part that separates people who can hold the job from people who can pass the interview. If you cannot measure a control you cannot claim it works, and in a non-deterministic system a demonstration is not a measurement. Be able to describe an attack suite: a fixed set per feature so you can compare releases, a held-out rotating set so you do not optimise against your own tests, attack success rate as the primary metric, false refusal rate as the cost you pay for lowering it, per-release tracking in continuous integration, and a human review of a sample because automated graders drift. Know the open tooling by name and ideally by use: garak, PyRIT, promptfoo, the Adversarial Robustness Toolbox, model scanners for weight files, and whichever gateway your target employer runs. Naming one tool you have actually run beats listing six.

Frameworks and regulation come up more at regulated employers than at labs, and the trick is to be useful rather than encyclopaedic. Know MITRE ATLAS as the tactic and technique vocabulary for AI attacks, the OWASP Top 10 for LLM Applications and the wider OWASP generative AI work including its agentic threat material, the NIST AI Risk Management Framework with its generative AI profile, the NIST taxonomy of adversarial machine learning, ISO/IEC 42001 for an AI management system, and the joint CISA and NCSC guidelines for secure AI system development. On the EU AI Act, know the shape of the obligations rather than the calendar: duties on providers of general-purpose models and heavier duties on high-risk uses, covering governance of training and validation data, technical documentation, record keeping, human oversight, robustness and cybersecurity. Do not quote an application date from memory. That timetable has been amended since the Act entered into force, several US state AI laws have had their effective dates moved after passage, and a candidate who states a deadline confidently and wrongly in an interview has damaged the one impression that matters. Say the obligation, then say you would check the current date before relying on it. That reads as rigour, not ignorance.

Finally, keep the classic adversarial machine learning material in proportion. Model extraction, membership inference, training data extraction, data poisoning and backdoored weights are real, and you should be able to define each and say who actually bears that risk. For most employers, who are consuming a hosted model rather than training a frontier one, these sit below injection, tenancy and agent authority. If you lead with them you will sound like you prepared for an older version of this field. At a lab, a model provider or a company training on sensitive data they move up the list, and poisoning of a fine-tuning set or of a retrieval corpus is a live concern worth real preparation.

• Prompt injection, direct and indirect, and why detection is a mitigation rather than a fix. Be able to explain the data-instruction confusion in two sentences without jargon.
• The lethal trifecta as a design test: private data, untrusted content, outward communication. Apply it to every feature you are shown.
• Retrieval tenancy: query-time scoping, source permissions carried into the index, no post-filtering, and what a shared embedding store leaks.
• Agent authority: service principal against on-behalf-of, per-tool scopes, short-lived credentials, deny-by-default egress, sandboxed execution, human confirmation thresholds for irreversible actions.
• Output handling: model output is untrusted input to shells, SQL, HTTP clients, HTML renderers, browsers and other agents. Markdown and image rendering are exfiltration channels.
• Tool and connector supply chain, which in practice means MCP server review: who wrote the tool descriptions, what tokens the server holds, what happens when it updates, and whether your model can be instructed by a third party.
• Model artefact supply chain: deserialisation-unsafe weight formats as code execution, signing and provenance, registry access control, who can promote a model.
• Pipeline and platform security: notebook environments with production credentials, feature store write access, GPU cluster multi-tenancy, and ML platform components that ship with no authentication by default, the Ray cluster and dashboard being the best known example and one reported as exploited in the wild for cryptomining.
• Inference-time abuse: cost-based denial of service, sometimes called denial of wallet, unbounded context and loops, per-tenant rate and spend limits, and key leakage from clients.
• Measurement: attack success rate, false refusal rate, fixed and held-out attack sets, per-release tracking, sampled human review. Tools: garak, PyRIT, promptfoo, the Adversarial Robustness Toolbox, weight scanners, your employer's gateway.
• Classic security that will be examined anyway: OAuth 2.x and the authorization code flow with PKCE, OpenID Connect, token validation, session handling, cloud IAM, secrets management, network egress control, container and sandbox isolation.
• Frameworks worth naming: MITRE ATLAS, the OWASP Top 10 for LLM Applications and the OWASP agentic work, the NIST AI Risk Management Framework and its generative AI profile, the NIST adversarial machine learning taxonomy, ISO/IEC 42001, and the CISA and NCSC secure AI development guidelines.
• Adversarial machine learning, kept in proportion: extraction, membership inference, training data extraction, poisoning, backdoors. Define them, know who bears the risk, do not lead with them unless the employer trains models.

The resume, the portfolio, and what gets ignored

Resumes for this role are read by a security hiring manager, often in under a minute, looking for one thing: evidence that you have made a judgement call about an AI system and been right. Everything else on the page is context for that.

Write bullets that name the system, the decision and the consequence. Not responsible for AI security reviews, but reviewed the AI feature designs shipped last year and blocked two launches, one for cross-tenant retrieval and one for an agent with unbounded refund authority. Not improved guardrails, but built the injection test suite that runs on every release of the assistant, and give your own attack count, your own before-and-after attack success rate and the false refusal cost you accepted. Use your real numbers or no numbers: if you do not have the measurement, describe the artefact and the decision instead, which reads as honest and is checkable in conversation. An invented metric dies in the first follow-up question and takes the rest of the resume with it.

The portfolio question is unavoidable from outside, because a title this new has no accepted credential and the manager has to substitute something. One artefact is enough if it shows judgement rather than enthusiasm, and the ranking is fairly consistent: a disclosed and fixed vulnerability in an AI product or framework, with the reproduction and the patch, sits at the top. Then a published threat model of a real, documented AI system, which is the cheapest high-signal artefact available because it costs nothing but thought and is exactly what the hardest round tests. Then an attack suite with measured before-and-after results, which demonstrates the skill most teams are short of. Then a tool other practitioners use, a verified bounty record on an AI vendor's programme, or a placement in a public AI red team or jailbreak event. Several AI companies run both a conventional vulnerability programme and a separate model-safety or jailbreak programme with different rules, so read the current scope on the vendor's own page before you touch anything, and never test a production AI system you have no permission to test.

What gets ignored, and in some cases counts against you: a long certificate list with no artefact; prompt engineering as a skill line; a screenshot of a jailbreak in a chat window with no impact argument; passionate about AI safety and alignment as a summary line, which reads as a different job; a list of frameworks you have read rather than applied; and the word leveraged. Hiring managers for this role see a very high volume of applicants whose entire evidence is that they have used a chatbot a lot.

On keywords, match the posting's own vocabulary wherever it is honestly true of you, because the first pass is often automated and this field has three names for everything. If the posting says LLM security, write LLM security rather than only generative AI security. If it says red teaming, use that phrase. Keep both spellings of threat modelling where you can do it naturally, and include the specific tool and framework names you have actually used, because those are what a recruiter searches on.

• Lead with the decision, not the duty. Blocked, found, bounded, measured, designed. Each bullet should contain a system, an action and a consequence.
• Use real numbers or no numbers. Attack counts, review counts, success rates and spend caps are all legitimate if you can defend them in the follow-up question.
• Put one artefact in the top third of the page with a link. A published threat model is the cheapest one to produce and maps directly onto the round that decides the job.
• Name tools you have run, not tools you have heard of: garak, PyRIT, promptfoo, Semgrep, Burp Suite, a specific gateway, a specific cloud's AI platform, a specific vector store.
• Name frameworks you have applied to something: ATLAS techniques used in a test plan, OWASP LLM items mapped to findings, an ISO or NIST control you implemented.
• Keep the classic security spine visible. Authorization, identity, cloud IAM, code review, incident response. A pure AI resume with no security fundamentals reads as route B and gets screened for the round you will fail.
• Drop: prompt engineering, passionate about AI safety, leveraged, synergy, a certificate list without an artefact, and any jailbreak screenshot without an impact argument.
• For internal moves, write the same resume anyway and send it to the hiring manager with a one-paragraph note naming the first thing you would review. Internal candidates who do this get the conversation.
• Keep a two-page version for consultancies and labs that ask for writing, and attach the written artefact rather than describing it.

Where the jobs are, what to search, and a 12-week plan

Demand for this role is concentrated rather than broad, which matters for how you search. The clusters are: frontier labs and large AI companies, which hire the deepest version of the role and have the highest bar; the large cloud providers, which are securing the AI platforms everyone else builds on and hire in volume; AI-native product companies past their first funding, which hire one or two generalists who do everything; security vendors building AI security products; large regulated enterprises standing up an AI programme, which is the fastest-growing source of openings and the least glamorous work; consultancies and boutique AI red team shops, which hire for writing and client presence as much as for depth; and defence, government and national security, gated on clearance. Postings also hide inside existing teams: a platform security team that picked up the AI platform, a product security team that picked up the copilot.

Search on the work, not the title, and keep an alert running on each phrase because these postings fill fast. Useful strings: AI security engineer, AI/ML security, GenAI security, LLM security, model security, AI red team, adversarial testing, AI safeguards, agent security, MLSecOps, and security engineer combined with agent or inference or model registry. Then read the responsibilities for which of the five variants it is and which half of the loop will be heavy.

On pay, resist the urge to anchor on a number from a forum. There is no occupation code for this title, so the honest sources are the ones you can open: BLS OES 15-1212 for information security analysts as a floor and sanity check, 15-1221 for research-flavoured lab roles, and the published ranges on postings in jurisdictions with pay transparency rules, including Colorado, California, New York, Washington and Illinois. The useful comparison is internal: for the same employer, this role generally pays at or above its senior security engineer band, and at labs and large technology companies a large share of total compensation is equity whose value you should discount rather than assume. When a recruiter asks for your expectation, name the band from their own published posting if there is one.

Here is a 12-week plan that produces interviews rather than a reading list. It assumes six to ten hours a week and it is built around producing two artefacts, because artefacts are what get you screened in.

• Weeks 1 and 2: name your weaker half and start there. Route A builds a small multi-tenant retrieval application with real authentication and two tools. Route B works through web authorization and OAuth failure modes until finding broken access control in unfamiliar code is routine.
• Weeks 3 and 4: make your own application vulnerable on purpose and break it. Indirect injection through an ingested document, a tool that takes an identifier from the model, retrieval without a tenant predicate, output rendered with a live link. Keep the transcripts.
• Weeks 5 and 6: build an attack suite against it. Run garak or PyRIT or promptfoo, define categories, record attack success rate, add one mitigation at a time, and record what each mitigation cost you in false refusals. This is the single most employable artefact in the list because most teams cannot do it.
• Weeks 7 and 8: write and publish a threat model of a real, documented AI system, using only public documentation. Pick something specific, such as a named vendor's coding agent or a cloud provider's agent service. Mark the untrusted-text boundary, rank the threats, propose control-level mitigations, accept a residual risk. One to three pages, no hedging.
• Weeks 9 and 10: get one external data point. A finding in an in-scope bounty programme, a contribution to OWASP generative AI material or an ATLAS technique, a pull request to an open source AI security tool, or an entry in a public red team event. Read the current scope rules before you test anything.
• Weeks 11 and 12: convert. Inside your employer, send the hiring manager of the AI programme your threat model and offer to review the next feature. Outside, apply to 15 to 25 postings across at least three of the clusters, with the artefact linked in the top third of the resume.
• Running through all 12 weeks: 30 minutes a week on the frameworks (ATLAS, the OWASP LLM top ten, the NIST generative AI profile) and 30 minutes a week reading incident write-ups, because concrete incidents are what you will reach for in every interview answer.
• Rehearse the threat model round out loud, with a timer, against three different systems: an agent that spends money, an assistant over an internal document estate, and a coding agent with repository write access. Say the words trust boundary, reachability, blast radius, residual risk and detection in every run until they are automatic.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• AI security
• AI security engineer
• AI/ML security
• LLM security
• GenAI security
• Generative AI security
• Machine learning security
• Model security
• Agent security
• Agentic AI security
• MLSecOps
• AI red teaming
• Red team
• Adversarial testing
• Adversarial machine learning
• Prompt injection
• Indirect prompt injection
• Jailbreak
• Jailbreak resistance
• Guardrails
• Guardrail evaluation
• Safety classifier
• Output handling
• Insecure output handling
• Excessive agency
• Confused deputy
• Data exfiltration
• Retrieval augmented generation
• RAG
• RAG security
• Vector database
• Embedding store
• pgvector
• Pinecone
• Weaviate
• Qdrant
• Milvus
• Multi-tenancy
• Tenant isolation
• Permission inheritance
• Document ACLs
• Broken access control
• Authorization
• Authentication
• OAuth 2.0
• OpenID Connect
• PKCE
• Token validation
• Session management
• Identity and access management
• Cloud IAM
• Least privilege
• Short-lived credentials
• Workload identity
• Secrets management
• Egress control
• Network segmentation
• Sandboxing
• Container isolation
• gVisor
• Firecracker
• Model Context Protocol
• MCP
• MCP server review
• Tool poisoning
• Tool calling
• Function calling
• Supply chain security
• Software bill of materials
• SBOM
• AI bill of materials
• Model provenance
• Model signing
• Sigstore
• Safetensors
• Pickle deserialization
• Model scanning
• Slopsquatting
• Dependency confusion
• Data poisoning
• Backdoored models
• Model extraction
• Model inversion
• Membership inference
• Training data extraction
• Model theft
• Denial of wallet
• Rate limiting
• Cost controls
• Threat modelling
• Threat modeling
• STRIDE
• Trust boundary
• Data flow diagram
• Design review
• Secure code review
• Security architecture review
• Risk acceptance
• Blast radius
• Detection engineering
• Tool call logging
• Audit logging
• Incident response
• MITRE ATLAS
• OWASP Top 10 for LLM Applications
• OWASP GenAI Security Project
• OWASP Machine Learning Security Top 10
• NIST AI Risk Management Framework
• NIST AI 600-1
• NIST adversarial machine learning taxonomy
• ISO/IEC 42001
• ISO/IEC 23894
• CISA NCSC secure AI guidelines
• EU AI Act
• AI governance
• AI assurance
• Model cards
• Model registry
• MLflow
• Feature store
• Kubernetes
• Ray
• Hugging Face
• Amazon Bedrock
• Azure AI Foundry
• Google Vertex AI
• LangChain
• LangGraph
• LlamaIndex
• LLM gateway
• AI security posture management
• AI-SPM
• garak
• PyRIT
• promptfoo
• Adversarial Robustness Toolbox
• NeMo Guardrails
• Llama Guard
• Semgrep
• Burp Suite
• Python
• Attack success rate
• False refusal rate
• Evaluation harness
• Held-out test set
• Continuous integration
• Bug bounty
• Vulnerability disclosure
• Penetration testing
• Security clearance

Mistakes that cost people this job

Questions people ask