Skip to content
SkillPilotNavigate Your Career

AI Security Engineer Roadmap

A defensive security path for engineers who secure LLM and agent systems, covering AI threat modelling, prompt injection defence, supply chain integrity, agent permissions, guardrails, governance and incident response.

Entry level
$140,357
Security Engineer salary estimate, 25th percentile (US, n=6,355) — proxy: the AI-specific title has too few reported salaries to publish
Mid level
$172,800
Security Engineer salary estimate (overall average, US, n=6,355) — proxy: measures Security Engineer, not AI Security Engineer
Senior level
$213,409
Senior Security Engineer salary estimate (average, US, n=1,664) — proxy: measures Senior Security Engineer, not AI Security Engineer
Glassdoor

This path assumes you know application security fundamentals and have called an LLM API. It is defensive work: securing systems your organisation is shipping, usually faster than anyone can review them.

One property breaks the tools you already trust: the instruction and the data arrive in the same channel. There is no prepared statement for a prompt. Input validation as you know it does not apply, because the payload is natural language and the parser is a model that was built to be helpful.

So the ordering follows blast radius rather than novelty. Prompt injection first because it is the delivery mechanism for most of the rest, and agent security before RAG because an agent with tools can act on what it was tricked into believing.

Expect 7–9 months. Phase five is where the threat model stops being theoretical.

Your progress0%

