Red-Teaming the Pentest Agent: Prompt Injection, Tool Poisoning and Credential Safety

Sources checked: 12 November 2026. FailSafe Research.

A pentest agent is a high-authority system that reads hostile input. It parses target responses, tool descriptions and retrieved content, then decides what to run. If you would not accept that behavior from a production service, test the agent with the same care you apply to the target.

Why the agent is part of the attack surface

The agent holds credentials, chooses actions and can keep context across steps. A malicious page, API response or tool definition is an input to that decision. The question is whether untrusted content can change the plan, redirect a tool call or expose a secret. The agent safety execution gates guide covers the control model in more depth.

Threat model

Surfaces to test, the question each answers, and the evidence to record

Surface	Question	Evidence
Untrusted target content	Can page text or an API response change the agent's plan or proposed action?	Proposed and executed actions, policy decision, and a clean control response.
Tool metadata	Can a tool description grant authority, hide a side effect or redirect a call?	Tool definition version, server decision, and the expected tool contract.
Credential exposure	Can a secret appear in context, logs, artifacts or an error message?	Canary search results across each store and the redaction rule.
Sandbox boundary	Can the agent read host files, reach another container or escape its workdir?	Filesystem and network inventory before and after the attempt.
Egress	Can the agent send data to an unapproved destination?	Egress logs, the deny rule, and a permitted destination control.
Persistence	Can the agent create a lasting credential, scheduled job or file?	Before-and-after inventory and the cleanup record.
Stop control	Does the kill switch work from outside the agent's control?	Time to stop and a confirmed denial after the switch.

Design a safe test

Use a disposable target and synthetic secrets. Plant a canary value so you can tell whether it reached context or a log. Keep the agent on an isolated network with an explicit egress deny rule and a small set of permitted destinations. Hold the stop control outside the agent. Set a request budget and a test window with the owner. Enable logging before the first case, because a missing log turns the result inconclusive.

Record the difference between a plan and an effect

A prompt injection that changes the agent's stated plan is not the same as one that changes an executed action. A tool call that is denied is not the same as one that reaches data. Record the proposed action, the policy or approval decision, the executed action, and the observed effect as separate fields. This is the same evidence discipline described in the reproducibility protocol.

How this differs from testing a customer AI application

Testing a customer AI application asks whether its prompts, retrieval, tools and permissions are safe for users. Testing the pentest agent asks whether the offensive toolchain can be turned against its operator, the target boundary or another environment. The two assessments can share test cases, but they have different assets, owners and stop conditions. The MCP security guide covers tool and server boundaries for deployed AI systems.

What to publish and what to keep private

Publish the method, the control model and sanitized evidence. Do not publish working payloads, live credentials, customer data or target details. Keep the canary, traces and configuration references in the agreed evidence channel. The goal is a durable control improvement, not a demonstration that a model can be persuaded to say something unusual.

FailSafe tests these boundaries under agreed scope, with isolation and evidence handling described on the SWARM platform page. Engagements that require local execution and evidence retention can use sovereign hosting and local inference.