PentestGPT vs Penligent: Current Workflows and Verified Findings

PentestGPT vs Penligent should not begin with the assumption that one writes commands while the other executes them. The current PentestGPT project has agentic workflows, so a comparison built around that old distinction can mislead readers before it reaches the first feature table. The more useful questions concern the version and mode being evaluated, the evidence it produces, and the work required to turn a run into an accepted finding.

PentestGPT refers specifically to the GreyDGL/PentestGPT project in this comparison. It is published by Penligent, draws on official sources checked on October 17, 2026, and reports no head-to-head benchmark.

Separate the original research from the current project

Die original USENIX Security 2024 paper studied a modular LLM-assisted penetration testing system. Its results belong to the evaluated configuration and tasks. They should not be treated as performance measurements for every later release or for a comparison with Penligent.

Die current PentestGPT repository now documents an agentic upgrade with CTF and pentest pipelines, saved sessions, and a separate legacy interactive mode. Selecting a mode is therefore part of defining the test. Claims about an older interactive workflow do not describe all current execution paths.

For Penligent, use Penligent’s current product and plan descriptions to identify the assessment workflow and the applicable plan. Verification and reporting are relevant documented capabilities; their quality on your target still needs an evaluation. A product description cannot replace an independent review of a finding.

An autonomous attempt is not yet an accepted finding

A system may execute tools successfully and still draw the wrong conclusion. A server error might be ordinary failure, an authorization response might be misread, or a test might run under the wrong account. The evidence must distinguish those explanations before an engineering team is asked to fix a vulnerability.

Use a staging application with synthetic data and a clear tenant-access policy. Give each workflow the same two roles and permitted actions. For a reported boundary violation, require the account context, object ownership, request, relevant response, expected restriction, and observed impact. A screenshot can support that record, but it should not be the sole basis for a technical claim.

Add a negative control: a similar action that is correctly restricted. Ask the reviewer to assess both cases without knowing which tool produced the report. This reduces the chance that a polished explanation or brand preference substitutes for technical judgment. Keep uncertain cases open as hypotheses rather than forcing every output into “true” or “false.”

A CTF success and a business application test answer different questions

A challenge may provide a recognizable completion signal and a narrow target. A business application may instead require a judgment about roles, ownership, state, and permitted behavior. If a trial uses CTF tasks, report that result as CTF performance. Do not silently translate it into assurance about authenticated application coverage.

For an assessment workflow, include a case that depends on a business rule you supply in advance. For example, one workspace must not access another workspace’s synthetic export. Record exactly how that rule is given to the tool. If the evaluator later supplies the vulnerable endpoint or the missing hypothesis, capture that assistance rather than presenting the outcome as an unaided discovery.

A useful comparison can value both independent exploration and efficient collaboration. The scoring should reflect the team’s objective. A researcher studying reasoning behavior may prefer detailed intervention opportunities; a release team may care more about a predictable result within a fixed window. State that objective before deciding which behavior counts as better.

Version, model, and environment belong in the result

Keep a small run record alongside every report. Include the code revision or product configuration, selected workflow, model identifier, target build, account roles, execution window, and human interventions. Preserve the setup for unsuccessful runs too. Otherwise a later improvement or regression is difficult to attribute.

When changing a model or execution mode, treat the new configuration as a new evaluation condition. Do not combine the best results from several attempts and describe them as one run. Likewise, compare equivalent resource budgets or disclose the difference. Extra time and operator guidance may be entirely reasonable, but they should remain visible.

If an environment failure prevents a test, mark the affected area inconclusive. “No finding” is not the same as “tested successfully.” This distinction is especially important when authentication fails or a target changes during the run. A final report should describe what was reached and what was left unresolved.

Test the engineer’s experience after the run

Ask an engineer who did not participate in the assessment to reproduce one accepted issue. Measure the time spent locating the affected component, rebuilding the account context, and confirming the impact. Record any report edits needed before the issue can enter the remediation queue.

Then repair the seeded flaw and repeat the relevant test under comparable conditions. The retest must reach the same feature with a valid session. If it fails earlier, record an incomplete retest instead of declaring the issue fixed. Keep the original proof and the retest result associated with the same finding so the closure decision is auditable.

