A Least-Privilege Audit Prompt for Your AI Agent's Tools

Your agent needs to read one config file. Six months and four features later, it holds write access to the whole repo, a database token that can drop tables, and shell execution — because each was easier to grant than to scope. Then a prompt injection lands, and every one of those permissions is now the attacker's. A least privilege audit for AI agents catches the over-grant before someone else does.

The good writing on this topic is conceptual. AgentNode's permission-models guide lays out four permission dimensions clearly, and BeyondTrust's identity-governance piece covers the org-level program. Both are architecture. Neither hands you a review you can run against a specific agent's actual grant list today.

That's the gap. This post gives you the audit prompt: paste the agent's tools and permissions, get back an over-grant verdict with the exact permission to revoke.

Why agents drift toward over-privilege

Traditional apps get their permissions set once and change rarely. Agents are different — they choose their own operations at runtime, so the permission surface is the union of everything they might ever try, not the one thing they're doing now.

That structural fact, plus a framework reality, drives the drift. As the search results across vendor guides agree, LangChain, CrewAI, and AutoGen don't enforce tool-level permissions natively; a tool runs with the agent process's full rights. So the path of least resistance is to grant the process broad access and let every tool inherit it. Nobody sits down to scope the summarizer's file access to one directory. It just gets the whole disk.

The stance worth holding: an over-privileged agent is a bigger risk than an under-capable one. If a tool lacks a permission it genuinely needs, you find out immediately — it fails loudly and you grant the one thing. If a tool holds a permission it doesn't need, you find out never, until it's the pivot in an incident. Bias every grant toward too little.

What you can do with this audit

• Review every tool an agent holds against the job that tool actually does.
• Score each permission across four dimensions: network, filesystem, execution, data.
• Flag permissions granted for features that no longer exist.
• Catch the classic over-grants: unscoped tokens, whole-disk access, unrestricted shell.
• Produce a revoke list with a justification demand for anything kept.
• Re-run the same audit whenever the agent gains a capability.

Anatomy of the audit prompt

The audit takes the agent's declared tools and current permissions, then scores each against its stated job.

Variables:
  {{agent_purpose}}    – what the agent is for, in one sentence
  {{tool_inventory}}   – each tool + its current permissions
  {{permission_scopes}} – the tokens/scopes/roles it holds

Prompt:
  Role: security reviewer applying least privilege.
  Task: for each tool, score need across four dimensions:
    network, filesystem, code execution, data scope.
  Any permission not justified by the purpose is an over-grant.

Output contract (restate on the final line):
  per_tool: name -> per-dimension verdict (needed | over-granted)
  over_grants: ordered list of permissions to revoke first
  unjustified: tools whose purpose doesn't explain their access
  verdict: TIGHTEN | ACCEPTABLE + one-line reason

The {{agent_purpose}} variable is the whole game. Least privilege is meaningless without a stated job to measure against — you can't call a permission excessive if you never said what the agent is for. One honest sentence here ("summarize support tickets into a daily digest") makes every unnecessary grant obvious.

How to use the audit

1. Write the purpose narrowly

{{agent_purpose}} should be one specific sentence. Not "help the support team" — "read tickets from the last 24 hours and post a summary to one Slack channel." The narrower the purpose, the sharper the over-grant detection.

2. Inventory every tool honestly

{{tool_inventory}} lists each tool the agent can call and what it can currently do. Don't list the intended permissions — list the actual ones. The gap between the two is the finding.

3. Include the raw scopes

{{permission_scopes}} is the tokens, roles, and API scopes behind the tools. An agent that "reads tickets" via an admin token has an over-grant even if it never writes. The scope is the capability, regardless of current use.

4. Score all four dimensions

Network, filesystem, execution, data. A tool can be perfectly scoped on three and wide open on the fourth. The four-dimension split, straight from the standard framing, stops a "looks fine" verdict from missing the one open door.

5. Work the revoke list

over_grants is ordered by blast radius. Revoke the shell access and the unscoped token first. Then demand a written justification for anything you decide to keep — the justification is the audit trail.

Audit-craft patterns

Score per dimension, never per tool. A single "is this tool okay" verdict hides the open door. Force a verdict on network, filesystem, execution, and data separately for each tool. That's where you find the summarizer that reads fine but somehow also has execute.

For each tool, four verdicts:
  network:    needed | over-granted
  filesystem: needed | over-granted
  execution:  needed | over-granted
  data_scope: needed | over-granted

Demand a justification, not a removal, for kept grants. The audit shouldn't auto-revoke — it should force a sentence explaining why each kept permission is needed. A grant nobody can justify in one line is a grant to drop. The unjustified ones are your real backlog.

Re-audit on every capability add. The most dangerous over-grant is the one added last week for a feature you've since cut. Wire the audit into the change that adds a tool, so the grant list never accretes silently. A permission tied to dead code is pure attack surface.

Variables you'll set

Getting started

1. Write the agent's purpose as one narrow sentence.
2. Inventory every tool with its actual (not intended) permissions.
3. Add the raw token scopes and roles.
4. Run the audit and read the four-dimension verdict per tool.
5. Revoke the over-grants in blast-radius order.
6. Demand a one-line justification for everything you keep.
7. Re-run it whenever the agent gains a tool. The Agent Tool Least-Privilege Auditor ships this audit with the four-dimension scoring and the revoke-list contract built in.

Scoping permissions is half the job; governing how the agent behaves inside those scopes is the other half. The Agent Guardrails Policy system prompt sets the runtime rules, and the AI Agent Audit Trail Designer records what the agent actually did with the access it kept.

For the runtime side of agent safety, see the guardrails prompt for AI coding agents. And because over-privilege is the payload of most injections, the prompt-injection defense guide pairs directly with this audit.