Pensar Apex: an agent-driven pentest CLI you run from the terminal

The problem Apex targets: pentests that do not fit a sprint

A conventional penetration test is a scheduled engagement. A tester enumerates the target, reasons about the attack surface, tries a chain, writes it up, and the report lands weeks later. By then the pull request that introduced the weakness has shipped and been built on.

Apex aims at the gap between that cadence and the merge cadence. The README frames the developer use case first: run /pentest before merging a PR, the way you would run a test suite, and get findings with severity scores, evidence, and suggested fixes. The second audience is security engineers, who the README says can deploy agent-driven swarm testing across large attack surfaces and use /operator mode for manual investigation, exploit chaining, and validation.

That split matters for evaluation. If you are a developer who wants a second opinion on a diff, the relevant question is whether the agent can be pointed at a local checkout and produce something readable. If you are a security engineer, the relevant question is whether the agent's memory and tooling survive across engagements. The README claims persistent memory that accumulates across engagements, but does not describe its storage format or retention behaviour beyond that sentence.

How the agent actually runs: CLI, TUI, and a headless path

The package exposes a single binary named pensar, declared in package.json as ./bin/pensar.js. Running pensar with no arguments opens the TUI. Running pensar pentest or pensar targeted-pentest runs headless, which is the path the README points at for scripting, CI, and evalgate integration.

The CLI surface is small and flag-driven. --target is required for both pentest commands. --cwd switches pentest into whitebox mode by handing the agent a source path alongside the URL. --mode exfil is described as enabling pivoting and flag extraction. --extended-thinking and --task-driven change how the agent plans; the README labels task-driven as experimental. --prompt and --threat-model both accept either literal text or an @file reference, which is how you feed a longer brief without quoting it on the command line.

Under the surface, the dependency list shows the shape of the thing. The agent layer is the Vercel AI SDK (ai, @ai-sdk/anthropic, @ai-sdk/openai, @ai-sdk/google, @ai-sdk/amazon-bedrock, @ai-sdk/openai-compatible, @openrouter/ai-sdk-provider), so model choice is a provider concern rather than something Apex implements. Browser-driven testing comes through @playwright/mcp and camoufox-js. Tool integration with external systems goes through @modelcontextprotocol/sdk. The TUI is built on @opentui/core and @opentui/react with React 19. Remote execution uses @daytonaio/sdk. There is also a @pensar/surface dependency, which the README does not explain.

Installing Pensar Apex and running a first pentest

The README lists four install paths. On macOS and Linux there is a curl-to-bash installer, on Windows a PowerShell equivalent, plus Homebrew and npm. The npm package name is @pensar/apex, and the binary it installs is pensar, so the package name and the command you type differ.

npm install -g @pensar/apex

After that, running pensar with no arguments opens the TUI. To run a headless pentest against a target you control, pass --target:

pensar pentest --target https://example.com

The README does not document where model credentials are read from for this command, so check the docs site before assuming it works out of the box. If you want the agent to see your source as well as the running service, add --cwd with the project path:

pensar pentest --target https://example.com --cwd ./my-app

For a narrower run, targeted-pentest takes repeatable --objective values instead of a whole-surface sweep:

pensar targeted-pentest --target https://example.com --objective "Test authentication bypass"

Diagnostics are worth knowing about before you debug anything. Apex writes one-line JSON to stderr when stdout is not a TTY, and pretty colourised output in an interactive terminal, with user-facing output staying on stdout. The level resolves in the order CLI flag, then PENSAR_LOG_LEVEL, then PENSAR_DEBUG, then the default of info:

pensar pentest --target https://example.com --log-level debug
PENSAR_LOG_LEVEL=debug pensar pentest --target https://example.com

The README also documents an optional Kali container, which it calls the best-performance option because the pentest tools are preconfigured:

cd container
cp env.example .env
docker compose up --build -d
docker compose exec kali-apex bash

Inside that shell you run pensar as usual. Copying env.example to .env is where your API keys go, per the README comment.

Observability is opt-in, and that is a deliberate constraint