This handoff exercise tests a property that raw vulnerability counts miss. A tool can generate many plausible leads while creating a large verification burden. Another can produce fewer items that are immediately reproducible. Report accepted findings, rejected claims, missed seeded cases, and review effort separately so a team can see the tradeoff.

The README and Docker status document need to be read together

There is a concrete documentation mismatch to resolve before using PentestGPT in a deployment comparison. The repository README presents a Docker execution path. Its Docker runtime status document, dated July 12, 2026, says the maintained nested agent project is not baked into the tool image and that the corresponding run path fails fast pending framework-image wiring. These statements should not be silently combined into a guaranteed working quick start.

The appropriate conclusion is limited: verify the intended entry point against the exact checked-out revision. This is not evidence that every PentestGPT workflow is unusable. It is evidence that “the repository supports Docker” is too broad to answer which maintained workflow a particular image actually runs. A buyer or researcher should resolve that question before interpreting a failed assessment.

Use a clean environment and a harmless readiness check before providing a target. Confirm that the selected CLI exists, its help output matches the intended mode, and its dependencies correspond to the maintained package. Keep the observed revision and startup result with the run record. If the deployment requires custom wiring, document that work rather than presenting it as an out-of-the-box product behavior.

Apply the same discipline to Penligent’s proposed configuration: ask for a demonstration of the supported deployment and enabled workflow. A product page and a repository README are different kinds of evidence, but neither should receive credit for a configuration that was not actually demonstrated. This keeps the comparison focused on deployable behavior rather than documentation style.

Legacy task-tree interaction and staged autonomy solve different problems

The repository preserves an interactive legacy workflow alongside its newer agentic direction. Treat the mode as a first-class part of the evaluation. An interactive session can be useful when the operator wants to inspect hypotheses and guide the next step; a staged autonomous run can be useful when the desired work is defined before launch. Combining their advantages into one unqualified feature list misrepresents what any single run establishes.

For an interactive trial, record where the human supplies judgment. A suggestion to investigate authentication is different from a precise instruction revealing the flaw. The operator may be the source of the most important inference, and that can still make the workflow useful. It simply means the result demonstrates collaborative effectiveness rather than independent discovery.

For a staged trial, inspect the information passed between phases. A discovery phase may identify a route without establishing its role requirements; a later phase may treat that route as a confirmed exposure. Ask the reviewer to trace the conclusion back through the preserved observations. A staged architecture is most useful when those transitions keep uncertainty visible.

Define phase completion separately from assessment completion. Finishing a report-generation phase does not establish that every intended role or feature was reached. The final deliverable should carry forward blocked prerequisites and untested areas. This is an acceptance requirement for either candidate, not a claim that a particular implementation currently loses that information.

Container isolation depends on the deployment, not the label

The PentestGPT Docker status document places significant responsibility on the execution boundary: it describes broad provider permissions and calls for constrained mounts, routes, and run state. It also identifies persistent authentication volumes as sensitive. Those details matter more than an unqualified assertion that a container makes an assessment safe.

Create a dedicated environment containing only the authorized target routes and the minimal files needed for the assessment. Keep unrelated source, personal home directories, host sockets, and production credentials outside it. The purpose is to make a mistaken action encounter an enforceable boundary instead of relying entirely on natural-language instructions.

Review persistence separately from isolation. Keeping login state can reduce repeated setup, but it also means a recreated container may still have access through a retained volume. Document which state survives shutdown, who can read it, and how it is revoked. Removing a container should not be assumed to remove every credential or assessment artifact.

For a managed or enterprise proposal, request the equivalent execution-boundary description. Ask about accessible networks, credentials, stored state, and the handling of completed runs. A different hosting model changes which team implements these controls; it does not make the questions irrelevant. Evaluate the actual environment rather than awarding isolation points for a deployment label.

Use a minimal evidence manifest to keep results reviewable

A finding can become difficult to reproduce when its prerequisites are spread across several sessions and tool outputs. Maintain a compact manifest that points to the evidence and states the conditions. This is especially useful when comparing a repository workflow with a product workflow because it gives the independent reviewer a consistent starting point.

The JSON below is an illustrative evaluation record. It is not a PentestGPT or Penligent API schema, and it is not fabricated test output. Its null fields deliberately remain unmeasured until a real pilot supplies the evidence.

