Welcome to TryHackMe's Agentic AI Security Path! You could be here for one of many reasons: maybe you've finished our AI Security Path and want to pick up where that left off, maybe your current role involves working with agentic systems and you want to learn how to do this securely, or maybe you've been bombarded with posts across various apps warning of the "infinite dangers" of agentic applications. Whether your interests are casual or corporate, you are in the right place. Here you will find no fear-mongering, no hyperbole, just in-depth hands-on labs which teach you all you need to know about Agentic Security. But why does it need its own path anyway?

Well, for that answer we need to look no further than the framework this path is structured around: the OWASP Top 10 for Agentic Applications. OWASP itself defined an entirely new framework for agentic AI rather than keeping it folded into the OWASP LLM Top 10 (covered in the AI Security Path); OWASP believed, as do we, that agentic systems represent a distinct enough shift to justify their own framework (and path!). Everything that has been "secured" so far in the AI Security Path has one thing in common: a model that talks, and something else (whether that something else be a user or a downstream system) standing between what it says and what it does next. If a model was successfully manipulated into saying something it shouldn't, the damage stopped at the words on the screen. That's no longer the case. Welcome to the autonomous world of agentic applications, let's get started, shall we?

Learning Objectives

• Understand why agentic AI security warrants its own dedicated OWASP framework and TryHackMe path, distinct from the OWASP LLM Top 10
• Understand the fundamental shift this path is built around: models that now act on their own decisions, not just produce text for something else to act on
• Get oriented on what the Agentic AI Security Path will cover

Prerequisites

• Completion of TryHackMe's AI Security Path is recommended, or at minimum a working familiarity with the OWASP Top 10 for LLM Applications, since this task explains how the two paths relate.

Putting the Agency in "Agentic"

To paraphrase OWASP, "an agent perceives, reasons, decides and acts towards a goal autonomously". This single sentence summarises the loop that makes agentic systems agentic, but it's a little academic, so let's zoom out a bit and put it into context. Let's start with something familiar, something we know, say, a plain old vanilla LLM being used as a customer help desk AI assistant. Without any access to external content, this AI assistant simply answers from what it knows, and that's the whole transaction.

Suddenly, as AI technology begins to advance, the team behind this AI assistant wants to increase its capabilities by defining a workflow. The team establishes predefined "routes" where, if a customer says X, it delegates to another agent (an agent trained with the domain knowledge of this topic) or calls tool Y (a tool is something an agent can use to do more than just talk — more on these in the next task). Now your AI assistant is starting to look more like an agentic system, with tools in place and sub-agents to delegate to. Only it's not. Not yet, anyway. A workflow has been defined in order for this LLM to know what to do and when; it is essentially hardcoded, and anything hardcoded has a ceiling.

The team then takes this into account and decide to take the AI assistant to the next level. The line they cross in this evolution is the boundary which "makes something agentic". From this point onwards, the model can intelligently and autonomously make decisions, such as which sub-agent to delegate to or which tool to call, and act on them. What actually changes here isn't more engineering, it's less. The hardcoded routes get deleted, and in their place the model is simply told what's available to it, and left to decide on its own. So ultimately, the difference between a plain LLM and an agentic system isn't the model but the architecture around it. In order for this agent to behave autonomously, it needs certain capabilities. This is what "the architecture around it" refers to.

Agentic Capabilities

We began this task by defining agentic systems with a loop; however, in order for this loop to run, an agent needs certain key capabilities. OWASP defines these three capabilities as follows:

• Planning & Reasoning: Working out what needs to happen and in what order, to actually satisfy the request. (How this actually works will be gone over in the next task.)
• Memory & Statefulness: Holding onto what's already happened so far, rather than treating each moment as a blank slate. Usually just the conversation itself, kept in view turn to turn, plus, for anything that needs to survive past one session, a separate store the agent writes to and reads back from later.
• Action & Tool Use: Doing something in the world instead of just describing what should be done. (Also covered in the next task.)

Both the "Planning & Reasoning" and the "Action & Tool Use" capabilities are the ones which turn a decision into something real, so that's what we're going to look at next.

An agent perceives, reasons, decides, and acts towards a goal autonomously, this deceptively simple loop unlocks so much potential, but before we dive a bit deeper into it, let's consider what problem it's trying to solve. Let's take it back to the loop's academic origin. ReAct, a technique introduced in a 2023 research paper, showed that AI works better when "thinking out loud". Think back to all those interactions you've had with an LLM where you're trying to troubleshoot some code or a technical issue. You go back and forth with the model, often having to cut through hallucinations to get to the fix. This happens because reasoning alone is a static black box, not grounded in the real world. Similarly, the ability to "act" alone is nothing without reasoning, as it lacks the working memory to support the action. If the problem is that the model isn't grounded in the real world, then the solution is surely… to ground it?

