AI & agent security

Test the AI in your product like an attacker will.

You shipped an AI feature or an agent. It reads data, calls tools and acts under real permissions — and almost nobody has security-tested it. AI agent penetration testing covers prompt injection, tool-call and permission boundaries, the MCP servers your agent trusts, and structured red-teaming — and proves each result with a canary before it counts.

AI & agent security · 24 October 2026By Enes Çetinkaya

The short version: an AI agent's risk is not what it can be made to say — it is what it can be made to do. Penetration testing for AI features targets the whole product: the model, the tools it can call, the data it reads, the identities it acts under and the app around it. SuperPentest tests all of it, and reproduces every candidate with a unique canary before calling it a finding.

What AI agent penetration testing is

It is security testing of the AI inside a product by an attacker-minded tester, not a scanner. A scanner has no concept of an agent that reads a document, decides to call a tool, and acts under a user's permissions — there is no static signature for "the agent was talked into doing something it shouldn't." Testing it means driving the feature the way an attacker would and watching what the agent actually does, then proving the result reproduces.

This is distinct from model red-teaming, which probes a model in isolation. Real incidents come from the agent's reach: the tool it can call, the data it can exfiltrate, the action it can take on behalf of someone who never asked. So the unit of testing is the product, not the prompt.

The attack surface of an AI feature

  • Inputs the agent trusts — user messages, but also every piece of data it reads while working: tickets, documents, web pages, database rows, tool results. Any of these can carry instructions.
  • Tools the agent can call — search, email, database, code execution, payments. The blast radius of a successful injection is the set of tools in reach.
  • Identities and permissions — what the agent is allowed to do, and whether it can be steered past that.
  • Connected MCP servers — external tools and data the agent trusts, each its own surface.

Prompt injection — direct and indirect

Direct injection is the attacker typing instructions into the agent. Indirect (second-order) injection is the dangerous one: instructions hidden in data the agent reads later during a normal task, so a legitimate user's session carries out the attacker's intent. We prove it with a canary — a unique value that exists only inside the injected content, so that if it surfaces in the agent's action, the agent provably read and acted on attacker-controlled data. The full method is in the prompt-injection canary teardown.

Attacker plants hidden text Data the agent reads ticket · doc · web page ● canary-XYZ injects Legitimate user normal task AI agent reads, then acts asks reads ● Tool call ● canary-XYZ canary in the tool call = proof it acted on it
Indirect injection: the attacker never talks to the agent. A unique canary rides in on data the agent reads during a legitimate user’s task — and surfacing in the agent’s tool call is what proves the agent acted on attacker-controlled input.

Tool-call and permission boundaries

The question is not "can the model be confused" but "can it be steered into a dangerous tool call, or beyond its authority?" We test whether injected or adversarial input can make the agent call a tool it shouldn't, pass arguments it shouldn't, or reach data and actions outside the identity it is acting under. These boundaries are tested, never assumed — a tool the agent can call is a tool an attacker will try to reach through it.

MCP (Model Context Protocol) servers

MCP is a standard way for an agent to connect to external tools and data sources. Every MCP server your agent trusts is an attack surface in its own right: its tools can be abused, the data it returns can carry injected instructions into your agent, and its granted permissions can be broader than the task needs. We test connected MCP servers directly rather than treating them as trusted plumbing.

Proof, not vibes

AI findings are the easiest to fake and the hardest to trust — a screenshot of a model saying something odd proves nothing. That is why every candidate here is reproduced from a clean session before it is recorded, with the canary, the payload, the agent's action and the replays captured as hash-chained evidence. And the honesty cuts both ways: a clean result means the paths we tested held, not that the agent is safe everywhere. Coverage is reported as evidence — what was tested, what had no eligible surface, what was blocked.

FAQ

What is AI agent penetration testing?

Security testing of the AI features and agents inside a product — the model, its tools, its data and its permissions — by an attacker-minded tester. It covers prompt injection, tool-call and permission boundaries, MCP attack surface and structured red-teaming, with each result reproduced before reporting.

How is it different from model red-teaming?

Model red-teaming probes a model in isolation. AI agent penetration testing targets the whole product — the agent plus the tools, data, identities and app around it — because impact comes from what the agent can do, not just what it can be made to say.

What is MCP and why test it?

MCP (Model Context Protocol) is a standard way for an agent to connect to external tools and data. Each connected server is an attack surface: its tools can be abused, its data can carry injected instructions, its permissions can be over-broad. We test them directly.

Have an AI feature nobody has tested? Book a demo, read the canary teardown, or browse the research.