Chapter 1 of 8 · 5 checks · 3 min
Tool inventory and least privilege
Every tool an agent holds is something an attacker can make it use. These checks keep the tool set small, narrow and enforced in code.
List every tool each agent can call, with what it can read, change and reachMust
Why it matters and how to check
You cannot reason about an agent's blast radius without a list of its tools. For each agent record the tools it loads (including those from MCP servers), whether each reads or writes, which systems and data it can reach, and which credential it runs with.
To verify, dump the tool list the model actually receives at runtime, for example by logging the tools array on one request, and compare it with the documented list. Anything present at runtime but missing from the document is an undocumented capability to review or remove.
Remove tools and functions the agent does not need for its taskMust
Why it matters and how to check
OWASP's guidance on excessive agency names three causes: excessive functionality, excessive permissions and excessive autonomy. A support agent that only needs to read orders should not also hold a refund tool, a generic HTTP fetch tool or a shell. Open-ended tools like "run any SQL" or "call any URL" are the hardest to secure, so replace them with narrow tools that do one thing.
To verify, for each tool in the inventory write the user task that needs it. Any tool without a task is removed. Then check that no generic shell, SQL or HTTP tool remains unless a reviewed design note explains why a narrower tool would not work.
Give each agent its own credentials, scoped to its tools and to the acting userMust
Why it matters and how to check
Identity and privilege abuse is on the OWASP agentic list because agents often run on one powerful shared service account. Give each agent its own identity, the narrowest scopes that cover its tools, short-lived tokens, and when it acts for a user, that user's permissions rather than its own wider ones.
To verify, read the credential each agent uses and list its permissions in the target system. Try one action the agent's tools do not need, such as deleting a record, with that credential directly. It should be refused by the target system, not just by your agent code.
Validate tool arguments and enforce limits in code, not in the promptMust
Why it matters and how to check
A system prompt that says "never refund more than 100" is a request, not a control. The MCP tools specification says servers must validate all tool inputs, implement proper access controls and rate limit tool invocations. Put allowlists, ranges, ownership checks and per-task caps in the tool implementation, where the model cannot talk its way past them.
To verify, call each write tool directly, bypassing the model, with out-of-range values, another user's record id and a burst of repeated calls. Every one should fail with a clear tool error, and the attempts should appear in your logs.
Separate read tools from write tools so they can be granted and approved separatelyShould
Why it matters and how to check
A single "manage_tickets" tool that reads, updates and deletes forces you to grant all or nothing. Split it into separate tools for read and for each kind of change. Then you can give read-only tools to an agent that has just processed untrusted content, and gate write tools behind approval.
To verify, check each tool's name and description: a reviewer should be able to tell from the name alone whether it changes state. Count tools that both read and write; aim for none.