MCP for Pentesting: Let AI Agents Run the Full Pentest Lifecycle

Your engineers already ask an AI assistant to open pull requests, read logs and triage tickets. This post explains how the same assistant can run a RedPick pentest from authorization to retest, and why that is a different thing from an agent that can only read a report.

Direct answer: RedPick's MCP server lets any MCP-compatible AI assistant or coding agent drive the full lifecycle of a real pentest: check that a target is authorized (by DNS record or verification file), launch now or on a schedule, monitor the run live, pause or stop it, read verified vulnerabilities and attack chains, and request retests and reports. Permissions are split by area, so reading, launching and stopping are granted separately, and every MCP-initiated launch is recorded in the audit trail. It runs on the same engine as the RedPick dashboard and is available in early access.

The short version. Many MCP servers in security let an agent read a report or start a scan. RedPick lets it operate an engagement: authorize, launch, watch, stop, read exploit-verified findings and close the loop with a retest. The agent sees what you can see, does only what you allowed, and leaves an audit record every time it starts something. If you want to try it, contact us for early access.

---

Why put pentesting behind MCP at all?

The Model Context Protocol is an open standard for connecting AI applications to external tools and data. In a short time it became the default way assistants talk to developer tools: issue trackers, cloud consoles, databases, observability stacks. Most AI assistants, chat workspaces, coding agents and IDEs that engineering teams use now speak it.

Security testing has mostly stayed outside that loop. A typical engagement still looks like this: someone fills in a scoping form, waits, receives a PDF, copies findings into a ticket system, and asks for a retest weeks later. Every handoff is a place where context gets lost and fixes stall.

RedPick already runs headless and can be triggered from CI/CD through an API. MCP adds a different kind of interface. An API is for code that you write in advance. MCP is for an agent that decides, in the middle of a conversation, that the next useful step is "check whether the retest on that IDOR finished" or "summarize the open high-severity findings for the payments app".

That changes who can use pentest results and when:

• A developer fixing a finding can ask their coding assistant for the exact reproduction steps, apply the fix, and request a retest without leaving the editor.
• An AppSec lead can ask for the status of every running engagement and a short summary of what is blocking release.
• A platform team can let an internal agent schedule recurring assessments for approved targets and report back in chat.

Reading results is not running a pentest

As MCP spread, many security platforms added an MCP server. Most of them do one of two things. Some are read-only: an agent can query findings or reports that already exist. Others are scan launchers: an agent can start a job and get back a list of issues when it finishes. Both are useful. Neither lets an agent own the engagement.

A real pentest has a lifecycle, and the valuable parts sit at the edges. Before anything runs, someone has to prove the target is theirs to test. While it runs, someone has to be able to see progress and stop it. After it runs, someone has to know which findings are real, how they chain together, and whether the fix actually worked. If an agent can only touch the middle of that lifecycle, a human still has to do the rest by hand.

RedPick's MCP server is built around the whole loop:

Stage	What the agent can do
Authorize	Check whether a target is approved and, if not, get the DNS record or verification file instructions
Launch	Start a pentest now or schedule it, from a saved setup or a new one
Monitor	Follow status and session output live, with a sanitized health view
Control	Pause, resume or stop a run it is allowed to control
Results	Read exploit-verified findings, attack chains and access matrices
Close the loop	Request retests of specific issues and generate reports

This is not a separate "AI edition" of the product. The MCP server exposes the same customer surface as the RedPick dashboard and calls the same engine. Whatever a pentest launched by an agent finds goes through the same testing, verification and reporting as one launched by a person. RedPick is not a model wrapper with a chat box on top; MCP is simply one more way in to the platform that does the work.

The lifecycle, step by step

Authorize the target

An agent can list your approved targets and saved pentest setups and check whether a target is authorized. This is the same preflight the dashboard launch wizard runs. If the target is not approved yet, the agent gets back the ownership-proof instructions, either a DNS record for the domain or a verification file on the exact host, instead of a running test. A launch also requires an explicit acknowledgement that testing is authorized.

