Pentest Copilot vs Broken Crystals

Can an autonomous pentester keep up with browser sessions, GraphQL, gRPC, files, and MCP? We put Pentest Copilot to the test.

Modern applications are rarely just websites anymore.

The browser is one piece. Behind it are APIs, backend services, file systems, login sessions, and increasingly, tools built for AI assistants.

Security scanners often treat each piece as a separate job. Attackers do not.

Pentest Copilot is designed to explore an application as one connected system. It signs in, learns how the product works, tests possible weaknesses, and proves which ones have a real effect.

That sounds good in a product description. But could it actually find everything in a difficult modern benchmark?

So we set up a test.

One domain. One recorded login. No source code given to the testing agent.

The target was Broken Crystals.

The Benchmark: Broken Crystals#

Broken Crystals is a deliberately vulnerable application, but it does not behave like an old-school training website.

It behaves more like a small technology company squeezed into one target.

There are normal browser workflows and authenticated sessions. There are REST and GraphQL APIs. Backend services use gRPC. Users and services can perform file operations. There is also an MCP server running over Streamable HTTP.

MCP is the standard that lets AI assistants discover and use tools. An MCP tool might search for a user, read a resource, render content, process data, or start a system process.

That last category is why MCP security matters. Giving an AI assistant a useful tool also creates a new security boundary around who can use it, what they can send to it, and what the tool is allowed to do.

Broken Crystals combines all of those boundaries in one place.

The campaign measured 60 known, in-scope security vulnerabilities and behaviors across the complete target.

The question was simple: how many could Pentest Copilot cover?

The Results#

60 out of 60.

Pentest Copilot Enterprise ran the campaign autonomously. One domain, one recorded login, no source code, no human steering the tests.

Coverage here means the behaviour was reproduced and the evidence kept. A successful status code on its own did not count. The agent had to show the consequence.

Discovery Phase#

Discovery ran first and produced the map everything else was tested against.

• Signed in with the recorded browser session and clicked through the product like a user.
• Recorded the HTTP request behind every action, and which identity it belonged to.
• Enumerated the REST surface and introspected the GraphQL schema for queries and mutations.
• Listed the gRPC service methods, which never appear as buttons in the UI.
• Catalogued file operations separately by verb: read, upload, modify, delete.
• Connected to the MCP server over Streamable HTTP and pulled its tool and resource inventory.
• Rebuilt multi-step user flows so state-dependent actions could be replayed later.

The output is one connected map, not six unrelated scan reports.

Attack Phase#

The attack phase replayed each mapped action against the identities the agent held: logged out, the recorded user, and any privilege it could reach.

Tactics used across the surfaces:

• Authorization. same request, different identity, compare the response.
• Injection. untrusted input into query, path, body, GraphQL arguments, and MCP tool parameters.
• Session handling. predictability, reuse, and whether logout actually revokes.
• Object access. direct references to files and records owned by someone else.
• Configuration exposure. endpoints and resources that answer without being asked politely.
• Dangerous capability. tools and service methods that execute, spawn, or write.

When a session expired mid-campaign, the agent replayed the recorded login, confirmed it was back as the correct user, and resumed. No operator involved.

Analyzing an Attack Path#

The vulnerability: a predictable MCP session identifier was accepted as proof of identity, granting unauthenticated access to a process-execution tool that ran as root, on a session that survived its own logout.

Here is the chain, one step at a time.

Discovery found the endpoint. The crawl surfaced an MCP server on Streamable HTTP and recorded its tool catalogue as part of the target map.

Step 1. Look at the session identifiers. Opening an MCP session returns an identifier in the Mcp-Session-Id header. Pentest Copilot opened several in a row and compared what it was handed.

The values were not random. Each one could be derived from the one before it, which meant a session the agent had never been issued could be constructed rather than guessed.

That is only a weakness if the server also trusts the identifier. The next four steps establish whether it does.

Step 2. Establish the negative control. No session, no Authorization.

The server wants session state. That is not the same as verifying identity.

Step 3. Supply a predicted session, withhold authorization. Using a value built from the pattern in step 1.

The session identifier is doing the job of authentication.

Step 4. Read the catalogue. The tool list included ordinary search and data-processing tools, and one that starts a system process.

Step 5. Prove the consequence with a canary. A unique value ties the output to this exact test.

Progress streamed back, then the final output: the canary, and uid=0(root).

Step 6. Test whether logout revokes.

Replaying step 3 with the same identifier returned 200 and the tool list again. The session outlived its own termination.

Four weaknesses, kept in the order that made each one possible:

predictable session → accepted as authentication → tool access → root execution → survives logout

A scanner would file four alerts. The order is what turns them into a route.

Conclusion#

Broken Crystals was built to be broken. Pentest Copilot found all of it: 60 out of 60.

The score is not the interesting part. One agent moved from the browser into APIs, backend services, files, and AI tools, recovered its own session when it expired, validated consequences instead of collecting alerts, and kept a four-step route to root execution intact as a single story.

Modern applications are connected systems. Security testing should be connected too.

See what Pentest Copilot can test in your environment.