Why a checklist specific to AI agents?
Because an agent is not a chatbot: it calls tools, reads data and acts without you approving each step. The risk changes nature, since a wrong answer becomes a wrong action.
OWASP defines Excessive Agency (LLM06:2025) as the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated model output, whatever the cause (hallucination or prompt injection). The checklist below turns that principle into verifiable points. It complements a full agent penetration test without replacing it.
How to use it: for each point, mark OK, To fix or Not applicable, with the evidence (screenshot, config line, log excerpt). A point without evidence is an unverified point.
What are the 20 points to check?
Here is the full checklist. Points marked Blocking must be resolved before any production release.
| No. | Family | Point to verify | Priority |
|---|---|---|---|
| 1 | Scope | Every agent tool is justified by a written use case | Blocking |
| 2 | Scope | No open-ended tool (free shell, arbitrary URL, free SQL) | Blocking |
| 3 | Scope | Service accounts hold minimal rights (read-only where possible) | Blocking |
| 4 | Scope | The agent acts with the rights of the user who calls it | Important |
| 5 | Scope | Secrets (keys, tokens) appear neither in the prompt nor in the context | Blocking |
| 6 | Inputs | All third-party content sources are listed (emails, pages, tickets, documents, RAG) | Blocking |
| 7 | Inputs | Third-party content is fenced as data and has no instruction authority | Important |
| 8 | Inputs | Incoming webhooks and APIs are authenticated | Blocking |
| 9 | Inputs | RAG applies access control before sending to the model | Blocking |
| 10 | Inputs | An indirect prompt injection test was run on every source | Blocking |
| 11 | Outputs | Model output is treated as untrusted before reaching another system | Blocking |
| 12 | Outputs | No automatic rendering of external images or links in the interface | Important |
| 13 | Outputs | Outbound calls are limited to a domain allowlist | Important |
| 14 | Outputs | The system prompt contains no sensitive data | Important |
| 15 | Approval | Human approval precedes any send, payment, deletion or sensitive write | Blocking |
| 16 | Approval | Limits (amounts, recipients, volumes) are enforced in code | Blocking |
| 17 | Observability | Every tool call is logged with its parameters and its trigger | Important |
| 18 | Observability | Rate and cost caps exist per user and per session | Important |
| 19 | Observability | An alert flags abnormal behavior (volume, new recipients) | Important |
| 20 | Operations | A kill switch and an access-revocation procedure are tested | Blocking |
The following sections explain the reasoning behind each family.
What to check on scope and permissions (points 1 to 5)?
Check that the agent can only do what its use case requires. OWASP separates three causes of Excessive Agency: too much functionality, too many permissions, too much autonomy. Points 1 to 5 address the first two.
A simple test: list the tools and, for each, write the sentence "the agent needs this to...". Any tool for which you cannot write the sentence should go. Prefer narrow tools ("create a draft reply") over open ones ("send an email to anyone"). For agents wired to MCP servers, apply the same logic to each server: our MCP security page details the risks.
What to check on inputs (points 6 to 10)?
Check that any content the agent reads but you do not control is treated as hostile. This is the territory of indirect prompt injection, described on our prompt injection page.
Point 10 is easy to forget: testing sometimes stops at the chat input without covering the email, web page or document the agent processes in the background. Point 9 also deserves attention: a RAG that indexes every document with no per-permission filter exposes data to any user who asks the right question.
What to check on outputs (points 11 to 14)?
Check that what the model produces can neither attack another component nor carry data out. OWASP (LLM05:2025, Improper Output Handling) asks you to treat the model as an untrusted user and validate its output before it reaches a downstream function.
In practice: context-aware encoding (HTML, SQL), parameterized queries, a strict content security policy (CSP) in the interface, and refusal to load external images or links generated by the model. On point 14, OWASP reminds us that the system prompt must not be treated as a secret or as a security control.
What to check on human approval (points 15 and 16)?
Check that no irreversible action runs without explicit agreement from a person, and that caps are hard-coded. A rule written in the prompt ("never refund more than 50 EUR") can be bypassed; a check inside the refund API cannot.
Make sure the approval is informed: the person must see the exact action (recipient, amount, content), not a summary written by the model. Otherwise an attacker can manipulate the summary.
What to check on observability and operations (points 17 to 20)?
Check that you will be able to detect, understand and stop a hijack. Without a tool-call log you cannot reconstruct what happened. OWASP recommends logging and rate limiting as damage-limiting measures.
Test the kill switch before you need it: who can shut the agent down, how fast, and how do you revoke the tokens it holds? A procedure that was never tried is a procedure that will fail on incident day.
In what order should you fix the gaps?
Start with the blocking points that touch permissions and human approval (1, 2, 3, 15, 16), because they reduce the impact of every other flaw. A successful injection against an agent with no dangerous rights causes little damage.
Then handle inputs (6 to 10) and outputs (11 to 14), then observability. Rerun the checklist whenever you add a tool or data source or change the model, and keep the evidence: it also helps during a client audit or a security questionnaire.
How do you go from checklist to real testing?
The checklist verifies the design; an adversarial test verifies that it holds against someone looking for the flaw. After the 20 points, have the agent attacked with real scenarios: booby-trapped content, attempts to leave the perimeter, tool abuse.
Our Agent Red Team Express (1,900 EUR, 5 days) covers exactly this step for one agent. For several agents or white-label delivery by an agency, see AI agent penetration testing. The overall approach is presented on our AI agent red teaming page.
Does your product ship an AI agent? CleanIssue tests what a stranger can make it do with the Agent Red Team Express (5 days, €1,900), or a custom red team for several agents and MCP servers.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
Human-in-the-loop: which AI agent actions need approval
Which AI agent actions require human approval? A risk-level table, the design pitfalls that break approvals, and six tests to try to bypass them.
Excessive Agency (LLM06): limit what an AI agent can do
Excessive Agency (OWASP LLM06:2025): reduce an AI agent's functions, permissions and autonomy, with a concrete test plan you can run today.
Function Calling: The AI Agent Attack Surface
Function calling and AI agents: five families of tool attacks, safer tool design and a testing protocol to limit unauthorized actions.
Sources
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.