How to audit AI agent tool permissions: a practical checklist for 2026
How to audit AI agent tool permissions: a practical checklist for 2026
In 2026, AI agents have real power. They read files, execute code, make API calls, send emails, query databases, merge pull requests. They do this on behalf of the humans who deploy them, using those humans' production credentials. When the agent is wrong, and it will be wrong eventually, the damage happens with real-world consequences.
The OWASP LLM Top 10 calls this LLM06: Excessive Agency. It means an agent has more tool permissions than it needs, so a single successful prompt injection or model mistake can cause disproportionate harm. It is one of the most common and highest-impact security issues in agentic systems today.
This article is the audit process we use to find and fix excessive agency before it becomes an incident. It is a checklist you can run against any agent in your stack, from an internal coding assistant to a customer-facing support bot.
Why this audit matters now
Three things make 2026 different from 2024.
First, agents are everywhere. Not just chatbots. Coding agents that open pull requests. Support agents that refund orders. Marketing agents that publish content. Sales agents that send cold emails from real domains. Each of these has production access to systems that can be misused.
Second, prompt injection is no longer theoretical. Real attacks have been demonstrated against real systems. An attacker who can influence any input that reaches the agent, whether through a support ticket, a document the agent reads, a web page it fetches, or an email in an inbox it processes, can potentially hijack its tools.
Third, the traditional permission model is inverted. Human employees have small default permissions and earn more over time. AI agents get deployed with broad permissions on day one because it is easier than figuring out the minimum set. That default is the problem.
The audit process
Step 1: map every tool
Start by listing every tool the agent can call. Not categories. Every single function. Include the ones in the MCP server, the ones in the function call schema, and the ones the agent can trigger indirectly through another tool.
A real inventory for a typical coding agent looks like this:
| Tool | What it does | Scope | |---|---|---| | read_file | Reads any file in the repo | Read, full repo | | write_file | Writes any file in the repo | Write, full repo | | run_bash | Executes shell commands | Full shell, unrestricted | | git_commit | Commits changes | Write, git | | git_push | Pushes to remote | Write, remote branches | | create_pr | Opens a pull request | Write, GitHub API | | search_web | Fetches web pages | Read, unrestricted | | query_db | Queries production database | Read, full DB | | send_email | Sends emails | Write, SMTP |
Most agents have more tools than their owners realize. The first audit surprise is usually the count.
Step 2: write an attack story for each tool
For every tool on the list, write one sentence that starts with "If an attacker hijacked the agent, they could..." Fill in the blank with the worst plausible outcome using that tool.
Using the coding agent example:
| Tool | Attack story | |---|