Agentic AI Penetration Testing: MCP, Tool Abuse, Identity and Memory

How to test AI agents that can take real actions: MCP and tool security, delegated identity, excessive agency, memory poisoning, approval gates, inter-agent trust and failure handling.

An agentic AI system can plan, retain state, call tools and delegate work. That turns a model response into a sequence of operations performed under real identities and permissions. Model Context Protocol (MCP) makes tool and context integration easier, but it does not remove the need for authorization, least privilege, input validation or egress control.

Why agentic systems need a different test model

The core question is authority, not intelligence

An agent becomes dangerous when untrusted information can influence an identity that has useful permissions. The model does not need to be unusually capable. A mediocre planning step can still create a serious incident if the application lets it send mail, change code, modify cloud resources, query sensitive data or call a privileged internal API.

Map the authority available at each step: the end user, the application service account, delegated OAuth tokens, MCP server credentials, cloud roles and downstream service identities. A large share of agentic risk comes from authority silently increasing as a workflow crosses those boundaries.

Traditional LLM testing often stops at the response. Agentic testing continues through planning, tool selection, execution, memory and delegation. The key risk is not that the model says the wrong thing; it is that the system converts a manipulated decision into a privileged side effect.

OWASP's Top 10 for Agentic Applications (2026) reflects that shift. It covers goal hijacking, tool misuse, identity and privilege abuse, supply-chain risk, unexpected code execution, memory/context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation and rogue agents.

Agentic risk areas at a glance

MCP is an integration protocol, not a security boundary

MCP standardizes how clients discover and interact with tools and context providers. Security still depends on how the client and server authenticate, authorize and isolate those interactions. In May 2026, the NSA AI Security Center and Carnegie Mellon SEI published guidance focused specifically on securing MCP deployments, reflecting how quickly MCP had moved into production environments.

Authorization and the confused-deputy problem

Test whether the tool acts for the user or merely on behalf of the application

A common design mistake is to authenticate the user at the chat layer and then execute tools with a broad backend identity. The agent appears to respect user permissions until a tool call reaches a service that only sees the application credential. Test the same action with users at different privilege levels and verify that downstream authorization still reflects the initiating user.

Where delegation is intended, check token audience, scopes, expiry and whether the tool can exchange or reuse a token for a different resource. If delegation is not intended, the backend needs its own policy that constrains what the service identity may do for each request.

A confused deputy occurs when a more privileged component performs an action on behalf of a less privileged caller without checking whether that caller is entitled to the outcome. In an agent workflow, the model may be able to reach a tool backed by a service account that has broader access than the user. Test authorization at the tool boundary using the end-user or delegated identity rather than relying on the agent's broader service identity.

Tokens, audience and delegation

Review how access tokens move between the AI application, MCP clients, MCP servers and downstream APIs. Test audience, scope, expiration and token exchange. A token issued for one service should not silently become a general credential for another. Avoid raw token passthrough where it causes downstream systems to lose the original caller context.

Make least privilege concrete. Use narrow per-tool scopes where the architecture allows it, prefer read-only access for retrieval tasks, separate credentials for side-effecting actions, and restrict where tools can send data. Prompt instructions can reinforce those controls, but they should not be the layer that decides whether an action is authorized.

Tool descriptors and tool poisoning

Agents often rely on names, descriptions and schemas to decide when and how to use a tool. Treat those descriptors as security-relevant input. A malicious or compromised tool definition can influence tool selection or persuade the model to send data it did not need to send. Test signed/approved tool registries, schema validation and whether a new or changed tool receives the same trust as a known one.

SSRF and backend egress

MCP and agent tools frequently fetch URLs, resolve metadata or call internal services. That creates SSRF and egress risk even when the user never sees a conventional URL field. Test DNS/IP normalization, redirect handling, cloud metadata addresses, link-local/private networks, protocol restrictions and allowlist exceptions. Verify actual network behaviour rather than assuming a setting named 'allowed addresses' or 'trusted domain' is safe by definition.

Local MCP servers and developer workstations

Local tool servers can expose files, shells, package managers, source repositories and credentials on a developer machine. Test bind addresses, authentication, origin assumptions, local proxy exposure and command/file parameter handling. A local-only service can still be reachable through browser or network tricks if the surrounding assumptions are weak.

Memory and inter-agent trust

