Best Practices Guide

AI Agent Penetration Testing Scope: What to Include and Exclude

A boundary-setting framework for scoping AI agent pentests: what to include, exclude, and document before engagement so you avoid coverage gaps and duplicated effort.

Request a Demo Talk to an Expert

A defensible AI agent penetration testing scope explicitly includes tool invocation chains, memory and context persistence, MCP or equivalent tool-connector interfaces, agent identity and authentication, and agent-to-agent communication. It excludes underlying model provider internals and application or infrastructure layers already covered by standard pentests, unless agent logic directly alters their behavior. Document inclusions and exclusions before engagement to avoid coverage gaps or duplicated testing effort.

Why Standard Pentest Scope Falls Short for AI Agents

Standard application and infrastructure penetration tests cover web surfaces, APIs, networks, and host configuration. AI agents introduce additional attack surface that those engagements often miss: tool invocation chains, memory and context stores, connector protocols such as MCP, agent-specific identity, and agent-to-agent channels.

Agent-specific testing does not replace standard application penetration testing. It addresses attack surface introduced by tool use, memory, MCP interfaces, and agent identity. Standard application and infrastructure testing should continue covering the underlying web, API, and network layers the agent runs on. Scope both explicitly rather than assuming one covers the other.

Agent-Specific Attack Surface to Include

Treat the following as first-class scope items. Each represents a distinct manipulation or trust boundary that standard API or app testing rarely covers end to end.

  • Tool invocation chainsWhich tools an agent can call, under what conditions, and with what parameters.
  • Memory and context persistenceShort-term context windows and long-term memory stores as distinct manipulation surfaces. Test short-term context window manipulation separately from long-term memory store manipulation.
  • MCP interfacesAuthorization between client, host, and server outside the traditional application boundary. Test MCP or equivalent tool-connector endpoints independently of the underlying application API.
  • Agent identity and permissionsHow an agent authenticates to tools and whether it uses its own credentials or impersonates a user. Verify how that identity is checked at each tool call.
  • Agent-to-agent communicationProtocols and trust assumptions that differ from agent-to-tool or agent-to-user interaction. Document and test this channel separately.

Also include permission boundaries under dynamic conditions. Where tool access depends on context (user role, task state, or similar), validate least privilege across representative context states rather than a single static permission set.

What to Exclude, and Why

Exclude underlying model provider internals from agent pentest scope. Model weights, training pipelines, and provider-side inference infrastructure are usually outside the customer’s control and outside what an application-layer agent engagement can meaningfully exercise.

Exclude application and infrastructure layers already covered by standard pentests, unless agent logic directly alters their behavior. Re-testing the same web routes, generic APIs, or network controls without an agent-specific path creates duplicate effort and can dilute focus on agent-only findings.

When agent behavior changes how those layers enforce access or process data, bring only the affected paths back into scope and document the boundary clearly.

Common Scoping Mistakes

  • Undefined prompt injection boundary: Scope should state whether prompt injection testing covers only direct user input or also indirect content the agent ingests via tools, documents, or retrieval. Leaving this undefined causes disputes over whether a finding was in scope.
  • Static permission assumption: Where agent tool access depends on context, such as user role or task state, testing a single fixed permission set will miss escalation paths that only appear under certain conditions.
  • MCP endpoints treated as standard APIs: MCP defines authorization between client, host, and server outside the traditional application boundary and warrants testing as its own interface rather than folding into general API testing.
  • No tool manifest provided: Without a current list of tools, parameters, and permission scopes, testers cannot assess whether granted access exceeds task requirements, a gap OWASP describes as excessive agency.
  • Agent-to-agent communication left unscoped: Where agents coordinate with other agents, that channel may use different protocols and trust assumptions than agent-to-tool interaction and should be scoped separately rather than assumed covered.

Prompt injection: make the boundary explicit

Indirect injection (content ingested from documents, web pages, or tool output) is a distinct attack path from direct user input and typically requires separate test cases and success criteria. Treat inclusion of indirect content as a stated scoping decision, not an assumption.

Artifacts to Provide Before Engagement

Hand testers concrete artifacts so scope is testable, not theoretical. At minimum, prepare the following.

Scope checklist

Use this list to define inclusions, exclusions, and supporting documentation before the engagement starts.

  • Tool invocation paths: which tools an agent can call, under what conditions, and with what parameters
  • Memory and context persistence: short-term context window manipulation tested separately from long-term memory store manipulation
  • MCP or equivalent tool-connector endpoints: authorization and authentication tested independently of the underlying application API
  • Agent identity: whether the agent authenticates with its own credentials or impersonates a user, and how that identity is verified at each tool call
  • Agent-to-agent communication: protocol and trust assumptions documented and tested separately from agent-to-tool interaction
  • Permission boundaries under dynamic conditions: least-privilege validation across representative context states rather than a single static permission set
  • Tool or function manifest listing tool names, parameters, and permission scopes
  • Agent architecture diagram covering tool invocation paths, memory and context stores, MCP or connector endpoints, and identity flow
  • Permission model documentation, including any dynamic or context-dependent access rules
  • Audit and logging artifacts covering tool calls and agent decisions, needed to validate findings and reconstruct attack chains

Scoping questions security engineers ask

Does AI agent penetration testing replace standard application penetration testing?

No. Agent-specific testing addresses attack surface introduced by tool invocation, memory, MCP interfaces, and agent identity. Standard application and infrastructure testing should continue covering the underlying web, API, and network layers the agent runs on. Scope both explicitly rather than assuming one covers the other.

Should prompt injection testing include indirect content the agent retrieves through tools?

This should be a stated scoping decision, not an assumption. Indirect injection, content ingested from documents, web pages, or tool output, is a distinct attack path from direct user input and typically requires separate test cases and success criteria.

How should MCP security testing be scoped separately from general API testing?

MCP defines authorization between client, host, and server outside the conventional application boundary. Scoping it as its own interface layer, with authentication and authorization tested independently of the underlying application API, avoids gaps that occur when MCP is assumed to inherit standard API coverage.

What if agent permissions change based on context or task state?

Static permission testing will miss escalation paths that only appear under certain conditions. Scope testing around representative context states, such as different user roles or task stages, rather than a single fixed permission set, to validate least privilege across the agent’s actual operating range.

Define Your Agent Pentest Scope Before You Engage a Tester

Trussed AI provides runtime governance for AI agents, including MCP security, agent identity and permissions, tool approval workflows, and audit logging, the artifacts and controls a well-scoped pentest depends on.

Request a Demo