Secure LLM Tool Access: Controlling What AI Agents Can Do
TL;DR · the short version
Giving an LLM access to tools (APIs, databases, code execution, messaging, actions) is what turns a chatbot into an agent, and it is where the security risk concentrates, because untrusted input can steer the model via prompt injection into misusing the tools you granted. Securing it applies familiar principles to a new context: least privilege scoped per tool, human-in-the-loop approval for irreversible actions, sandboxing, treating all model output and tool results as untrusted, and logging every tool call. This guide lays out those controls.
The moment you let a large language model call tools — hit APIs, query databases, run code, take actions — you stop having a chatbot and start having an agent with real capability in your environment. That capability is the point, and it is also where the risk concentrates: an LLM can be steered by untrusted input into misusing the very tools you granted it. Securing LLM tool access is about bounding that power.
Why it is risky
An LLM cannot reliably tell instructions from data. If it processes untrusted content — a web page, a document, an email, a tool result — that contains injected instructions, it may act on them, using its tools to exfiltrate data or take harmful actions. You cannot fully prevent this, so you contain its impact.
The core controls
- Least privilege: scope each tool to the minimum capability and data it needs; read-only where possible.
- Human approval for high-impact actions: destructive or irreversible actions (deleting data, sending external messages, moving money) require a human, so a hijacked agent cannot execute them alone. This matters most for always-on personal agents that hold logged-in browser sessions, such as Open Dot.
- Sandboxing & isolation: constrain what tools can reach — network, filesystem, data.
- Treat outputs as untrusted: model output and tool results feeding other systems must be validated, not trusted.
- Log every tool call: comprehensive, reviewable logs for detection and audit.
For MCP-based agents
If your agents use the Model Context Protocol, apply the same controls to each MCP server: allowlist approved servers, scope to least privilege, authenticate, gate high-impact actions, and log everything.
Govern tool/server access with the MCP Guard →, assess a specific server with MCP Server Risk, read the control baseline in MCP governance controls, and threat-model the feature with the AI Threat Model.
Frequently asked questions
Why is it risky? Tool access gives the model real capability, and prompt injection can steer it into misusing those tools.
Core controls? Least privilege, human approval for high-impact actions, sandboxing, treating outputs as untrusted, and logging.
Relation to prompt injection? Injection is the mechanism; least privilege and approval gates contain its impact.
How to start? Inventory tools, scope to least privilege, gate destructive actions, sandbox, treat outputs as untrusted, log — and apply the same to MCP servers.
Frequently asked questions
Why is LLM tool access a security risk?
Because it gives the model real capability in your environment — and the model can be manipulated. If an LLM processes untrusted content (a web page, document, email, or tool result) that contains injected instructions, it can be steered into calling its tools in harmful ways: exfiltrating data, taking destructive actions, or escalating access. The tools you grant for legitimate use become the attack surface, which is why access must be tightly controlled.
What are the core controls for secure LLM tool access?
Least privilege (each tool scoped to the minimum capability and data needed, read-only where possible); human-in-the-loop approval for high-impact or irreversible actions; sandboxing and isolation so tools can only reach what they should; treating model output and tool results as untrusted input to downstream systems; and comprehensive logging of every tool call for detection and audit. Together these limit what a hijacked agent can actually do.
How does prompt injection relate to tool access?
Prompt injection is the mechanism that makes tool access dangerous. An attacker plants instructions in content the agent will process, and the agent — unable to reliably distinguish instructions from data — may act on them, using its tools to do the attacker's bidding. Because you cannot fully prevent injection, you contain its impact by limiting what the tools can do (least privilege) and requiring human approval for anything consequential.
How do I start securing tool access for our AI agents?
Inventory which tools each agent can call and what they can reach, scope every tool to least privilege, require human approval for destructive or sensitive actions, isolate/sandbox tool execution, treat all outputs as untrusted, and log every tool call. For agents using the Model Context Protocol, apply the same controls to each MCP server: allowlist, least-privilege scope, authentication, approval gates and logging.