AI agent security testing

A chatbot that only answers can only say wrong things. An agent can do wrong things, with the access you gave it. The NCSC puts the problem this way: “it’s very possible that prompt injection attacks may never be totally mitigated in the way that SQL injection attacks can be.” (NCSC) It adds: “we instead need to approach it by seeking to reduce the risk and the impact.” (NCSC)

So the question for a test is not only whether the model can be fooled. It is what happens next: which tools it can call, with whose identity, on what data, and who is asked before anything irreversible. The NCSC’s blog post says: “Design protections need to therefore focus more on deterministic (non-LLM) safeguards that constrain the actions of the system” (NCSC).

• Tools and permissions: every tool the agent can call, and what each can read, write or delete.
• Identity: whose credentials the agent uses, how long they last and what else they open.
• Inputs it trusts: web pages, documents, email, retrieved data, other agents, tool descriptions.
• Memory and context: what it stores between runs, and who can write to it.
• MCP servers and plugins: where each came from, how it is started, what it can reach, whether remote ones need sign-in.
• Human approval: which actions ask a person, and whether the prompt shows what will really happen.
• Code execution: anything that runs commands or code, and where.

Give the tester test accounts, the tool list and the configs. Our guide to what to send for a quote covers the basics.

The IDs give you and your tester a shared name for each risk. OWASP describes it as a peer-reviewed framework of the most critical security risks facing autonomous and agentic AI systems. The item titles below are as listed in OWASP’s launch post for the 2026 edition (December 2025).

Ask your tester which published version of the list they map to.

The Model Context Protocol lets an assistant connect to servers that offer tools. Three things make it a testing target.

Tool descriptions are read by the model. Invariant Labs defines tool poisoning like this: “A Tool Poisoning Attack occurs when malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models.” (Invariant Labs) The MCP specification says descriptions of tool behaviour, such as annotations, should be considered untrusted unless they come from a trusted server.

Local servers are programs you run. The specification’s security guidance lists an attacker putting a malicious startup command in a client configuration as an attack on local servers, and tells clients to warn that servers run with the same privileges as the client.

Authorization is optional. The specification says so. A remote server that asks nobody to sign in may answer whoever finds its address.

Paste a config into the MCP config checker for a first look. It runs in your browser and is a pattern check, not a test.

OWASP MCP Top 10

OWASP’s page presents the MCP Top 10 as a beta: its roadmap says Phase 3, beta release and pilot testing, is the current phase. Titles may change before the final release.

• MCP01:2025 Token Mismanagement & Secret Exposure
• MCP02:2025 Privilege Escalation via Scope Creep
• MCP03:2025 Tool Poisoning
• MCP04:2025 Software Supply Chain Attacks & Dependency Tampering
• MCP05:2025 Command Injection & Execution
• MCP06:2025 Prompt Injection via Contextual Payloads
• MCP07:2025 Insufficient Authentication & Authorization
• MCP08:2025 Lack of Audit and Telemetry
• MCP09:2025 Shadow MCP Servers
• MCP10:2025 Context Injection & Over-Sharing

Both lists sit alongside OWASP’s list for LLM applications. In its 2025 edition, items that apply to agents include LLM01:2025 Prompt Injection, LLM06:2025 Excessive Agency, LLM07:2025 System Prompt Leakage. OWASP’s site also lists an OWASP GenAI LLM Top 10 2026, dated August 3, 2026, so ask which edition a tester or customer means.

These CVEs are in MCP reference servers, a debugging tool, a connection helper and a code editor, as NVD describes them. They show what testers find: command injection, missing authentication on a local developer tool, files outside the allowed folder, and a trusted config swapped for a malicious one. Scores are shown as NVD lists them, with who supplied each: NVD’s own score, or the score from the CVE’s numbering authority (CNA). Some records have only the CNA’s.

Read the NVD record for each before you rely on it: scores and affected versions can change.

• A map of what the agent can reach, tool by tool, and what it should reach.
• Proof of what an injected instruction can do, with the steps to repeat it.
• Findings tied to the OWASP IDs your customer or auditor uses.
• Fixes that limit impact (narrower permissions, approvals, separate identities) rather than only a longer prompt.
• A retest after the fixes.