Tool Permissions
When an LLM is given tools to act in the real world (like sending emails or deleting files), it must be restricted by the principle of least privilege to minimize the blast radius if it gets hacked.
Why Does This Exist?
In the early days of Generative AI, chatbots were just conversational interfaces. If an attacker managed to jailbreak the model, the worst thing the model could do was output toxic text.
Today, AI models are built as Agents. They are given tools (APIs) to act on behalf of the user: they can read your emails, buy things with your credit card, and execute code on your server. If an agent falls victim to an Indirect Prompt Injection, the attacker can hijack the agent and force it to use its tools maliciously.
Because we cannot guarantee that an LLM will never be tricked by a prompt injection, we must assume it will happen. Tool Permissions are the access control layers built around the agent's tools to ensure that, when a hijack inevitably occurs, the "blast radius" is contained.
Think of It Like This
Giving your teenager a credit card
Imagine giving your teenager a credit card to buy groceries while you are out of town.
If you give them your main credit card with no limit, they might get scammed online, or they might impulsively buy a car. The blast radius of a mistake is your life savings.
Instead, you give them a prepaid card loaded with exactly 100.
Tool permissions do this for AI. Instead of giving the AI "full admin access" to your database, you give it a highly restricted token that can only read specific tables.
How It Actually Works
Tool permissions in AI architectures are governed by the Principle of Least Privilege: an agent should only have the exact permissions necessary to complete its assigned task, and no more.
1. Read vs. Write Access
The most fundamental split. An AI agent tasked with summarizing your calendar should have a ReadCalendar tool, but it should absolutely not have a DeleteEvent tool. If the agent gets hijacked by a malicious email, the attacker can only read your calendar (a privacy breach), not delete all your meetings (a destructive breach).
2. Scoped Credentials (OAuth)
When an agent acts on behalf of a user, it should use scoped authentication tokens (like OAuth), not global API keys.
- BAD: The agent uses a root AWS key to query a database. If hijacked, the attacker can use the tool to drop the database.
- GOOD: The agent authenticates as "User Bob" using Bob's OAuth token. If hijacked, the agent can only access the files that Bob himself has permission to access.
3. Human-in-the-Loop (HITL) for High-Stakes Tools
For dangerous tools—like sending an email to a client, executing a financial transaction, or running arbitrary bash code—permissions should be configured to require human approval. The agent can draft the action, but execution is blocked until the user clicks an "Approve" button.
Show Me the Code
# A conceptual example of defining scoped tools for an agentclass EmailAgent: def __init__(self, user_oauth_token): # 1. Provide a strictly Read-Only tool self.read_tool = Tool( name="ReadInbox", func=self._read_emails, permission_level="READ_ONLY", auth=user_oauth_token # Scoped to the specific user ) # 2. Provide a Write tool, but wrap it in a Human-in-the-Loop check self.send_tool = Tool( name="SendEmail", func=self._send_email_with_approval, permission_level="REQUIRES_APPROVAL", auth=user_oauth_token ) self.tools = [self.read_tool, self.send_tool]
def _send_email_with_approval(self, draft): # The tool halts execution and waits for user confirmation if prompt_user_for_approval(draft): return execute_send(draft) else: return "Action denied by user."Watch Out For
Over-permissioned default tools
Many agent frameworks (like LangChain or AutoGen) come with pre-built tools, like a PythonREPLTool that allows the agent to execute any Python code to solve math problems. If you deploy an agent to a production server with this tool enabled, a prompt injection can force the agent to write a Python script that deletes your server's hard drive. Never use global, unrestricted execution tools in production without Sandboxing.
Permission creep
As you add features to an AI assistant, it is tempting to give it more and more permissions to make it "smarter" and more helpful. This gradually turns a safe, read-only bot into a highly privileged admin. You must regularly audit an agent's tools and revoke those that aren't strictly necessary.
The Quick Version
- Tool Permissions limit what an AI agent can do when interacting with external systems.
- They are necessary because LLMs are vulnerable to prompt injections; attackers can hijack the agent and force it to use its tools maliciously.
- Always apply the Principle of Least Privilege: default to read-only access, scope credentials to the specific user, and avoid global admin keys.
- High-stakes actions (like spending money or sending messages) should require Human-in-the-Loop approval before the tool executes.
What to Read Next
- Indirect Prompt Injection covers the exact attack vector that makes strict tool permissions mandatory.
- Human-in-the-Loop details how to build the approval workflows that gate high-risk tools.
- Agent Security explores broader security architectures for autonomous systems beyond just tool access.