Persistent memory changes the lifetime of an attack. A malicious instruction saved today can influence a later task after the original input is gone. Test who can write memory, which users or agents can read it, whether provenance is preserved and whether poisoned entries can be reviewed or removed.

For multi-agent systems, do not assume an internal agent is trusted simply because it is internal. Authenticate messages, preserve the originating identity, validate structured data and re-check authorization when authority crosses an agent boundary.

Human approval is a control only if the human sees the right thing

Approval has to bind to the exact action

A confirmation screen that says “allow this task” is weak if the model can change the destination, amount, repository, command or attachment after approval. The human should see the material parameters of the action and the system should execute the approved version, not regenerate it afterwards.

Test race conditions and multi-step workflows as well. An agent may obtain approval for a benign first step and then use the resulting token, file or context to perform a riskier second step that never reaches the approval layer.

A confirmation button can become ceremonial if the interface hides the destination, amount, file path or data being transmitted. Test approval screens for context, transaction binding and race conditions. High-impact actions should be reversible where possible and should generate logs that show who approved what.

Test transient failure as well as the happy path. If a read-only tool is unavailable, an API times out or a preferred action is denied, the agent should not silently choose a more privileged tool or reuse broader credentials simply to complete the task.

A realistic chained attack path

Consider a support agent that retrieves tickets, can fetch URLs and can send email. A poisoned ticket contains an indirect instruction. The model follows it and calls the URL tool. Broad egress lets the tool reach an internal endpoint, and the result contains a secret. The agent then uses its email tool to send the data externally. No single step requires a dramatic jailbreak. The risk comes from the chain and the authority attached to each tool.

A useful penetration test reports that chain as one story and identifies which deterministic control would stop it: retrieval trust, egress restriction, secret isolation, tool authorization or outbound destination policy.

How to test an agentic/MCP system

Run negative tests against failure and recovery behaviour

Deny a permission. Expire a token. Remove a tool. Make the preferred MCP server unavailable. Return malformed output from a tool. Block egress. Then watch how the agent adapts. Safe systems should fail closed or ask for a new decision. Unsafe ones may retry with broader credentials, select a more powerful tool, expose internal error context or continue on an invented assumption.

Also verify that stopping the visible conversation actually stops background work. Long-running tasks, queued tool calls and delegated sub-agents need cancellation, timeout and kill-switch behaviour that can be observed and audited.

• Inventory agents, MCP clients/servers, tools, model providers, memory stores, identities and external destinations.
• Map the effective permissions of each tool and service account.
• Test direct and indirect goal hijacking from prompts, documents, tool output and agent-to-agent messages.
• Test tool descriptors, schemas and parameters as untrusted input.
• Test delegated identity, token scope/audience and confused-deputy paths.
• Test SSRF, backend egress, local-service exposure and file/command access.
• Test persistent memory and cross-agent provenance/authorization.
• Test approval gates with realistic high-impact actions.
• Chain weaknesses and record the resulting business impact instead of stopping at isolated prompt behaviour.
• Re-test after material tool, permission, model or orchestration changes.

Telemetry is part of the security boundary

Agentic systems are difficult to investigate if logs only show the final model response. Useful telemetry links the initiating user, model decision, tool selected, arguments passed, credential or role used, downstream result, approval event and any delegated sub-task. Sensitive prompt content still needs appropriate handling, but the action chain must be reconstructable.

That trace also makes testing much stronger. Instead of claiming that “the agent ignored policy,” the report can show exactly where attacker-controlled context changed a decision and which authority converted that decision into an external action.

Evidence worth knowing

Two developments are particularly useful context for 2026. OWASP published a dedicated Top 10 for Agentic Applications, separating agentic risks from the older single-model view. The NSA AI Security Center and Carnegie Mellon SEI also published MCP security guidance in May 2026, emphasizing secure architecture, authorization and isolation. Earlier, the 2025 EchoLeak vulnerability in Microsoft 365 Copilot demonstrated how indirect prompt injection could be chained into data exfiltration without a conventional user prompt. The lesson for testers is to follow untrusted content through every privileged action it can influence.

Assess agents and MCP as a system

RedSecLabs scopes agentic AI testing around the tools, identities, data and side effects your application actually exposes, including MCP clients/servers, RAG and multi-step attack paths.

AI & LLM Penetration Testing Services  https://www.redseclabs.com/services/pentesting-services/ai-llm-penetration-testing-services