AI Agent Security Testing: Pentest Methodology 2026

Key Findings (2026 from Cybersecify AI agent engagements):

• Across the AI agent engagements Cybersecify ran in the first half of 2026, indirect prompt injection via tool output was the most common finding.
• Over-privileged agent tokens were common (broader production scope than any human user).
• Missing rate limiting on the agent endpoint was common.
• Memory poisoning across user sessions appeared in a minority of engagements.
• The 4-layer attack surface map below (planning, tool calls, memory, non-determinism) is the methodology Cybersecify uses to surface these findings.

---

Pentesting an AI agent (also called an LLM agent in current shorthand) in 2026 means testing four layers a web application does not have: a planning layer that interprets natural language and decides actions, a tool layer where the agent calls external systems with privileges, a memory layer that persists context across runs, and non-deterministic behavior that produces different outputs for identical inputs. The methodology adds prompt injection at multiple input points, tool poisoning, memory poisoning, agent privilege escalation through tool chains, and hallucinated dependency abuse on top of standard web application testing. This post walks the threat model, the attack surface map, the test cases we run in our engagements, and the most common findings. For Series A SaaS founders building agentic features, this is what you should expect a pentest to cover.

Why AI agents need their own pentest methodology

A traditional web application has a request-response shape. The user sends an HTTP request, the server processes it, returns a response. Authentication, authorization, and input validation are well-understood. Pentest methodology for web apps is mature: OWASP Top 10, OWASP WSTG v4.2, PTES.

The engagement this describes is our AI agent penetration testing work, with the surfaces, the frameworks and the price stated up front.

An AI agent breaks every assumption that methodology was built on:

1. The user’s input is a natural language instruction, not a structured request. The agent interprets it, plans, and executes a sequence of actions. Authorization is harder when the action set is open-ended.
2. The agent calls tools (APIs, databases, external systems) on behalf of the user. The tools have their own authentication and authorization. The agent is a privileged intermediary with broader access than any individual user.
3. The agent has memory. Previous conversations, retrieved documents, and stored facts influence current behavior. An attacker who controls any input source eventually controls the agent.
4. The model is non-deterministic. The same prompt may produce different outputs across runs. Reproducibility is harder. Coverage is harder.

These are not minor variations on web app testing. They are a different system. Pentesting an AI agent with web app methodology alone is like running a network scanner against a database server: you find some things, miss others, miss the ones that matter.

Attack surface map for AI agents

We use this four-layer model when scoping agent engagements:

Layer 1: User input (natural language)
   ↓
Layer 2: Planning (LLM decides what to do)
   ↓
Layer 3: Tool calls (external systems with privileges)
   ↓
Layer 4: Memory + state (persistence)

Each layer has its own attack surface. Each layer can be the entry point. A vulnerability at any layer can compromise the agent end to end.

How we scope each layer: Our AI Application Pentest service tests all four layers in a single engagement, with extra time budgeted for the tool layer (typically the largest attack surface in production agents). Scope is based on tool count + memory architecture + orchestration depth, not endpoint count.

Layer 1: User input

Standard web application input validation applies (XSS, SQLi if input flows into a database, command injection if input flows into a shell). Plus prompt injection: an attacker provides input that the LLM treats as instructions instead of data. See our prompt injection 2026 patterns post for the full taxonomy.

Layer 2: Planning

The LLM receives user input plus system prompt, plus tool descriptions, plus retrieved context. It decides which tool to call with which arguments. Attack surface here:

• Indirect prompt injection through retrieved documents. The agent reads a document, the document contains an instruction, the agent follows it.
• Tool description poisoning. An attacker who can modify tool descriptions can change agent behavior without modifying user input.
• Plan manipulation. The agent can be tricked into multi-step plans that individually seem reasonable but together produce harm.

Layer 3: Tool calls

The agent invokes APIs, databases, file systems, web requests, code execution, email, payment, anything you have wired up. Attack surface here:

• Over-privileged agent. Most common finding. The agent has production tokens broader than any human user. A successful prompt injection inherits all of those privileges.
• Tool argument injection. The agent calls a tool with attacker-controlled arguments. If the tool does not validate (because it trusted the agent), classic injection vulnerabilities reappear.
• Tool chaining for privilege escalation. Tool A returns data the agent passes to Tool B. The combined effect exceeds either tool’s intended privilege.
• Side-effect tools. The agent calls a tool that writes to email, slack, payment systems, or production databases. Confirmation steps are often skipped under prompt-injection-induced reasoning.

Layer 4: Memory and state

Persistent context across sessions, RAG vector stores, conversation history, user preferences. Attack surface here:

• Memory poisoning. An attacker injects content into the agent’s memory that influences future sessions for other users.
• RAG poisoning. An attacker contaminates the document store the agent retrieves from. Future retrievals return the poisoned content.
• Cross-user memory leakage. Memory implementation accidentally shares context across user sessions.
• Memory exfiltration. The agent is induced to reveal stored memory contents in responses.

Test cases we run

The following test cases are run in every AI agent engagement. Specifics vary by agent architecture, tool set, and use case, but the categories are consistent.

1. Direct prompt injection at user input

Adversarial prompts at the user-facing input. Goals: bypass safety filters, extract system prompt, change agent persona, induce unauthorized tool calls. Tools: Garak, PyRIT, promptfoo, custom payloads.

2. Indirect prompt injection through retrieved content

We embed adversarial instructions in documents the agent retrieves: web pages, email content, support tickets, attached files. The agent reads, follows the embedded instruction, executes outside the user’s intent. This is the highest-severity finding pattern in 2026 because mitigation is structurally hard.

3. Tool poisoning

If the agent reads tool descriptions from a configurable source, we test whether modified tool descriptions change agent behavior. We also test whether new tools introduced at runtime are accepted without validation.

4. Tool argument injection

For each tool the agent can call, we test whether attacker-controlled prompt content can produce attacker-controlled tool arguments. Classic SQL injection, command injection, and SSRF patterns reappear here when tools trust agent-supplied arguments.

5. Tool chain privilege escalation

We map the agent’s tool graph. Identify tool combinations where Tool A’s output becomes Tool B’s input in ways that exceed either tool’s expected privilege. Test for unauthorized read-then-write patterns, cross-tenant data leakage, and information aggregation that violates least-privilege intent.

6. Memory and RAG poisoning

For agents with persistent memory or RAG, we test whether memory entries created by one user influence behavior for other users. We poison the document store with adversarial content and observe retrieval and downstream agent behavior.

7. Plan manipulation

Multi-turn conversations where each turn is benign but the cumulative state drives the agent toward a harmful action. The agent’s plan is the attack surface, not any single message.

8. Hallucinated dependency abuse

If the agent generates code that imports packages, we check whether non-existent package names are generated. An attacker who squats those names on npm or PyPI gains code execution if the generated code runs anywhere automated.

9. Output validation and information disclosure

The agent’s response is itself an attack surface. We test whether the agent reveals system prompt, internal tool descriptions, other users’ data from memory, or sensitive information from retrieval that the user should not see.

10. Authentication and authorization integration

Standard web application auth and authz tests applied to the underlying API endpoints, plus tests specific to agent context: does the agent enforce per-session authorization on tool calls, are there ways to escalate privileges by exploiting agent state, can the agent be tricked into bypassing auth checks intended for human users.

Most common findings (2026)

From our engagements over the past 12 months, the top three findings in AI agent pentests are:

1. Over-privileged agents. Agent has production credentials with scopes broader than any human user.
2. Indirect prompt injection through retrieved content. Tool outputs, retrieved documents, or external content steer the agent’s behavior.
3. Insufficient output validation. Agent reveals system prompt, internal context, or other-user memory in responses.

The first two account for most of the high-severity findings we see. The fix patterns are well-understood but consistently missed in implementation.

2026 framework alignment: what we test maps to what auditors and standards expect

A SOC 2 / ISO 27001 / regulated-sector audit on an AI agent product expects the pentest to map findings to recognized AI-security frameworks. The four most relevant in 2026:

• OWASP Top 10 for LLM Applications (2026): LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling. Released 4 August 2026, superseding the 2025 edition: most categories were renumbered and System Prompt Leakage was renamed Hidden Context Exposure, so codes quoted from a 2025 report do not carry over.
• OWASP Top Ten for Agentic Applications (ASI): extends the LLM Top 10 with agent-specific risks (ASI01 Agent Behaviour Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory and Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation, ASI10 Rogue Agents). It is a first public draft, not a released standard, so treat it as coverage structure rather than as report identifiers. The areas below are OUR test categorisation, not OWASP identifiers: tool-call hijacking, MCP (Model Context Protocol) server poisoning, multi-agent goal manipulation, agent identity confusion, persistent memory poisoning across sessions, agent privilege escalation through tool chains.
• MITRE ATLAS: adversarial threat landscape for AI systems. Tactics and techniques framework analogous to MITRE ATT&CK for traditional security. Findings can be mapped to specific ATLAS technique IDs for the audit appendix.
• NIST AI 100-2e2025 (Adversarial Machine Learning Taxonomy): NIST’s January 2025 update covers adversarial attacks against ML systems including generative AI. Useful for findings classification and remediation guidance.

Each of the ten LLM categories is explained in full, with real disclosed incidents mapped to them, in our OWASP Top 10 for LLM Applications reference.

Mapping our 10 test cases to these frameworks:

