Orientation
What if the model could do things?
So far, LLMs are text-in, text-out machines. They predict words. But what if instead of just answering "The weather in London is probably cold," the model could check the actual weather? What if it could send emails, search databases, or book flights?
That's what tools enable - and it changes the risk profile entirely.
The Basic LLM Limitation
Without connected tools or application code, a text LLM only generates model output. By itself, it can't:
- Browse the web
- Do guaranteed-exact math (it can reason through arithmetic, but it is not a calculator that is always exact)
- Access databases
- Send messages
- Read files
- Call APIs
It's stuck in the text world. Ask it "What's 7,392 x 8,451?" and a quick pattern-based guess can be off - and even when it reasons the answer out step by step, it is not the guaranteed-exact calculator a tool gives you. Ask it for today's weather and, without a live source, it can only generate an answer from supplied context and training patterns.
Tools Solve This
Tools (also called function calling) let developers give the model a menu of actions it can take.
The key idea: the model proposes an action, and the application carries it out. The model emits a structured request; secure application code validates authorization and arguments before deciding whether to run it.
"What's the weather in London?"
It outputs a structured request like get_weather(city="London")
The app - not the model - validates, authorizes, and calls the real API
The app feeds the result into the context window
"It's 15°C and cloudy in London right now."
Notice how this is a straight line - user asks, model proposes one tool call, the app validates and runs it, and the model answers. One round-trip. The application remains the enforcement point.
With Tools vs. Without Tools
Same model, same question. Tools let the answer be grounded in an external source instead of relying only on model training.
From Tool Calling to Agents
The diagram above shows a single tool call - one question, one tool, one answer. But what happens when the task needs multiple steps?
"Plan a trip to Tokyo" isn't a single API call. It's: search flights, then book a hotel, then check the weather. The model needs to call several tools in sequence, deciding what to do after each result.
This is where agentic behavior starts. Instead of one round-trip, the model runs in a loop:
"Plan a trip to Tokyo - find flights, book a hotel, and check the weather."
search_flights(destination="Tokyo") → gets flight options
The app runs the tool, feeds the result back
"I have flights. Now I need a hotel." → calls book_hotel(...)
The loop continues only within the application's limits and approval controls
See the difference? The tool-calling diagram is a straight line. The agentic diagram has a loop - the model keeps going, calling tool after tool, until it decides the task is done.
The Privilege Problem
Here's where things get serious.
If you give a model tools for sending emails and deleting files, and the backend executes its requests without effective authorization, the damage is real. The email gets sent. The file gets deleted.
Text manipulation becomes real-world action.
In an agentic loop configured to auto-execute tool requests, one bad decision can chain into the next. The model might delete a file, email its contents to the wrong person, then delete the email log. Each action can feed the next unless application limits or approval gates stop the chain.
Consider a model with these tools:
send_email(to, subject, body)delete_file(path)query_database(sql)
The model is acting as a deputy - it takes actions on behalf of the user. But if the model gets confused about what the user actually wants (through manipulation, ambiguous instructions, or injected data), it becomes a confused deputy - executing actions the user never intended.
An LLM assistant has access to send_email, delete_file, and read_file tools. A user asks it to 'clean up old files and email me a summary.' What could go wrong?
Why This Matters
Tools turn LLMs from interesting toys into powerful systems that act in the real world. Agentic loops can amplify risk when applications auto-execute model requests - a manipulated instruction may trigger a chain of real actions. The security implications compound:
- How LLMs Work: At its core the model is predicting text with no built-in check on what that text is, so it can be fooled
- System Prompts: Higher-priority instructions shape behavior, but they are not an authorization boundary
- RAG: External data flows into the prompt - it can carry hidden instructions
- Tools + Agents: A manipulated model with powerful tools can cause real damage, and an autonomous loop can continue until a limit or approval boundary
Each layer builds on the last. That's why you needed the fundamentals first.
Ready for the Security Modules
You now understand the four building blocks:
- LLMs are text predictors with a finite context window
- System prompts shape behavior but aren't security boundaries
- RAG injects external documents into the prompt
- Tools let the model trigger real-world actions - and agentic loops let it chain them
The security modules will show you how to exploit each of these and how to analyze the controls that mitigate them.
Sources
- Model Context Protocol: Tools - a concrete protocol for tool discovery and invocation
- OWASP LLM06: Excessive Agency - least privilege, authorization, and human approval for high-impact actions