How to Learn AI and LLM Security in 2026: A Roadmap for the Field Nobody Has a Head Start In
Most of security has a brutal entry problem. The people hiring have twenty years of experience, the certifications assume you already know the basics, and every job wants three years for an entry level role.
AI and LLM security does not have that problem yet. The field is about three years old in any serious sense. The person who started in 2023 is not a veteran, they are an early adopter who got lucky with timing. For once, the gap between you and the people at the front is measured in months, not decades.
This post is a roadmap to close that gap on purpose. Six steps, four to six months of focused effort, and a checkpoint at each stage. It assumes you have basic security fundamentals already. If you are completely new to security, do a web fundamentals path first, because most LLM attacks are delivered over the same HTTP you need to understand anyway.
One rule before we start, and it matters more here than in older fields because the boundaries are still being drawn: only test models, applications and agents you own or are explicitly authorised to test. Prompt injecting a production system you do not own is unauthorised access, the same as any other intrusion.
What AI security actually covers
The phrase gets used for several different jobs, and knowing which one you want saves months of wandering.
- LLM application security. Testing apps built on top of models: chatbots, copilots, RAG systems, agents. This is where most of the jobs and bug bounty scope are right now
- AI red teaming. Adversarially probing a model or system for harmful, unsafe or policy breaking behaviour. Labs and model vendors hire for this
- ML security. Attacks on the models themselves: data poisoning, model extraction, adversarial examples. More research heavy, often needs a machine learning background
- AI for security. Using AI to defend, like detection and triage. This is a defender skill, not an attacker one
This roadmap focuses on the first two, LLM application security and AI red teaming, because that is where a security person without a deep machine learning background can get productive fastest and where the demand is loudest.
Step 1: Understand how LLMs actually work
Time needed: 2 to 3 weeks
You cannot attack what you treat as magic. You do not need to train a model or do the maths, but you do need an accurate mental model of what is happening, because almost every LLM vulnerability comes from one specific property.
The concepts that matter for security
- Tokens and context. How a model reads input as tokens and how the context window works, including why long inputs can push instructions out
- The system prompt. What it is, where it sits, and why it is not a security boundary even though developers keep treating it as one
- Instructions and data share a channel. This is the single most important idea in the whole field. A model cannot reliably tell the difference between “this is a command from the developer” and “this is text from a user or a document”. Every prompt injection exploits exactly this
- Temperature and sampling. Why the same input gives different outputs, and what that means for testing
- RAG and tool use. How models pull in external data and call functions, which is where the dangerous attack surface lives
Checkpoint: you can explain, in one sentence, why prompt injection is fundamentally hard to fix. If your answer involves instructions and data sharing the same channel, you understand the field’s core problem.
Step 2: Learn prompt injection, the core vulnerability
Time needed: 3 to 4 weeks
Prompt injection is to AI security what SQL injection was to web security: the signature bug class that defines the early field. Master this before anything else.
Direct prompt injection
- Getting a model to ignore its instructions through the user input directly
- Jailbreaks, role play framing, instruction override, encoding tricks
- Why “ignore previous instructions” is the toy version, and what the real techniques look like
Indirect prompt injection
- The dangerous one. The malicious instruction is hidden in data the model later reads: a web page, a document, an email, a calendar invite
- Example shape: a resume with hidden white text that tells the screening AI to recommend the candidate, or a web page that hijacks an AI browsing agent
- Why this turns every untrusted data source the model touches into an attack vector
What to actually do
- Work through a deliberately vulnerable LLM app and get hands on with both types
- Build a small chatbot yourself and try to break your own system prompt, then try to defend it, then break the defense
- Study real disclosed prompt injection findings to see how they are reported
Checkpoint: you can take a chatbot with a system prompt and extract that prompt, then make the bot do something it was explicitly told not to do, through both direct and indirect injection.
Step 3: Map the OWASP Top 10 for LLM applications
Time needed: 2 to 3 weeks
OWASP maintains a Top 10 specifically for LLM applications, and it is the closest thing the field has to a shared syllabus. Learn each item as a testable vulnerability class, not as a definition to memorise.
The classes worth real time
- Prompt injection. Already covered, and still number one for a reason
- Insecure output handling. The app trusts model output and passes it straight into a browser, a shell, or a database. Classic XSS and injection, now with the model as the unwitting middleman
- Sensitive information disclosure. The model leaks training data, other users’ data, or secrets from its context
- Excessive agency. The model can take actions, call tools, send emails, run code, with too little restriction. This is where injection becomes genuinely dangerous
- Supply chain and model poisoning. Compromised models, datasets or plugins
- System prompt leakage. Extracting the hidden instructions, which often contain secrets developers assumed were private
Checkpoint: given an LLM powered application, you can walk through the OWASP LLM Top 10 and name a concrete test for each item that applies.
Step 4: Attack AI agents and tool use
Time needed: 3 to 4 weeks
This is the frontier, and where the field is heading fastest. A chatbot that only talks is low risk. An agent that can browse, run code, send messages and call APIs is a different animal, because now a successful prompt injection does not just change text, it takes actions.
What makes agents dangerous
- Tool access. The model can call real functions. Injection plus tool access equals real world impact
- Autonomy. Multi step agents make decisions without a human checking each one
- Chaining. Output from one step becomes input to the next, so a single poisoned source can cascade
- The confused deputy problem. The agent has permissions the attacker does not, and injection tricks it into using them
The protocol layer
- Agents increasingly talk to tools through standard protocols like MCP, which introduces its own attack surface: tool poisoning, malicious tool descriptions, and trust boundaries between agent and tools
- This is new enough that writing clearly about it puts you near the front of public knowledge
Checkpoint: you can describe an end to end attack where untrusted data reaches an agent, injects an instruction, and causes the agent to misuse a tool it has access to.
On Hacklido this is exactly the ground the “30 Days of Agent Hacking” series and the AI recon and threat mapping lab cover, so there is hands on material to practise against rather than just theory to read.
Step 5: Learn the defenses
Time needed: 2 to 3 weeks
You cannot do this work for a company without knowing what the fixes are, because the second half of every finding is “and here is how to reduce it”. The honest truth of this field is that prompt injection has no complete fix yet, so defense is about layers and damage limitation, not a silver bullet.
The defensive toolkit
- Input and output filtering. Guardrail models and classifiers that screen prompts and responses. Helpful, not sufficient
- Least privilege for agents. The strongest real defense. If the agent cannot send money, injection cannot send money. Scope tool access tightly
- Human in the loop. Requiring confirmation for high impact actions
- Privilege separation. Treating all model output as untrusted, and never passing it into a sensitive sink without validation
- Sandboxing. Running agent actions in isolated environments with no access to anything they do not strictly need
Checkpoint: for any finding you produce, you can propose a layered mitigation and honestly explain its limits, rather than claiming a problem is solved.
Step 6: Build proof and specialise
Time needed: ongoing
The field is so new that a small amount of public work puts you visibly ahead. This is the step that converts learning into a reputation and a job.
- Write it up. Document every attack you reproduce and every lab you complete. In a field this young, clear writeups rank and get read fast
- Pick a lane. LLM app pentesting, agent security, or model red teaming. Depth in one beats shallow coverage of all three
- Hunt where it is live. A growing number of bug bounty programs now include AI features in scope. Prompt injection and output handling bugs are being paid for today
- Follow the research. The field moves monthly. Following the people publishing new techniques is part of the job, not extra credit
Checkpoint: you have a public writeup of at least one real AI security finding or lab, in your chosen lane, that someone else could learn from.
A realistic schedule
Based on six to ten focused hours a week, assuming existing security basics.
| Period | Focus |
|---|
| Weeks 1 to 3 | How LLMs work, the instructions and data problem, build a small chatbot |
| Weeks 4 to 7 | Prompt injection, direct and indirect, break your own bot |
| Weeks 8 to 10 | OWASP LLM Top 10 as testable classes |
| Weeks 11 to 14 | Agent and tool use attacks, the protocol layer |
| Weeks 15 to 17 | Defenses, mitigations, writing honest remediation |
| Weeks 18 onward | Public writeups, a chosen lane, live bug bounty scope |
Where this leads
- AI Red Teamer. Adversarially testing models and AI products, at labs and vendors
- LLM Application Pentester. Testing the growing wave of AI features bolted onto normal products
- AI Security Engineer. Building the guardrails, filtering and architecture that defend these systems
- AI Security Researcher. Publishing new attack and defense techniques in a field hungry for them
- Detection and Response for AI. The defender side, monitoring and responding to AI specific threats
The common thread is that all of these roles have shortages right now, and credentials barely exist, which means demonstrated skill counts for an unusual amount.
Frequently asked questions
Do I need a machine learning background?
For LLM application security and red teaming, no. You need to understand how models behave, not how to build them. A deep ML background matters more for the research heavy model attacks, which is a different lane.
Is this a real career or hype?
Real, and growing. Every company shipping AI features is creating attack surface, and almost nobody knows how to test it. The demand is ahead of the supply of skilled people by a wide margin.
Can I use my existing security skills?
Yes, heavily. Insecure output handling is XSS and injection wearing a new hat. Excessive agency is privilege and access control. Your web and app security knowledge transfers directly.
Where do I practise legally?
Deliberately vulnerable LLM apps, your own built chatbots and agents, dedicated AI security labs, and bug bounty programs that explicitly include AI features in scope. Never a production system you do not own.
Is prompt injection actually unfixable?
There is no complete fix today. It is managed with layers, least privilege and human oversight, not eliminated. Anyone claiming a total solution is overselling, and knowing that is itself a sign you understand the field.
The honest closing
Every established security field has a wall of experienced people standing between you and the interesting work. AI security does not have that wall yet, because the field is too new for anyone to have spent a career in it.
That window does not stay open. In a few years this will look like every other speciality, with its own senior tier and its own entry barrier. The advantage goes to the people who start while it is still being figured out, and who publish what they learn while the public record is still thin enough that one good writeup gets noticed.
Build a small chatbot this week. Break its system prompt. Write up exactly how you did it. You will have done, with your own hands, the thing that the entire field is still trying to solve, and you will have the writeup to prove it.
The AI security labs and the agent hacking material on Hacklido are built to give you real targets for exactly this, and publishing your own findings there is a fast way to get your work seen in a field where the early writeups are still being written.
