Tool calling lets an LLM agent take actions in the world — call an API, run code, query a database, send an email — rather than just generate text. That capability is also the security boundary that matters most, because a manipulated or hallucinated tool call can produce a real-world effect, not just a wrong sentence on a screen.
What changed in 2026
- Indirect prompt injection moved from theoretical to routinely exploited, with attacks embedding instructions in documents, web pages, or emails that an agent later retrieves and treats as trustworthy content.
- Sandboxed and permission-scoped agent execution became standard architecture advice, replacing the earlier default of giving agents broad, standing credentials.
- Evaluation frameworks for agent safety matured alongside general agent evaluation practices, with red-teaming for tool misuse becoming a normal part of pre-launch testing.
How tool calling works, briefly
The model receives a description of available tools (name, parameters, purpose), decides when a tool call is warranted based on the conversation, and emits a structured call that your application code executes and returns the result of. The model does not execute anything itself — your application does — which is exactly where the security responsibility sits: the model's output is a request, and your code decides whether and how to honor it.
The attack surface
| Risk |
How it happens |
Impact |
| Indirect prompt injection |
Malicious instructions embedded in retrieved content (a webpage, document, email) |
Agent takes unintended action based on injected instructions |
| Overly broad tool permissions |
Agent granted standing credentials wider than any single task needs |
A single manipulated call causes outsized damage |
| Hallucinated tool arguments |
Model generates plausible but incorrect parameters |
Wrong data sent, wrong record modified |
| Chained tool calls |
Multiple tools called in sequence, compounding a single bad decision |
Small error early in the chain amplifies downstream |
| Lack of action confirmation |
Irreversible actions execute without human check |
No recovery once an incorrect action completes |
Mitigations that actually help
Scope permissions to the specific action, not the broadest available credential — a tool that only needs to read a calendar should not hold write access to email. Treat all retrieved or user-supplied content as untrusted, the same discipline used for prompt templates handling variable input. Require human confirmation before irreversible actions — sending money, deleting data, sending external communications — regardless of how confident the model's output looks. Log every tool call with its inputs and outputs so an incident can actually be traced after the fact, not just detected in general.
Designing least-privilege agents
Build tool access around the smallest set of permissions the specific workflow needs, issued as short-lived credentials rather than standing broad access. Separate "read" and "write" tools explicitly, and put any tool capable of an irreversible or costly action behind an extra confirmation layer, whether that is a human-in-the-loop step or a secondary automated check with a different, independent model or ruleset.
FAQ
Is indirect prompt injection preventable entirely?
Not with current techniques. Defense-in-depth — content sanitization, permission scoping, and human confirmation for consequential actions — reduces risk; nothing eliminates it completely today.
Does using a more capable model reduce tool-calling risk?
Not by itself, and sometimes the opposite — a more capable model given broad permissions can cause more damage per mistake. Permission scoping matters more than raw model capability.
Should every tool call require human confirmation?
No, that defeats the purpose of automation. Reserve confirmation for irreversible or high-cost actions; low-risk, reversible actions can run without a human in the loop.
How do I test an agent for tool-calling vulnerabilities before launch?
Red-team it deliberately with adversarial content designed to trigger unintended tool calls — malicious instructions embedded in documents or retrieved pages the agent is likely to process.
Where to go next