Ground Control to Agent Tom

You may have noticed the two problems identified in the paragraph above:

• Reasoning not being grounded in the real world
• Acting without reasoning lacks working memory

Both problems mentioned can be solved by simply involving each other. With this approach, as the model is reasoning, instead of proposing a hallucination, it can attempt to execute the solution itself and get feedback, or "ground truth", from the tool call or code execution itself, and repeat the loop again with this updated context. The action output can inform the reasoning, and the reasoning context can inform the action. A lot of this solution hinges on this term that keeps coming up: "tools". If you're not familiar with the term, it may be causing some confusion, so let's take a beat and understand what they are, and practically, how their implementation enables the loop we're discussing above.

What Are Tools?

In the previous task, a tool was defined as "something an agent can use to do more than just talk". We've now added further context to that, identifying that the objective here is to action something in the real world, and gain some feedback from that action so it can inform the next one. So for this we define a tool: a tool has a name, a description of what it does and when to use it, and a set of parameters that need to be filled in. When the model decides to use one (using its own reasoning), it doesn't run anything itself; rather, it outputs a structured request.

This can take shape in a few different formats, but for example's sake, let's take a look at what a tool written in Anthropic's format might look like. You are an employee at a bank and have built an agentic application (by the way, check out our Agent Building module!). You define a tool which can take an employee ID and check what that employee's role and access permissions are:

           {
  "name": "check_role",
  "description": "Look up an employee's role and access permissions by employee ID.",
  "input_schema": {
    "type": "object",
    "properties": {
      "employee_id": {
        "type": "string",
        "description": "The employee's ID"
      }
    },
    "required": ["employee_id"]
  }
}
        

Now, when a user is using your application, which takes in a user's message, it will forward this to the model (in this example, an Anthropic model), along with additional information such as which tools it has permission to use in this engagement. The model will perceive the given context, using it to reason and make a decision on which tool to use. It then acts on this decision and will send the agentic application a block looking something like this, essentially telling it to engage this tool with X parameters.

           {
  "type": "tool_use",
  "id": "toolu_01A3B",
  "name": "check_role",
  "input": {
    "employee_id": "e-4471"
  }
}
        

The agentic application will then run the piece of code associated with this tool and return the execution results back to the model, which might look something like this:

           {
  "type": "tool_result",
  "tool_use_id": "toolu_01A3B",
  "content": "role: ml-engineer (contract); permitted_scopes: [training-data-buckets: read]"
}
        

How reliably any of this works often comes down to how deliberately a tool was designed for a model to use. It's actually advocated for under the umbrella of its own practice, named "Agent-Computer Interface" (ACI). It deliberately mirrors the effort teams already put into Human-Computer Interface (HCI) design for people, and this attention to design has security relevance later in the path. A tool is how an agent acts on something itself, but not every decision ends there, and next we look at what happens when the right call isn't to act at all, but to hand the request to another agent entirely.

Why Use Them?

In this task, we're going to deep-dive into multi-agent systems and how they work. But before that, let's consider why we would want to use them in the first place, instead of just having one poor agent do all of our work.

1. Scoped identity / blast radius: Splitting work across agents means each one only needs the credentials for its own job, instead of one agent holding the combined access required for everything it might ever be asked to do.
2. Reduced path dependency: Separate agents each start reasoning fresh, so a bad approach in one doesn't drag the others down with it, the way it would if everything shared one long, anchored line of reasoning.
3. Specialisation: An agent with a narrow prompt and a handful of relevant tools performs more reliably on its one job than a generalist agent juggling instructions and tools for everything at once.
4. Speed: Independent subtasks can run at the same time across multiple agents instead of one agent working through them one by one, cutting total completion time dramatically.

Of course, none of these benefits come free, multi-agent systems can burn up to 15x the tokens of a single conversation, and more agents mean more coordination overhead, harder debugging, and less predictable behaviour overall.

How It Actually Works

Anthropic refers to this pattern as orchestrator-workers: "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results". OWASP names the same architecture from the security side a Coordinating Agent that "assigns subtasks to specialised agents". This terminology shows up across the field under different names because it's the shape most systems converge on.

Most multi-agent systems are built this way: one orchestrator, with one or more sub-agents beneath it, each reporting back to the orchestrator rather than to each other.

