Beyond AI Security: Learning How to Assess AI Systems
My Experience with INE’s AI Systems Security Specialist (eAIS) Learning Path
When I decided to complete TryHackMe’s AI Security learning path, I expected to spend most of my time experimenting with prompts, trying to jailbreak language models, and exploring ways to make chatbots behave in unexpected ways. Instead, I spent the first several hours reading, which initially caught me by surprise.
Anyone familiar with TryHackMe knows the platform usually alternates short theoretical explanations with practical exercises that keep the pace engaging. This learning path takes a different approach. The opening modules are noticeably more theory-heavy, and for someone eager to jump into the labs, it can feel slower than expected.
Looking back, I now think that decision makes perfect sense. Understanding AI security requires something many other cybersecurity domains don’t: learning the technology before learning how to attack or defend it.
Before discussing prompt injection, data poisoning, or AI threat modelling, you first need to understand what a Large Language Model (LLM) actually is, how it receives information, how Retrieval-Augmented Generation (RAG) works, how embeddings are created, and how all these components communicate with one another.
One of the biggest misconceptions I had before starting was thinking of AI as something completely separate from traditional software. The learning path gradually changed that perspective.
An AI application is an ecosystem of interconnected services: the application itself, APIs, retrieval mechanisms, vector databases, external models, datasets, plugins, and often third-party providers. Each additional component introduces new trust boundaries and, consequently, new attack surfaces.

Comparison between a traditional application and an AI-enabled application
As someone preparing for a SOC role, this was one of the most valuable takeaways:
The technology may be new, but the defender’s mindset isn’t.
We still need to understand how information flows through systems before we can identify where those systems may fail.
Whenever AI security appears in the news, prompt injection tends to dominate the conversation, and it’s easy to understand why: watching a chatbot ignore its instructions or reveal information it shouldn’t makes for an eye-catching demonstration.
The learning path showed that prompt injection is only one entry in a much broader landscape of AI security risks.

A general view of the AI Security learning path
One framework I found particularly useful while progressing through the modules was the OWASP Top 10 for LLM Applications. Rather than treating prompt injection as an isolated vulnerability, OWASP places it alongside other equally important risks such as insecure output handling, sensitive information disclosure, excessive agency, insecure plugins, supply chain weaknesses, and training data poisoning.
The learning path doesn’t treat AI security as “prompt injection plus jailbreaking.” Those topics receive significant attention, and rightly so, but they’re presented as just two risks within a much broader ecosystem.
Looking at the curriculum through the lens of the OWASP Top 10 for LLM Applications, it becomes clear that the path also explores supply chain security, data poisoning, sensitive information disclosure, vector database security, threat modelling, and defensive architecture. That broader perspective made it feel much closer to real-world security than to a collection of isolated AI tricks.

Around the AI Forensics module, the pace of the learning path began to change. Instead of reading about concepts, I started interacting with different AI systems through practical labs designed to demonstrate how attackers and defenders approach these environments.
Some scenarios focused on reconnaissance, identifying AI infrastructure and extracting information from exposed services. Others explored prompt injection, indirect prompt attacks, AI threat modelling, RAG security, and supply chain risks.
What I appreciated most was that the practical exercises didn’t exist in isolation. Each lab built directly on concepts introduced earlier, making the initial theoretical investment feel worthwhile.

The practical exercises put you in direct interaction with multiple AI systems, helping reinforce the theory while deepening your understanding of how they work.
Ironically, one of my favorite sections wasn’t offensive at all. It was AI Forensics.
Before starting the path, I hadn’t really considered what investigating an AI-related incident might involve. The module introduced the idea that AI systems generate their own artifacts, interactions, prompts, logs, and behavioral patterns that defenders can analyze during incident response.
As someone pursuing a career in Security Operations, this immediately felt relevant. Although today’s SOC analysts may not investigate compromised LLMs every day, understanding how AI systems produce evidence, and how that evidence can support an investigation, seems likely to become increasingly valuable as organizations integrate AI into their environments.
Perhaps the biggest lesson I took away from the entire learning path is that AI security allows us to adapt everything we already know rather than discard it.
Throughout the modules, I found myself returning to concepts that already exist across cybersecurity:
The technologies may be different, but the underlying mindset remains remarkably consistent.
That realization also explains why frameworks such as MITRE ATLAS have begun organizing AI adversary techniques in a way that feels immediately familiar to anyone who has worked with MITRE ATT\&CK.
As AI systems become another enterprise technology stack, security practitioners need structured ways to understand how those systems are attacked and defended.

A simplified view of a prompt injection attack, illustrating how untrusted input can influence an LLM’s behavior by altering the instructions it follows.
One aspect of this learning path that deserves recognition is its balanced approach.
Many AI security resources naturally gravitate toward offensive techniques because they are engaging to demonstrate.
TryHackMe certainly covers prompt injection, jailbreaking, and reconnaissance, but it also spends considerable time exploring AI threat modelling, defensive controls, secure architecture, supply chain governance, data poisoning, and AI forensics.
That broader perspective made the experience feel much closer to real-world security than simply learning how to bypass safeguards.

Securing AI requires visibility beyond the model itself. The entire AI supply chain, from training data and third-party models to APIs and supporting infrastructure, must be considered.
AI introduces new attack surfaces, new technologies, and new terminology, but the principles behind defending those systems remain reassuringly familiar.
Understanding architecture, identifying trust boundaries, modelling threats, investigating incidents, and securing complex environments are still at the heart of the job.
As I continue building my homelab, writing technical walkthroughs, improving my detection engineering skills, and preparing for a career in Security Operations, I see AI security not as a separate specialisation, but as another domain where those same defensive fundamentals apply.
One of the most valuable lessons I took away from the experience: before we can secure intelligent systems, we first need to understand how they work, and how they fit into the environments we’re already protecting.