{
  "record_type": "illustrative_finding_review",
  "target_build": null,
  "workflow_revision": null,
  "mode": null,
  "account_role": "dedicated_test_role",
  "hypothesis": "Cross-tenant access violates the supplied policy",
  "observed_result": null,
  "evidence_artifacts": [],
  "independent_reproduction": "not_performed",
  "coverage_gaps": [],
  "retest": {
    "build": null,
    "same_feature_reached": null,
    "result": "not_performed"
  }
}

Keep the manifest small enough to review, and store detailed artifacts separately under controlled access. Use stable identifiers rather than embedding session cookies or large response bodies. If the workflow produces a richer native record, map it into the review process without discarding useful provenance. The objective is a common acceptance standard, not a forced replacement for either product’s output.

A failure taxonomy makes the comparison actionable

A failed run can indicate an unavailable runtime, rejected model access, missing target reachability, expired authentication, an incorrect hypothesis, or an unsupported conclusion. Those failures lead to different fixes. A single “did not find the issue” score cannot tell the team whether to repair deployment, improve context, or choose another workflow.

Classify the first blocking condition and retain the supporting evidence. If the selected CLI is absent, the run has not evaluated detection. If authentication fails, protected coverage is incomplete. If the tool reaches the feature but misreads the response, the review should address interpretation. This separation prevents deployment friction from being mistaken for a measured security capability.

Also record successful execution that produces no supported finding. That can be a correct result on a clean control, a missed seeded issue, or insufficient exploration on an unseeded target. The surrounding ground truth determines which interpretation is justified. Do not turn every empty report into a success or every unexpected silence into a confirmed miss.

Migration should preserve the finding history

If a team moves between PentestGPT workflows or from a local experiment into a procured service, preserve the evidence that supports existing findings. Exported prose alone may omit the target state, account role, and operator context. Carry those prerequisites forward so the next reviewer does not need to repeat the original investigation merely to understand it.

Use one synthetic project to rehearse migration. Move the accepted finding record and its artifacts through the supported export or manual handoff, then have a new reviewer reproduce the case. Document any information that must be added. A successful migration preserves the technical claim and its provenance, not just a title and severity label.

Repeat this exercise after a workflow upgrade if the output structure changes. Keep earlier assessments associated with their original configuration. Reprocessing an old transcript with a new model may produce a different explanation; label that as new analysis rather than rewriting the history of what the earlier run observed.

The choice between PentestGPT and Penligent becomes clearer when these responsibilities are visible. A team may reasonably accept integration work to gain implementation access, or prefer an offered workflow that meets its delivery process. In either case, require a deployable configuration, traceable evidence, and a closure decision that survives a change of operator.

Compare coverage at the feature level

Route counts do not establish that a workflow exercised the meaningful states of an application. A single export route may behave differently for an owner, a guest, and an administrator. A browser may reach every visible page while never making the request that tests the supplied business rule. Record feature, role, and relevant state alongside the reached surface.

For a small pilot, define a matrix before the run with a few important combinations. Mark each as reached, tested with evidence, blocked by a prerequisite, or outside scope. This is a proposed reviewer artifact rather than a native output format promised by either tool. Its purpose is to prevent activity volume from obscuring missing assessment work.

Use the matrix during retesting as well. A fixed issue should be checked in its original role and state, while at least one permitted action remains functional. If a new build removes the feature entirely, record that change rather than presenting the absent route as proof that the underlying authorization logic was repaired.

This gives the engagement owner a more useful statement than a broad percentage without a denominator. It also makes a missed case actionable: repair access, add business context, broaden the test, or accept a documented limitation. Those decisions remain visible after the original operator has moved on.

When each approach makes sense

PentestGPT is worth evaluating when you want to work with its current repository workflows, investigate agent behavior, or build an experiment around a specific configuration. Use the current project instructions and inspect the selected mode; do not rely on an old review to define what it can do.

Evaluate Penligent when you are selecting an assessment workflow and need its proposed verification, reporting, integration, or deployment arrangements to fit an organization’s process. Demonstrate the necessary features in the appropriate plan rather than assuming they are universal.

The deciding evidence should be a scoped run that another person can review: what was tested, what was proven, what remained uncertain, and whether a repaired issue was genuinely retested. That is a stronger basis for choosing between PentestGPT and Penligent than preserving an outdated distinction between conversation and execution.