Mechanically, delegating to a sub-agent isn't actually new, it follows the same tool_use/tool_result round trip covered in the previous task, except this time a sub-agent is engaged in place of a tool function. OpenAI's SDK emphasises the same idea: "Handoffs are represented as tools to the LLM. So if there's a handoff to an agent named Refund Agent, the tool would be named transfer_to_refund_agent." And to further underscore this, LangChain's supervisor pattern implements the same idea: sub-agents get wrapped as ordinary tools, so the orchestrator sees high-level tools like schedule_event, never anything that looks different from a normal tool call.

So far, every sub-agent has been reached by wrapping it as a tool, but that only works when the sub-agent lives inside the application, which isn't always the case. In the next task, we will examine this scenario.

We wrapped up the previous task talking about how agents often communicate back to their orchestrator, but sometimes agents need to communicate with other systems, or even each other. This task will take you through how both of those happen.

Model Context Protocol

So we've talked briefly about how agentic systems can be set up to call tools which live within our own application, but what about when it's a tool or app someone else has built or hosts? How does an application communicate with that? This is the problem that Model Context Protocol (MCP) exists to solve. MCP is a shared standard for connecting an AI agent to the tools and data it needs, so nobody has to build a custom connector every time. Before this, engineers would find themselves writing custom integration code every time they connected a model to any given external system (a database, a file store, a company's internal API, etc.). The standard was developed at Anthropic by David Soria Parra and Justin Spahr-Summers; their own analogy for it compares MCP to a USB port, one standard connector instead of a different proprietary cable for every device (Anthropic's MCP announcement).

How It Works

Mechanically, MCP defines three roles (modelcontextprotocol.io):

• Host: The AI application itself
• Client: A component maintaining a connection to one server
• Server: A program that actually provides tools, resources, and prompts

If you think back to Task 3, where we looked at the tool_use/tool_result mechanism, it's essentially the same. MCP doesn't replace that — it standardises how a tool gets discovered and connected in the first place, especially when that tool is hosted by someone other than whoever built the application.

Agent-to-Agent (A2A)

A2A is the answer to the question, "well, what if I don't want to call an external tool or application, but an external agent?" Unlike before, when we spoke about a bank employee who had developed their own agentic application, a delegation to a sub-agent did not require "discovery", because they themselves defined that agent. However, when calling upon an agent built and run by a completely different company or person, you don't automatically know what it's capable of, what it expects as input, or what credentials it requires from you.

So imagine that same banking employee is now building an eBanking agentic application. They would scout some external agents which they think their application may find use for — say, for example, an agent which calls a credit bureau's agent to retrieve a customer's credit score. The engineer would essentially allowlist this external agent, so their agentic application knows it has access to it. From there, the application can handle it. Let's walk through what this might look like from the agent's perspective now, using the four steps defined in the official A2A spec:

1. Discovery: Okay, so a user has asked our agentic application if they can apply for a loan. The application needs to determine whether their credit score is sufficient first. It checks to see what tools and agents it has access to, and sees that it does indeed have access to an agent from a respected credit bureau. However, it doesn't yet know how to initiate communication with this agent, so it starts "discovery". Discovery is done by fetching an agent's "Agent Card" from its HTTP endpoint. An Agent Card is a document an agent publishes about itself, listing what it can do and how to safely authenticate to it, so others know before ever sending it a message.
2. Authentication: After reading the Agent Card, the bank's agentic application knows exactly what authentication is needed in order to communicate with the credit bureau's agent.
3. sendMessage: After authentication has been completed, the real communication can go out — "check the credit score for this customer", formatted the way the bureau's agent card said it should be. The bureau's agent performs its own reasoning steps and sends back a result.
4. sendMessageStream (optional): If the bureau's check was complex and involved multiple stages rather than one instant answer (unlikely in this example), it can stream those updates back incrementally instead of leaving your orchestrator sitting idle.

It's worth noting that Steps 1 and 2 typically only need to happen once, or get cached — you don't rediscover an agent every single request.

Wrapping Up

That's the whole shape of agent communication once you step outside your own agentic application: reaching tools someone else built, and reaching an agent someone else runs. It's worth letting the source clarify the distinction between the two communication types we've covered in this task: "MCP is for agent-to-tool communication: it standardises how an agent connects to its tools, APIs, and resources to get information. A2A is for agent-to-agent communication: as a universal, decentralised standard, A2A lets independent agents — including those using MCP — discover each other, delegate tasks, and share results." (a2a-protocol.org) Not competing standards — an agent can use both at once, MCP for tools and A2A for agents. Knowing how an agent reaches something is only half the picture, though; next we cover what it should actually be allowed to do once it gets there.

Put on Your Security Hat

