Ask ten security people what LLM security means and you'll get ten different answers, most of them half right. It's the discipline of finding and closing the ways a large language model can be manipulated, tricked, or abused, covering everything from the prompt a user types in to the training data and third-party plugins sitting behind the scenes. It is not a subfield of machine learning, whatever your LinkedIn feed keeps implying, and it is not traditional web application security wearing a novelty hat. It's its own attack surface, with its own exploit classes, and almost everyone learning it right now is starting from zero, regardless of how many years they've already put into security.
What Exactly Falls Under LLM Security?
Four things, roughly, and most beginner explainers only ever cover one. There's the model itself, its weights and training data, and the ways it can be poisoned or have information extracted from it. There's the prompt layer, the actual text going in and out, home to prompt injection and jailbreaking, the part everyone pictures first. There's the output, what the model is allowed to say, retrieve, or execute, and whether a clever enough input can get it to leak something it shouldn't. And there's the pipeline wrapped around all of it, the plugins, the retrieval system pulling in documents, the third-party model or library the whole product is bolted onto, any of which can be the actual weak point even while the model behaves exactly as designed.
Most people stop at the second one. Ask someone what LLM security means and you'll usually get some version of "stopping people from tricking a chatbot into saying something embarrassing." That's real, and it's also the smallest, least damaging slice of the problem. A poisoned document sitting quietly in a retrieval database, or a compromised dependency somewhere in the supply chain, will do more lasting damage than any clever jailbreak, and neither one requires the attacker to type a single manipulative sentence.
Why Doesn't Traditional AppSec Already Cover This?
Because the playbook that works for SQL injection has no clean equivalent here. You can sanitise a database query with a parameterised statement and move on with your day. You cannot sanitise natural language the same way without breaking the exact thing that makes the model useful, which is that it responds to arbitrary human phrasing. Traditional AppSec assumes a deterministic system, same input, same output, every time, which is what lets you write a test case, ship a fix, and call the vulnerability closed. LLMs don't play along. The same prompt asked twice can produce two different answers, and a payload that fails outright on attempt one can succeed on attempt three purely because you rephrased it slightly.
A traditional web app is a building with locked doors, you secure it by controlling who holds keys. An LLM is a building with a guard on the door who's been trained to follow a set of rules but who can, given enough persistence, a convincing enough story, or the right kind of flattery, be talked into breaking them anyway. You're not securing a lock any more. You're securing a judgment call, made fresh every single time someone talks to it, and that's a genuinely different problem to test for, not a harder version of the old one.
What Are the Core Risks, and Which One Actually Matters Most?
We don't treat these as a flat list, and we'd push back on anyone who does. Prompt injection is the one that matters most, not because it's the most technically interesting but because it's the most immediately exploitable in systems already in production, and because it's the technique that keeps showing up as the root cause behind other failures rather than staying in its own lane. According to OWASP's Gen AI Security Project, prompt injection alone maps to six of the ten categories in OWASP's Top 10 for Agentic Applications, as reported by Help Net Security, which tells you it's less a single vulnerability and more a technique that cuts across most of the ways agentic AI systems fail in the wild.
Under that sit the other LLM-specific vulnerability classes: jailbreaking, the closely related discipline of bypassing a model's safety training specifically rather than hijacking its instructions wholesale, sensitive information disclosure, where the model leaks training data or another user's context, data poisoning, where an attacker feeds a RAG system a document designed to corrupt what it tells the model later, sometimes lying dormant for months before anyone notices, and supply chain risk, which covers compromised weights, malicious plugins, and poisoned dependencies that need no clever prompt at all. The governance side is arguably worse. IBM data cited in that same Help Net Security coverage found only 37% of organisations have a policy in place to even detect shadow AI running inside them, which means most companies can't see the problem, let alone fix it.
What Actually Went Into Building AI1
We didn't build TryHackMe's AI1 certification as a multiple-choice quiz with an AI-themed skin. It's a 48-hour, non-proctored, browser-based practical exam, most people finish it in 6 to 8 hours, split across 13 hands-on scenarios in four sections, and those four sections aren't arbitrary, they map directly onto the risk hierarchy above: threat modelling and vulnerability identification, prompt injection and jailbreaking, AI supply chain security, and data poisoning in RAG systems. You need a 70% pass mark, and you need existing security fundamentals, networking, operating systems, core security concepts, going in. What you explicitly don't need is a machine learning background. That's not a lowered bar, it's a deliberate one: the shortage isn't in machine learning departments, it's in security teams who've never had to think about a system that takes plain English as its attack surface.
The reasoning behind building it this way is the same reasoning behind the whole path: companies are putting AI into production faster than they can secure it, and the people who can secure it properly are in short supply. You close that gap by breaking and defending real systems, not by reading about them, which is exactly why AI1 doesn't hand you a wall of text and ask you to pick the right answer. It hands you a live chatbot, a poisoned document, a compromised dependency, and 48 hours to prove you know what to do about each one.
How Do You Actually Build the Skills, in the Order We'd Recommend
You can read every OWASP category twice over and still freeze the first time you're handed a real prompt injection challenge, so the order matters more than most guides let on, and it's not a random one. It's the same order we recommend for AI security skills generally: prompt injection first, because it's the number one threat and everything else builds on understanding it, then the wider vulnerability classes OWASP defines, then threat modelling using a framework like MITRE ATLAS to map the attack surface across training, inference, API, and agent layers, then supply chain, then forensics and incident response last, because investigating a compromise properly requires everything that came before it.
Start with how the models actually work. Skipping the fundamentals, how models are structured, what training data actually does, is the single most common reason beginners get lost later. You end up trying to exploit a system whose basic mechanics you never learned.
Then go straight at prompt injection and jailbreaking. This is the one that earns first place in the order for a reason, and a dedicated LLM security room alongside separate prompt injection and jailbreaking content lets you run real attacks against a real model instead of reading about them in the abstract.
Practise defence, not just offence. Building an actual threat model and securing a system are different muscles to attacking one, and most learners skip past them because attacking is more fun. TryHackMe hires and certifies for people who can do both, and so does everyone else worth working for.
Go past the prompt layer into the pipeline. Supply chain security and RAG-specific data poisoning are where the real damage tends to land in production, and they're also the part almost no beginner content bothers covering, because it's less fun to demo than tricking a chatbot on camera.
Prove it with a scenario-based assessment, not a theory test. A multiple-choice exam can confirm you can recognise the term "prompt injection." It cannot confirm you can execute one under time pressure or spot a poisoned RAG document before it does damage. Only a practical format does that, which is the entire reason AI1 is built the way it is.
LLM Security Isn't a Niche Skill Anymore
The persistent myth is that this is a specialist add-on for people who already have a machine learning background, something you bolt on after years of traditional AppSec once you've run out of other things to learn. We think that's backwards, and AI1's own prerequisites make the point better than we could in prose: no prior AI or ML experience required, just the security fundamentals you'd need for any serious role. LLMs are already embedded in products most security teams are responsible for defending today, and the skills gap sits with the security people who don't yet know what a poisoned RAG document looks like, not with the data scientists. You don't need to understand backpropagation to learn LLM security. You need to understand how an attacker thinks, in the order we've laid out here, and then apply that thinking to a system whose input field is plain English.
Nick O'Grady