That means a prompt like "start a full pentest on the staging API we approved last week" works, while "go test this random domain I found" stops at the authorization check.

Launch now or schedule

Once the target is authorized, the agent can start the pentest immediately or schedule it. Retries are safe: if a client repeats a launch request, RedPick does not start a duplicate run.

Monitor live

Pentests take time. An agent can follow the status of an engagement, read session output, and get a sanitized health view that explains whether the run is progressing, waiting on something intentional, or needs an operator. These reads are informational: watching a run never changes how it executes.

Pause or stop

If something changes, such as a release freeze or a target that turns out to be fragile, the agent can pause, resume or stop a run, exactly as the user could from the dashboard. Stopping is a separate permission from launching, so you can give an agent the right to halt tests without the right to start them.

Read verified vulnerabilities and attack chains

When findings arrive, an agent can pull a summary per engagement or open a single finding with its description, impact, evidence, reproduction steps and remediation guidance. It can also read attack chains and access matrices, which matter when a vulnerability only makes sense in combination with another one. Every finding RedPick reports is confirmed with a working proof-of-concept: no exploit, no finding. Our AI pentesting buyer's checklist explains why that is the bar to ask for.

Retest and report

This is where MCP helps the most. An agent can request a retest of specific issues once a fix is deployed. Retests reproduce the original attack against the fixed endpoint. If an endpoint moved during the fix, the retest can be pointed at the new location for that issue, and anything that cannot be verified is reported as not verified rather than quietly marked as fixed. The agent can also list report templates, generate a report and fetch a download link, so "send me the executive summary for last month's assessment" becomes a single request.

Teams that run infrastructure vulnerability assessments can bring those results into RedPick and follow them from the same agent as well.

Least privilege by design

The most important design decision is also the simplest: the agent acts as you, and only as much as you allow.

Every MCP call is made on behalf of the signed-in user and is checked against that user's role, company and targets. A viewer cannot launch pentests through MCP. A user who sees one business unit's engagements cannot read another's. When you revoke someone's access in RedPick, their agent loses it too.

On top of that, permissions are split by area. Reading results, launching a pentest and stopping one are separate grants, and the same separation applies to reports, retests, targets and account settings. In hosted mode, the consent screen shows which permissions the assistant is asking for before the user approves them. An agent that only needs to summarize findings for a weekly update never needs the right to launch anything.

There are two ways to connect, with the same rules:

• Local mode. The MCP server runs on your machine, next to your MCP client, and authenticates with a personal token from your account that you can revoke at any time. Some workstation-specific capabilities, such as preparing desktop or mobile application runs, are only available locally because they need files and runtimes on that machine.
• Hosted mode. An administrator adds RedPick once as a connector in the company's AI workspace. The first time a user asks their assistant to do something with RedPick, the client opens the RedPick login and consent screen. After sign-in, the connector receives a short-lived authorization tied to that user. No shared service account is involved, and nothing needs to be installed on laptops.

This matters because agentic tools blur the line between "the user asked" and "the model decided". If the model can only do what the user could have done by clicking, and only in the areas the user granted, the blast radius of a confused or manipulated agent stays bounded by permissions you already manage.

Guardrails and the audit trail

Giving an AI agent access to an offensive security platform deserves caution. Prompt injection is real, and we cover it at length in our LLM security testing guide. An agent reading attacker-controlled content can be pushed to do things nobody asked for. So the MCP server follows a few rules.

An explicit tool allowlist. The server exposes a fixed, reviewed set of tools. There is no generic "call any endpoint" tool and no shell access. If a capability is not on the list, the agent cannot reach it, however the prompt is phrased.

Risky actions are excluded on purpose. Some things stay out of MCP entirely: changing execution and delivery limits, overriding safety gates, forcing recovery of a run, publishing partial results, and every internal or cross-customer operation. These remain decisions for people. Each exclusion is documented and tested, so a future change cannot silently expose one.