Over the course of this room, we've looked at how agents work mechanically and architecturally to unlock functionality across systems. However, anyone who is security-minded (implied by your presence on this site) will have been reading this with alarm bells going off, and for good reason too. This technological leap forward does not come without potentially catastrophic security implications. This task reframes what we've covered in this room in a security context.

So let's walk back through exactly what should be setting them off. Task 2 established that the whole point of an agentic system is that hardcoded, human-approved routes get deleted, the model now decides for itself. Task 3 confirmed that decision doesn't stay theoretical: tools mean it can actually act on it, not just describe what it can do. Task 4 showed that same decision-making multiplying across several agents, each one needing real credentials to do its specific job. And Task 5 showed that reach extending past your own application entirely, to agents and systems you don't control, authenticating on your systems' behalf, on its own initiative.

Each one of those steps quietly depends on the same assumption: that whatever access got handed to the agent making the decision was the right amount. Not too little to do the job, not so much that one wrong call does real damage.

Least Agency

OWASP has a name for that assumption, and what happens when nobody checks it: Least Agency. In their own words, "We expand on the concepts of Least-Privilege and Excessive Agency by citing Least-Agency. This captures our advice to organizations to avoid unnecessary autonomy; deploying agentic behavior where it is not needed expands the attack surface without adding value." Least Agency is essentially the amalgamation of Excessive Agency (LLM06 from the original OWASP LLM Top 10) and Least-Privilege. If these already existed, why isn't this just old advice with a new label, then?

Well, Least-Privilege has always assumed a person provisions access ahead of time and reviews it periodically. Nothing in this room has worked that way. Task 4's delegation and Task 5's authentication both happened because the model decided to, in the moment, not because a person signed off on that specific instance beforehand. The decision to reach for access moved from a human, provisioning in advance, to a model, reasoning live.

But what does Least Agency look like in practice?

• Time-boxed access, not standing access: An agent holds permission only for the exact window it's using it, not indefinitely.
• One credential per agent, not one shared across a pipeline: Treating a whole chain of agents as a single client with a single token is the flaw, not a convenient shortcut.
• Identity bound to specific tools, not to broad accounts: Access should map to the exact calls an agent is allowed to make, not a general-purpose service account that happens to be capable of more.
• Inheritance tracked, not assumed to stop: A sub-agent silently inheriting or escalating its parent's access is how scope creep happens without anyone deciding it should.

Least Agency is a core security consideration when approaching agentic applications, and you'll see it come up again in future modules on this path as we explore specific vulnerabilities (like ASI01 and ASI04).

You now have access to TryHackMe's agentic platform. Rather than chatting with a single AI, you are talking to an orchestrator agent, a lead agent that can delegate tasks to specialist sub-agents working behind the scenes. You will only ever see the orchestrator in chat, but a lot more is happening underneath.

To see what's happening under the hood, click the Inspector icon in the top right of the agent window — it looks like a list with a pencil. This shows you every delegation, every tool call, and every result that passed between agents, the full chain made visible.

You have access to OrbitEx's cargo operations system. Ask the orchestrator about active shipments and watch how it handles your request. Here are some prompts to get you started:

• What is the current status of shipment OX-1101 and who is authorised to handle it?
• Are there any shipments currently awaiting clearance?
• Show me all critical handling shipments

Once you've explored, open the Inspector and answer the questions below.

This room has established that agentic systems are not defined by a smarter model, but by the architecture that lets a model decide and act on its own, and that shift changes what security actually has to account for at every layer.

• Agentic vs. workflow is an architectural distinction, not a capability one. A system becomes agentic when hardcoded, pre-approved routes are removed in favour of the model being told what's available and left to decide for itself. The same model can power either.
• That decision only matters because tools turn it into real action. A tool call gives the model "ground truth" from the environment instead of a guess, and how deliberately a tool is designed for a model (not just a human) to use directly determines how reliably that loop holds together.
• Splitting work across multiple agents trades cost and coordination overhead for scoped credentials, cleaner reasoning, specialisation, and speed. Delegation itself isn't a new mechanism, it's the same tool call from before, just with another agent sitting where a function used to.
• Reaching beyond your own application means choosing the right standard for what's on the other end: MCP for tools and data someone else built, A2A for an entire agent someone else runs, and an agent can use both at once.
• None of this is safe by default. Least Agency asks whether an agent's access maps exactly to the action it needs to perform, and it's a live problem specifically because that access is now being reached for by a model reasoning in the moment, not provisioned in advance by a person.

By completing this room, you have begun your journey into understanding agentic applications. Continue it on TryHackMe's Agentic AI Security Path with our next room, which covers how we threat model this new surface.