The path, phase by phase

  1. AI Threat Landscape

    Classical appsec assumes code decides and data is inert. An LLM erases that line: the text it reads becomes the instructions it follows, so there is no parser to harden. Done when you have written a threat model for one AI system you own, mapped its risks onto the OWASP LLM Top 10 and MITRE ATLAS, and can name the controls that do not transfer from your existing appsec programme.

    3-4 weeks
    8 Skills
    AI Threat Modelling
    OWASP LLM Top 10
    MITRE ATLAS
    Trust Boundary Analysis
    Attack Surface Mapping
    Risk Classification
    Security Architecture Review
    Non-determinism as a Security Property
    Show details, projects and resources

    Skills you'll master

    AI Threat Modellingadvanced
    OWASP LLM Top 10advanced
    MITRE ATLASadvanced
    Trust Boundary Analysisadvanced
    Attack Surface Mappingadvanced
    Risk Classificationintermediate
    Security Architecture Reviewadvanced
    Non-determinism as a Security Propertyadvanced

    Hands-on projects

    1. 01Write a full threat model for one AI system you own or maintain, marking every point where untrusted text reaches the model as a trust boundary
    2. 02Map your system's risks onto the OWASP LLM Top 10 2026 and record which entries genuinely do not apply, with the reason for each
    3. 03Take your existing appsec checklist and mark every control that stops working when the input is natural language — that list is the scope of this roadmap
    4. 04Build an inventory of every model, prompt and data source your organisation runs in production, including the ones nobody registered
    5. 05Pick three ATLAS case studies and write, for each, whether your own architecture would have detected it — and what signal would have shown it
    6. 06Rank your inventory by blast radius rather than by model size: which system could take the most destructive action if it were manipulated?

  2. Prompt Injection Defence

    The signature failure of the field, and the one with no complete fix. Untrusted content reaching the context window is treated as instruction, and indirect injection through a retrieved document or tool output is the variant teams miss. Done when you can defend a system you own with layered controls and state honestly what your defences still do not stop.

    3-4 weeks
    8 Skills
    Prompt Injection Defence
    Indirect Injection via Content
    Input & Output Segregation
    Instruction Hierarchy Design
    Content Provenance & Tainting
    Output Validation
    Defence in Depth
    Residual Risk Documentation
    Show details, projects and resources

    Skills you'll master

    Prompt Injection Defenceadvanced
    Indirect Injection via Contentadvanced
    Input & Output Segregationadvanced
    Instruction Hierarchy Designadvanced
    Content Provenance & Taintingadvanced
    Output Validationadvanced
    Defence in Depthadvanced
    Residual Risk Documentationintermediate

    Hands-on projects

    1. 01Build a test corpus of injection-shaped inputs for a system you own, and track what fraction your current defences catch as a single baseline number
    2. 02Layer three independent controls — input handling, privilege limits, output validation — and measure each one's contribution separately
    3. 03Demonstrate indirect injection against your own retrieval pipeline by planting a document you control, then design the mitigation
    4. 04Mark retrieved and tool-returned content as untrusted throughout your pipeline, so its provenance survives all the way to the model call
    5. 05Treat model output as untrusted input to whatever consumes it, and add validation at that boundary rather than trusting the model
    6. 06Write the residual risk statement for your system: what your defences do not stop, and what compensating control covers it

  3. Data Poisoning & Model Supply Chain

    Every third-party model and dataset is code you did not write, executing with your privileges. Serialised model formats can carry arbitrary execution, and a poisoned fine-tuning set installs behaviour no code review will find. Done when you can prove the provenance of every model artefact in your pipeline and have blocked one unsigned or unscanned artefact from reaching production.

    3-4 weeks
    8 Skills
    Model Supply Chain Security
    Data Poisoning Defence
    Artefact Provenance & Signing
    Model Scanning
    Serialisation Risk
    AI Bill of Materials
    Training Data Governance
    Secure ML Pipelines
    Show details, projects and resources

    Skills you'll master

    Model Supply Chain Securityadvanced
    Data Poisoning Defenceadvanced
    Artefact Provenance & Signingadvanced
    Model Scanningadvanced
    Serialisation Riskadvanced
    AI Bill of Materialsintermediate
    Training Data Governanceadvanced
    Secure ML Pipelinesadvanced

    Hands-on projects

    1. 01Build an AI bill of materials for one production system, listing every model, dataset, adapter and their licences and origins
    2. 02Scan every third-party model artefact you run for unsafe serialisation, and convert what you can to a safe-by-construction format
    3. 03Add signature verification to your model deployment pipeline so an unsigned artefact fails the build rather than shipping
    4. 04Trace one fine-tuning dataset to its origin and write down who could have modified it, at which step, without you knowing
    5. 05Add integrity checks and access controls to your training data store, then verify them by attempting an unauthorised write yourself
    6. 06Introduce a benign marker into a training set you own, then confirm your pipeline's validation catches it before the model is trained

  4. Model & Inference Exposure

    What a served model leaks simply by answering. System prompts surface, training data can be memorised and recovered, and query access alone can approximate a proprietary model. Done when you have measured what one of your own deployed models discloses under sustained querying, and shipped a rate, logging or output control that reduces it — with the before-and-after figure.

    3-4 weeks
    8 Skills
    Sensitive Information Disclosure
    System Prompt Leakage Defence
    Training Data Memorisation
    Model Extraction Defence
    Inference-time Rate Controls
    PII Detection & Redaction
    Unbounded Consumption Defence
    Privacy-preserving Design
    Show details, projects and resources

    Skills you'll master

    Sensitive Information Disclosureadvanced
    System Prompt Leakage Defenceadvanced
    Training Data Memorisationadvanced
    Model Extraction Defenceadvanced
    Inference-time Rate Controlsadvanced
    PII Detection & Redactionadvanced
    Unbounded Consumption Defenceintermediate
    Privacy-preserving Designintermediate

    Hands-on projects

    1. 01Query one of your own deployed models until you can characterise what it discloses about its system prompt, then treat that prompt as public and re-secure what depended on its secrecy
    2. 02Add PII detection and redaction on both the inbound and outbound path, and measure the false-positive rate before you enable blocking
    3. 03Design rate and quota controls that make sustained extraction querying expensive, and confirm normal users never hit them
    4. 04Test whether a model you fine-tuned reproduces verbatim strings from its training set, and document what you changed if it did
    5. 05Add cost and token ceilings per caller so a single client cannot exhaust your inference budget — then verify by load-testing your own endpoint
    6. 06Audit what your inference logs retain, and cut any field that stores user content longer than your privacy policy allows

  5. Agent Security & Excessive Agency

    An agent turns a wrong answer into a wrong action. Tools, credentials and autonomy convert a text failure into a database write or an outbound payment, which is why excessive agency climbed the 2026 list. Done when every tool your agent holds runs under least privilege, destructive actions require confirmation, and you have proved a revoked permission fails closed.

    4-5 weeks
    8 Skills
    Least-Privilege Tool Design
    Agent Permission Boundaries
    Human-in-the-Loop Controls
    Blast Radius Limitation
    Sandboxing & Isolation
    Credential Scoping & Secrets
    Multi-agent Trust
    Action Audit Logging
    Show details, projects and resources

    Skills you'll master

    Least-Privilege Tool Designadvanced
    Agent Permission Boundariesadvanced
    Human-in-the-Loop Controlsadvanced
    Blast Radius Limitationadvanced
    Sandboxing & Isolationadvanced
    Credential Scoping & Secretsadvanced
    Multi-agent Trustadvanced
    Action Audit Loggingadvanced

    Hands-on projects

    1. 01Enumerate every tool and credential an agent you own can reach, then cut each one to the narrowest scope that still works
    2. 02Add explicit human confirmation for destructive or irreversible actions, and define in writing which actions qualify
    3. 03Revoke one permission and verify the agent fails closed with a clear error rather than silently degrading or improvising
    4. 04Run agent tool execution inside a sandbox with no ambient network or filesystem access, and document what broke when you removed it
    5. 05Log every tool call an agent makes with its arguments and outcome, so an investigator can reconstruct a session without the agent's help
    6. 06Threat-model an agent that reads from one system and writes to another, and identify where injected content could steer the write

  6. RAG & Data Boundary Security

    Retrieval makes the vector store part of your attack surface and your access-control problem. Embeddings ignore the permissions of the documents they came from, so the default failure is a user retrieving content they were never allowed to read. Done when retrieval in a system you own enforces per-user authorisation at query time, proved by a test where two users ask the same question and get different documents.

    3-4 weeks
    8 Skills
    Retrieval Access Control
    Vector Store Security
    Document-level Permissions
    Embedding Weaknesses
    Multi-tenant Isolation
    Knowledge Base Poisoning Defence
    Data Classification
    Ingestion Pipeline Validation
    Show details, projects and resources

    Skills you'll master

    Retrieval Access Controladvanced
    Vector Store Securityadvanced
    Document-level Permissionsadvanced
    Embedding Weaknessesadvanced
    Multi-tenant Isolationadvanced
    Knowledge Base Poisoning Defenceadvanced
    Data Classificationintermediate
    Ingestion Pipeline Validationadvanced

    Hands-on projects

    1. 01Enforce per-user authorisation at retrieval time, then prove it by having two users with different entitlements ask the same question
    2. 02Audit an existing vector store for documents whose source permissions were lost at ingestion — the count is usually not zero
    3. 03Implement tenant isolation in a shared vector store and verify a query from one tenant cannot surface another's chunks
    4. 04Add validation and provenance tracking to your ingestion pipeline so an untrusted document cannot enter the index unlabelled
    5. 05Plant a document containing injected instructions in a test index you own, and confirm your downstream controls neutralise it
    6. 06Classify the content in one knowledge base by sensitivity, and route the most sensitive class through stricter retrieval and logging

  7. Red Teaming Your Own AI Systems

    Adversarial evaluation as an authorised, repeatable engineering practice on systems you own. The output is not a list of clever tricks but a regression suite that fails a build. Done when an automated adversarial run executes in CI against a system you are authorised to test, and a change that weakens a defence breaks the pipeline rather than reaching production.

    3-4 weeks
    8 Skills
    Adversarial Evaluation Design
    Authorisation & Rules of Engagement
    Automated Red-Team Tooling
    Security Regression Testing
    Coverage Measurement
    Finding Triage & Severity
    Reporting to Engineering
    Continuous Assurance
    Show details, projects and resources

    Skills you'll master

    Adversarial Evaluation Designadvanced
    Authorisation & Rules of Engagementadvanced
    Automated Red-Team Toolingadvanced
    Security Regression Testingadvanced
    Coverage Measurementadvanced
    Finding Triage & Severityadvanced
    Reporting to Engineeringintermediate
    Continuous Assuranceadvanced

    Hands-on projects

    1. 01Write rules of engagement before testing anything: what is in scope, who authorised it, what you stop for, and where findings are stored
    2. 02Run an automated adversarial scanner against a system you own and triage every finding by severity rather than by novelty
    3. 03Convert your findings into a regression suite that runs in CI, so a defence that regresses fails the build
    4. 04Measure coverage across the OWASP LLM Top 10 categories and publish the gaps — the categories you cannot test yet are the honest result
    5. 05Write the findings report engineering will actually act on, leading with the fix rather than the demonstration
    6. 06Re-run the full suite after remediation and report the delta, so the security work has a number attached rather than a claim

  8. Guardrails & Runtime Defence

    The controls that run on every request in production, where latency and false positives are real costs. A filter that blocks 2% of legitimate traffic gets switched off within a week, so tuning is the engineering. Done when a guardrail you built runs on live traffic with measured precision and recall, and you can state its latency cost per request.

    3-4 weeks
    8 Skills
    Guardrail Architecture
    Input & Output Filtering
    Classifier Tuning
    False Positive Management
    Latency Budgeting
    Fail-safe vs Fail-open Design
    Policy Enforcement Points
    Guardrail Evaluation
    Show details, projects and resources

    Skills you'll master

    Guardrail Architectureadvanced
    Input & Output Filteringadvanced
    Classifier Tuningadvanced
    False Positive Managementadvanced
    Latency Budgetingadvanced
    Fail-safe vs Fail-open Designadvanced
    Policy Enforcement Pointsadvanced
    Guardrail Evaluationadvanced

    Hands-on projects

    1. 01Deploy a guardrail on live traffic and report its precision and recall against a labelled set you built first
    2. 02Measure the latency your guardrail adds per request, and decide explicitly whether it fails open or closed when it times out
    3. 03Tune a filter until legitimate traffic passes reliably, and record how many real requests the untuned version would have blocked
    4. 04Place enforcement points on both the inbound and outbound path, and show which class of failure each one catches
    5. 05Compare a managed guardrail service against your own implementation on the same labelled set, and justify the choice you keep
    6. 06Build the escape hatch: a documented, audited way to disable a guardrail in an incident without a deploy

  9. Governance & Compliance

    Where security work becomes something an auditor and a regulator can read. The EU AI Act attaches obligations to risk tier, and NIST AI RMF gives the vocabulary most programmes are assessed against. Done when you have classified one AI system against the EU AI Act's risk tiers, mapped your controls to NIST AI RMF functions, and named the gaps with owners.

    2-3 weeks
    8 Skills
    NIST AI RMF Application
    EU AI Act Risk Tiering
    Control Mapping & Evidence
    AI System Documentation
    Audit Readiness
    Policy Authoring
    Cross-functional Governance
    Third-party AI Risk Assessment
    Show details, projects and resources

    Skills you'll master

    NIST AI RMF Applicationadvanced
    EU AI Act Risk Tieringadvanced
    Control Mapping & Evidenceadvanced
    AI System Documentationintermediate
    Audit Readinessintermediate
    Policy Authoringintermediate
    Cross-functional Governanceintermediate
    Third-party AI Risk Assessmentadvanced

    Hands-on projects

    1. 01Classify one AI system against the EU AI Act risk tiers and write the justification you would defend to a regulator
    2. 02Map your existing controls to the NIST AI RMF Govern, Map, Measure and Manage functions, and list every gap with a named owner
    3. 03Assemble the evidence pack for one system — model cards, evaluations, approvals — as an auditor would ask for it
    4. 04Write the acceptable-use policy for AI systems at your organisation, in language a non-engineer will follow
    5. 05Build the third-party AI vendor assessment questionnaire you would send before approving a new model provider
    6. 06Run a governance review with legal and product, and record which of your technical controls they could not evaluate — that gap is a documentation defect

  10. Incident Response for AI Systems

    What you do once it has already happened. AI incidents resist the usual playbook: there is no stack trace, the behaviour may not reproduce, and the logs you need are ones nobody thought to keep. Done when you have run a tabletop for an AI-specific incident on a system you own and closed at least one telemetry gap it exposed.

    3-4 weeks
    8 Skills
    AI Incident Response
    Forensic Logging for LLMs
    Non-reproducible Investigation
    Detection Engineering
    Containment & Model Rollback
    Blameless Postmortems
    Disclosure & Communication
    Abuse Monitoring
    Show details, projects and resources

    Skills you'll master

    AI Incident Responseadvanced
    Forensic Logging for LLMsadvanced
    Non-reproducible Investigationadvanced
    Detection Engineeringadvanced
    Containment & Model Rollbackadvanced
    Blameless Postmortemsintermediate
    Disclosure & Communicationintermediate
    Abuse Monitoringadvanced

    Hands-on projects

    1. 01Run a tabletop for an AI-specific incident on a system you own, and record every question the responders could not answer from telemetry
    2. 02Close one telemetry gap the tabletop exposed — log the prompt, retrieval set and tool calls needed to reconstruct a session
    3. 03Write the containment playbook for a compromised model or prompt, including how to roll back a model version under load
    4. 04Build a detection that fires on anomalous agent behaviour, such as an unusual tool-call sequence, and tune out the false positives
    5. 05Investigate an incident that will not reproduce, and write the finding honestly in terms of likelihood rather than certainty
    6. 06Draft the disclosure template for an AI incident affecting users, saying what happened without either minimising it or over-explaining internals