Our test case	OWASP LLM Top 10	Agentic risk area (our categorisation)	MITRE ATLAS	NIST AI 100-2e2025
Direct prompt injection (user input)	LLM01	Prompt injection in agent context	AML.T0051	Evasion attacks
Indirect prompt injection (retrieved content)	LLM01 + LLM05	Indirect injection via tools	AML.T0051.001	Evasion via poisoned input
Tool poisoning (compromised tool definitions)	LLM04	MCP server poisoning	AML.T0010	Supply chain attacks
Tool argument injection	LLM03 + LLM10	Tool-call hijacking	AML.T0048	-
Tool chain privilege escalation	LLM03	Agent privilege escalation	AML.T0020	-
Memory and RAG poisoning	LLM05 + LLM09	Persistent memory poisoning	AML.T0070	Data poisoning
Plan manipulation	LLM03 + LLM07	Multi-agent goal manipulation	AML.T0051	-
Hallucinated dependency abuse	LLM04 + LLM07	Slopsquatting / hallucinated package	AML.T0010.002	-
Output validation + information disclosure	LLM02 + LLM08 + LLM10	Output channel exfiltration	AML.T0024	-
Authentication and authorization integration	n/a (covered by web app methodology)	Agent identity confusion in multi-tenant	-	-

Reports from our Growth Pentest plan include this mapping in the report appendix so the auditor can cross-reference each finding to the framework they care about. Without the mapping, the auditor has to do the work post-hoc, which slows the audit by 1 to 4 weeks.

Named 2026 attack patterns worth calling out

These overlap with the test cases above but are worth surfacing by name because they’re the patterns surfacing in 2025-2026 incidents and security research:

• MCP (Model Context Protocol) server poisoning: when an agent connects to a Model Context Protocol server (the emerging standard for tool integration in 2025-2026, e.g., Claude’s MCP, OpenAI’s tool calling), the tool definitions themselves can be poisoned. A compromised MCP server can serve malicious tool descriptions that the agent treats as ground truth. Tested under our test case 3 (Tool poisoning).
• Indirect prompt injection via external content: the highest-priority attack vector identified in 2025-2026 production incidents. An external document (email, web page, RAG knowledge base, tool output) contains instructions that the LLM treats as system-level prompts. Tested under our test case 2.
• Guardrail evasion via tokenizer misalignment: exploiting differences between guardrail tokenization and model tokenization to slip restricted content past safety filters. Tested as part of test case 1.
• Denial-of-wallet (token exhaustion) attacks: adversarial prompts designed to maximize token consumption at the runtime layer, exhausting the application’s LLM API budget. Maps to OWASP LLM06 (Unbounded Consumption) in the 2026 edition. Tested under test case 4 (Tool argument injection) when the tool consumes LLM tokens.
• Multi-agent goal manipulation: in multi-agent pipelines, one agent’s output becomes another agent’s instruction. A malicious actor manipulates the chain by injecting goals at one stage that propagate downstream. Tested under test case 7.
• RAG knowledge base poisoning: pre-populating the agent’s retrieval corpus with adversarial documents that are later surfaced as authoritative context. Tested under test case 6.

How AI agent pentest fits into your security program

An AI agent pentest is not a replacement for traditional web application pentest. The underlying API surface, the authentication layer, the database, the cloud infrastructure all need standard testing. Agent-specific testing extends the standard methodology with the four layers above.

For a Series A SaaS startup with an AI agent feature in production, we recommend:

• First engagement: standard web app pentest plus agent-layer testing. Combined scope. Typically a Growth plan engagement at INR 1,79,999 plus one additional scope for agent depth at INR 74,999 = INR 2,54,998 total. 12 to 14 business days.
• Annual cadence: repeat the combined engagement annually as the agent’s tool set and memory architecture evolves. Agentic features change faster than typical web apps; the pentest cadence should reflect that.
• Continuous monitoring: for high-stakes agents (financial, healthcare, legal), add bug bounty or continuous testing through one of the AI-specific platforms. Static annual testing alone is insufficient.

See our AI Application Penetration Testing service page for scope details, or our pricing page for plan options.

Where to go from here

If you have an AI agent in production or in pre-production scoping and want to understand what a real pentest would cover, book a free 30-min call with Ashok to scope the engagement. For plan options, see our AI Application Pentest service page and pricing.

We work with AI-first and API-first SaaS startups, Seed to Series B, primarily based in Bengaluru.

Want to see how we report AI findings? Our sample penetration test report is published in full, no email gate. For what an AI scope covers and where it stops, see AI and API penetration testing.

Corrections

• 2026-08-09: Replaced per-engagement frequency statistics on this page with qualitative descriptions of what we find most often. The underlying observations are unchanged, but we do not publish a per-engagement findings register, so precise counts are not something a reader can check.