Tool Permissions: Limiting What Agents Can Do

The Principle of Least Privilege

Every agent should have access to the minimum set of tools needed for its specific task, with each tool scoped to the minimum permissions required for that task. This principle, borrowed from traditional computer security, is even more important for AI agents because agents make autonomous decisions that are not reviewed by humans in real time. A customer support agent needs to read order data, not write to the product database. A content generation agent needs to read reference material, not modify published content. A monitoring agent needs to query metrics, not restart services.

Implementing least privilege requires thinking carefully about what each agent role needs to accomplish and providing exactly that access, nothing more. This is more work than giving every agent full access to every tool, but the security benefits are substantial. When an agent is compromised through prompt injection or makes an error in judgment, the damage is limited to what the agent permissions allow. A compromised agent with read-only access to order data cannot delete customer records or transfer funds, regardless of what the attacker instructs it to do.

Permissions should be defined at the role level rather than the individual agent level. A "customer support" role has access to order lookup, refund processing (up to a dollar limit), and account information retrieval. A "content editor" role has access to content management tools but not customer data. When a new agent is created, it is assigned a role that determines its tool access. This role-based approach scales better than managing permissions for each individual agent and ensures consistency across agents with the same function.

Scope Limitations

Beyond controlling which tools an agent can access, permissions should control the scope of each tool invocation. A customer support agent should be able to look up the current customer order history but not other customers. A financial agent should be able to view transactions within a specific account but not across all accounts. Scope limitations ensure that even when an agent has access to a tool, it can only use that tool within appropriate boundaries.

Scope can be enforced at multiple levels. Parameter-level scoping injects or validates specific parameter values. When a customer support agent calls "get_orders", the system automatically adds the current customer ID to the arguments, preventing the agent from querying other customers. Row-level scoping applies database-level filters that limit which records the tool can access. API-level scoping uses API keys with restricted permissions that limit what operations the underlying service allows.

Time-based scoping limits how long permissions remain valid. A session-specific permission might expire when the customer conversation ends. A task-specific permission might expire when the assigned task is completed. Temporary elevation allows an agent to perform a sensitive action within a narrow time window, after which the elevated permission is revoked. This prevents stale permissions from being exploited long after they were needed.

Approval Gates for Sensitive Operations

High-risk tool calls should require explicit approval before execution. A refund exceeding a threshold amount, a data deletion operation, an external communication sent on behalf of the user, or a configuration change that affects system behavior are all candidates for approval gates. The agent generates the tool call as usual, but instead of executing immediately, the system pauses and requests approval from a human operator or an automated approval system.

Approval gates introduce latency, which is acceptable for high-stakes operations where the cost of an error exceeds the cost of a brief delay. The gate should present the approver with full context: what operation is being requested, why the agent decided to perform it, what the expected impact is, and what the risk is if the operation fails or produces unintended results. Clear context helps approvers make informed decisions quickly.

Automated approval systems can handle approval for routine operations that meet predefined criteria. A refund under 50 dollars for an order with a clear quality issue might be auto-approved. A refund over 500 dollars or a refund for an order that was delivered successfully might require human review. The criteria should be configurable and auditable, with clear records of what was auto-approved and what was escalated.

Defending Against Prompt Injection

Prompt injection attacks attempt to manipulate the model into making unauthorized tool calls by embedding adversarial instructions in data the model processes. A malicious user might include hidden instructions in a support ticket that tell the model to export customer data or to issue unauthorized refunds. Permissions are the last line of defense when the model reasoning is compromised.

Defense in depth combines permissions with other protective measures. Input sanitization strips or neutralizes potentially adversarial content before the model processes it. Output validation checks tool call arguments against expected patterns and flags anomalous requests. Rate limiting prevents rapid-fire tool calls that suggest automated exploitation. Anomaly detection monitors tool calling patterns and alerts operators when behavior deviates from the norm.

Even with robust permissions, the model can be manipulated into making tool calls that are individually authorized but collectively malicious. An attacker might instruct the model to look up many customer accounts one at a time, each call individually authorized but the aggregate constituting a data exfiltration attack. Session-level limits on the total number of tool calls, the total amount of data accessed, and the diversity of resources queried can detect and prevent these aggregate attacks.

Audit Logging

Every tool call should be logged with complete context: the agent identity, the user or session that triggered the call, the function name and arguments, the result, the timestamp, and whether the call was approved, denied, or auto-approved. This audit trail serves multiple purposes: debugging agent behavior, investigating security incidents, demonstrating compliance with regulatory requirements, and identifying patterns that suggest permission adjustments are needed.

Audit logs should be immutable and stored separately from the agent system. An attacker who compromises the agent should not be able to modify or delete the logs that record the compromise. Log analysis tools should flag suspicious patterns automatically: unusual tool call volumes, access to resources outside normal patterns, calls during unusual hours, and tool calls that follow known attack signatures.