What the job is actually like

Day to day
Mostly review and threat modelling, punctuated by red teaming your own systems. A normal week is reading design docs for features that add a model somewhere and asking what that model can now reach, arguing about whether an agent needs write access, and building the guardrails that make the answer enforceable rather than advisory. Time also goes on unglamorous supply chain work: where a model came from, what it was trained on, who can push a new version. The recurring frustration is being asked to sign off on a system after it shipped, which is a scheduling problem wearing a security costume.
The interview
Expect a threat modelling exercise on a system with an LLM in it, scored on whether you find the data boundary rather than on naming attack classes. A hands-on round often hands you a deliberately weak agent, asks you to make it do something it should not, then asks for the fix — and the fix is what is marked. Because the field is young, interviews lean hard on judgement: what you would block, what you would accept with monitoring, and how you tell the difference. Traditional security teams will also probe classic application security, since AI risk sits on top of it and does not replace it.
How people get in
Two clear origins, and neither is AI. Application and cloud security engineers arrive with the threat modelling and incident habits, and have to learn how models fail; the cloud security path covers most of what transfers. Engineers who built AI systems arrive from the agents path knowing exactly how the plumbing breaks, and have to learn to think adversarially about it. The second group is usually faster at finding real problems and slower at judging which ones matter. What transfers from either is assuming the input is hostile. What does not is confidence that a benchmark score means the system is safe.
After senior
The technical fork widens from securing systems to setting the standard other teams build against — governance work done by an engineer rather than a lawyer, and where the certification market currently points. A second fork goes toward AI red teaming as a full-time specialisation, closer to offensive security. A third is ordinary security leadership, where AI becomes one risk among many. Because the discipline is new, senior here often means the person who wrote the organisation's first policy on it, and that is a real and durable form of seniority.
Why people leave
The first is becoming the department of no. Guardrails that block legitimate work get routed around, and an engineer whose only artefact is a policy nobody follows has less influence than one who shipped a working permission boundary. The second is chasing the paper of the week: research moves fast, and a practice built on the latest named attack rather than on the boring fundamentals — access control, logging, supply chain — ages in months. The third is joining a company that wants the title for a compliance checkbox, where nobody intends to change a shipping decision because of anything you find.

Frequently asked questions

Related certifications

Related roadmaps