Open-source agents.
Different approaches.

Choosing an agentic security tool means choosing a workflow: what the agent can see, which tools it can use, how its work is constrained, and what evidence reaches your team.

Open-source projects make those choices easier to inspect. But a feature list does not tell you whether a finding will reproduce in your application, or whether your team can turn it into a fix.

Comparison at a glance

Sources: the official Strix, PentAGI and PentestGPT repositories. Open-source software licensing does not eliminate model-provider or infrastructure costs.

Strix: an application-focused workflow

Strix documents agents that coordinate security investigation and validate issues with proofs of concept. Its open-source workflow runs locally with Docker and a configured model provider. The repository describes code targets, black-box web testing, API contracts and combined source-plus-application assessments. It also documents findings with remediation guidance. Read the official Strix overview.

Evaluation lens: inspect the path from target configuration to a reproducible finding. If your workflow combines source visibility with a deployed application, check how the assessment uses both. Evaluate the open-source CLI separately from hosted-platform features rather than assuming they are interchangeable.

PentAGI: an operational agent platform

PentAGI documents a self-hosted system with specialist agents, Docker-based execution, a web interface, persistent command and output storage, and reporting. Its setup supports multiple model providers, with optional observability and knowledge-graph integrations. The project also distinguishes its current penetration-testing workflow from predefined adversary-emulation campaigns. Read the official PentAGI features and boundaries.

Evaluation lens: assess the operating model alongside the agent. Who will maintain the deployment, inspect runs and manage stored assessment data? A richer platform can be useful when those responsibilities fit your team; its value should be judged against the workflow you actually need.

PentestGPT: staged and interactive paths

PentestGPT’s current repository describes an autonomous multi-stage pipeline with Claude Code and Codex backends, session persistence, and distinct CTF and penetration-test modes. It also retains a modernized interactive legacy mode with reasoning, generation and parsing sessions and broader provider support. These modes are different workflows, so the older assisted experience should not stand in for the current autonomous pipeline. Read the official PentestGPT agentic upgrade.

Evaluation lens: choose the mode before comparing results. Check whether the stage transitions, context and outputs suit a lab exercise or your intended application assessment. Keep historical research results separate from expectations about a current release in your environment.

Evaluate the workflow, not the headline

A useful comparison gives each candidate the same opportunity to solve the same problem. Define a small assessment in a system you own or are authorized to test, and write down what success would look like before starting.

1. Match scope and access. Keep targets, accounts and source-code visibility consistent. White-box and black-box runs answer different questions.
2. Record the configuration. Note the project revision, model, instructions, time limit and spending budget. Otherwise you may be comparing configurations rather than tools.
3. Inspect the harness. Review the available actions and constraints. Consider how scope is enforced and how you can intervene when the investigation takes an unhelpful direction.
4. Check evidence. Can another person reproduce the reported issue? Count confirmed findings separately from unverified observations and duplicates.
5. Judge remediation quality. Does the output give engineering enough context to understand and address the problem?
6. Count operating effort. Include setup, model usage, supervision, cleanup and review—not only run time.

Repeat the evaluation when an important configuration changes. A successful demonstration is useful evidence, but it does not establish reliable coverage across every application you run.

The choice depends on your team

Open-source agents are valuable building blocks. Some teams want direct control over the runtime and methodology; others want help turning that machinery into a scoped assessment and useful engineering output. The right starting point depends on your access, operating capacity and evidence requirements.

The question to carry into a trial is simple: can this workflow produce findings your team can reproduce, understand and act on?