Two tracing paths exist and they behave differently. W&B Weave streaming is enabled by environment variable: set WANDB_API_KEY and WANDB_ENTITY, and traces go out with WANDB_PROJECT defaulting to apex-traces. The README says those traces include reasoning steps, tool calls, token usage, and state checkpoints, and that tracing is silently disabled when credentials are not set. Silent disabling is convenient and also means a misconfigured key produces no error, just no traces.

The OpenTelemetry path is the more interesting design decision. Apex emits spans for agent runs, LLM calls, and tool executions through @opentelemetry/api, but ships no SDK. Unless your process registers an OpenTelemetry SDK as the global tracer provider, the spans are no-ops. That is a library-style choice imposed on an application: you get the instrumentation only if you wire it yourself, and the README tells you to register the SDK before importing Apex code. For Sentry it names @sentry/node at 9.27 or later plus Sentry.vercelAIIntegration(); for anything else it points at @opentelemetry/sdk-node with an OTLP exporter.

Payload capture is off by default. Only span shape (model, token counts, latency, tool names) is recorded unless you set AI_TRACE_RECORD_PAYLOADS=true, which also records prompts, tool I/O, and outputs. For a pentest agent, those payloads can contain live credentials and exploit detail, so the default is the right one and the opt-in is the flag to think hardest about before enabling in a shared backend.

Where Apex is the wrong tool, and what to use instead

The release channel is the first limitation. Every release listed is a v2.5.0-canary tag, the most recent being v2.5.0-canary.c10401c9, and the default branch is canary. The README's own badges distinguish a latest npm version from a prerelease version, which implies a stable line exists, but nothing in the repository describes what is in it or how it differs. If your process requires pinned, stable versions, treat this as a canary-only project until you confirm otherwise.

The second limitation is more fundamental. An autonomous agent exploring a web target is a nondeterministic process. The README offers --task-driven as an experimental mode and --extended-thinking for supported models, which suggests the project is still tuning how much planning happens before action. The README does not describe coverage guarantees, false-positive rates, or how findings are deduplicated across runs. A pentest report you cannot reproduce is hard to defend in a compliance review.

The concrete alternative is a scripted scanner such as OWASP ZAP or a Nuclei template run. The difference in approach is not quality, it is determinism: a template run executes a fixed list of checks and produces the same result against the same target, which makes it auditable and cheap to re-run in CI. Apex instead spends model tokens reasoning about what to try next, which is what lets it chain findings and read source in whitebox mode, and also what makes each run different. If your requirement is a repeatable gate, the template runner is the better fit. If your requirement is exploratory depth on a target you own, that is the case Apex is built for.

Licence, upgrade cost, and the canary branch

Apex is Apache-2.0, and the repository ships a LICENSE file plus a separate RESPONSIBLE_USE.md, which is worth reading before pointing the tool at anything. Apache-2.0 permits commercial use and modification and includes a patent grant. It also means the project carries no warranty, which for a tool that actively probes systems is the clause that matters. Nothing here is legal advice; if you are embedding Apex in a product, have counsel read the licence and RESPONSIBLE_USE.md together.

Upgrade cost is shaped by the canary channel. Three canary builds landed within four days in September 2026, and the most recent push to the repository was on 2026-09-14. That rate means the CLI surface can move between builds. The flags documented in the README are the ones to pin your scripts to, and the @file form of --prompt and --threat-model is the safer integration point than a long inline string, because a file survives a flag rename better than a shell one-liner does. The dependency list is broad (multiple AI SDK providers, Playwright MCP, OpenTelemetry packages, Daytona, mail libraries), so expect transitive churn on upgrade rather than a quiet patch. The repository also carries a bun.lock and bunfig.toml while declaring npm as an install path, so the lockfile and the published package are not necessarily the same resolution.

Editorial conclusion

Adopt Pensar Apex if you already run pentests against your own systems and want an agent that produces severity-scored findings without a security background, especially if you can run it inside the bundled Kali container for the preconfigured tooling. Do not adopt it if you need a stable release channel: the published tags are all v2.5.0-canary builds, and the default branch is canary. Before you point it at anything, verify three things: that --target and --cwd are scoped to assets you are authorised to test, that your model provider credentials are set for the model the CLI auto-selects, and whether AI_TRACE_RECORD_PAYLOADS should stay unset so prompts and tool output are not recorded in traces.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. pensarai/apex on GitHub
3. Project website
4. README
5. Releases