Authorization before action. Launching requires an authorized target and an explicit acknowledgement. Higher-impact active checks need a separate confirmation on top of the request itself.

Everything is on the record. Every pentest launched or scheduled through MCP is written to the audit trail as an MCP-initiated action, tied to the real user who made it. Engagements, retests and reports created this way live in the same dashboard and history as everything else. There is no separate "agent mode" with its own, harder-to-review history.

None of these rules makes an agent safe by itself. They make sure that when an agent misbehaves, the consequences stay small and visible.

Why MCP itself needs testing

MCP is also a new attack surface, and the public record shows it. In October 2026, one source-review campaign published by VulnCheck produced at least 27 MCP and agent CVEs in six days, with no patched version listed in any of the advisories, and a critical Langflow flaw let an MCP server configuration run arbitrary commands on the host. If your product exposes an MCP server or lets an assistant call one, it belongs in scope. RedPick's AI and LLM testing covers it: discovering MCP servers, checking tool descriptions for hidden instructions, finding endpoints that answer without authentication, and testing isolation between servers. The guardrails described above are how we handle the same risks on our own side.

A realistic workflow

Here is how a team might use it on an ordinary Tuesday.

1. On Monday evening, a scheduled RedPick pentest finishes on the customer portal. Two findings are verified: a broken object-level authorization issue on an invoices endpoint and a stored XSS in a profile field.
2. On Tuesday morning, a developer asks the coding assistant in their editor: "What did RedPick find on the customer portal yesterday?" The assistant reads the findings and returns both issues with their evidence.
3. The developer asks for the reproduction steps for the authorization issue. The assistant reads the finding, points at the affected handler, and helps write a fix and a regression test.
4. After the fix is deployed to staging, the developer asks: "Request a RedPick retest for the invoices finding." The assistant files the retest for that specific issue.
5. Meanwhile, the platform team's agent, connected by a team member with launch and stop permissions, starts the weekly pentest of a new service on an approved target. The launch is recorded in the audit trail as MCP-initiated, under that team member. When a release freeze is announced, the agent pauses the run and resumes it afterwards.
6. In the afternoon, the AppSec lead asks a chat assistant: "Which high-severity findings are still open across our apps?" It answers with the remaining XSS and the retest status of the first issue.

Nobody exported a PDF, copied text into a ticket, or waited for a weekly sync. Everyone stayed within their own permissions, and every launch is on the record.

How this fits with your other tools

MCP is one interface among several. The dashboard remains the place for scoping, approvals and review. The API and CI/CD integration remain the right choice for fully automated pipelines, where no conversation is involved. MCP sits in between, for work that is driven by people and carried out by their assistants.

Testers who work in Burp Suite can use RedPick's extension alongside the MCP server, so an agent sees the same engagement context a tester sees. We'll cover the extension in a dedicated post.

What to ask before connecting any security platform to an agent

These are the questions we would ask of any security platform that offers an MCP server:

• Does it cover the lifecycle or just a slice? Reading a report and running an engagement are different capabilities.
• Whose identity does the agent use? Prefer per-user delegation over a shared service account.
• Are permissions split by area? Reading, launching and stopping should be separate grants.
• What is deliberately excluded? A platform that cannot name the actions it kept out of MCP has probably not thought about it.
• Are high-impact actions confirmed? Look for explicit confirmation steps, not just a warning in the tool description.
• Where is the audit trail? Actions taken by agents should appear in the same history as human ones, marked as agent-initiated.
• Are the findings verified? An agent acting on unverified results spreads noise faster.

The OWASP Top 10 for LLM Applications is a good companion here, especially the entries on excessive agency and prompt injection. An MCP server is exactly the kind of tool those entries are about.

Getting early access

The RedPick MCP server is in early access and works with MCP-compatible clients in local or hosted mode. During early access we enable it per workspace and help you connect your first client, choose between local and hosted mode, and decide which permissions each team member and agent should have.

---

Related: Platform · AI Pentesting Buyer's Checklist · LLM security testing guide