There is a bright line in AI application security, and it is the moment you hand a model a tool. Before that, the worst a language model can do is say something wrong. After that, it can send an email, open a pull request, query a database, move money, or delete a record — on behalf of whoever managed to influence its instructions. Tool use is what turns an assistant into an agent, and it is where the security conversation gets serious.
OWASP names this risk category excessive agency in its Top 10 for LLM Applications, and its 2026 guidance for agentic systems keeps returning to the same theme: the damage an agent can do is bounded not by how smart it is, but by how much it is permitted to do. That reframing is the whole game.
Why tool use breaks the usual model
A traditional application has a fixed set of code paths. An agent does not. It decides, at runtime, which tool to call and with what arguments, based on natural-language context it assembled from potentially untrusted sources. That makes it a near-perfect confused deputy: a component with legitimate, often broad privileges, taking instructions from a less-privileged and possibly hostile party.
The attacker's move is rarely to break the model. It is to get a malicious instruction into the agent's context — through a retrieved document, an email the agent reads, a webpage it browses, a support ticket it triages — and let the agent do the rest with its perfectly valid credentials. There is no CVE, no buffer overflow. The API call was authorized. The agent just did what it was told by the wrong person.
The main threats to tool-enabled agents
- Excessive permissions. The agent holds a broad token — admin scope, write access to systems it only needs to read — because that was the fast way to ship. A single injected instruction now has that entire blast radius.
- Excessive functionality. The agent is wired to forty tools when the task needs three. Every extra tool is another verb an attacker can conjugate.
- Tool poisoning. The description or schema of a tool the agent trusts is manipulated to smuggle instructions into the model, or a legitimate-looking tool is swapped for a malicious one. Because the model reads tool descriptions as context, a poisoned description is prompt injection with a delivery mechanism.
- Unbounded autonomy. High-impact, irreversible actions proceed with no human checkpoint, so a mistaken or manipulated decision executes at machine speed before anyone notices.
Controls that actually reduce blast radius
Accept that a malicious instruction will eventually reach your agent, and design so it cannot do much when it does.
Scope tools, not roles. Give the agent the narrowest set of tools the task requires, each with the least permission that works. An agent that summarizes support tickets does not need write access to billing. This is ordinary least privilege applied to a non-human identity, and it is the control that scales.
Treat each agent as its own identity. It should have its own credentials, its own audit trail, and its own behavioral baseline — governed with the same rigor as a human account. Inherited or cached credentials are how the confused deputy gets its dangerous reach.
Authorize the action, not the session. The meaningful checkpoint is the moment the agent tries to do something, not when the session started. Per-action authorization inside the execution loop catches the injected command that a session-level grant would wave straight through.
Keep a human in the loop for the irreversible. Sending money, deleting data, granting access, publishing externally — these warrant an explicit approval step. The latency is real; so is the blast radius you avoid.
Sandbox tool execution. Run tools with no ambient credentials and no network egress they do not need. If a tool executes generated code, isolate it hard — an agent that can run arbitrary code is only as safe as the box it runs in.
Validate tool inputs and outputs. Do not let the model pass unsanitized arguments into a shell, a query, or a filesystem path. And treat what a tool returns as untrusted content that will re-enter the context window.
The plumbing is a supply chain
There is a second, less obvious surface: the tools themselves are software, and increasingly they are third-party. An agent that connects to external tool servers is running code and trusting schemas it did not write. Typosquatted or compromised tool packages, unpinned tool definitions that change after you approved them, and unverified integrations are supply-chain risks that happen to live in the agent layer. They deserve the same pinning, provenance, and scanning you already apply to dependencies.
How Safeguard helps
Safeguard treats the agent layer as part of the software supply chain rather than a separate magical thing. The Griffin AI detection engine inspects the code where tool calls are wired up — where model output becomes a shell command, a query, or a filesystem operation — and flags the injection sinks and missing-authorization patterns that give a compromised agent its reach, so you catch excessive agency before it ships. Auto-fix remediation proposes the corrected, least-privilege pattern instead of just filing a finding.
On the supply-chain side, software composition analysis inventories the tool libraries and SDKs your agents depend on and reconciles them against known vulnerabilities and reputation data, so a poisoned or typosquatted tool package becomes a specific, prioritized finding. And Safeguard's own MCP server shows the pattern done right: a tightly scoped server that exposes read-oriented security data to the assistants your engineers use, so they can query findings and remediation plans without handing the model the keys to your environment. To see how this stacks up against alternatives, compare Safeguard against other tools.
Agents are only as safe as the smallest set of things they are allowed to do. Shrink that set, verify the code that grants it, and keep a human on the irreversible. Create a free account or read the documentation to get started.