PentestGPT

The framework launches both LLM roles through the provider CLI in full-access mode, so the agent acts with the operator's whole OS identity and the provider login the CLI already holds. No credential is scoped, narrowed or withheld from the shell tool, and nothing checks authority per request. The only credential handling in the repo's own code is passing a few provider environment flags. A hijacked run can use anything the operator's account can reach.

There is no approval step anywhere in the maintained framework: every command and file write the model chooses runs immediately. The provider permission mode in effect is the one that skips all permission prompts. Deterministic code only decides which planned task runs next, not whether a given action may execute, and no undo or checkpoint exists for the actions taken.

The one real scope control is a deterministic check that each planned task's target field matches an operator-supplied allowed target, plus a phrase denylist for test-type tasks. It checks the plan's metadata, not the commands or network destinations the shell tool then uses, so the model can still act against any host or path. All provider tools are enabled by default.

Model-chosen commands run in the provider CLI's shell as the operator's user, with the permission system set to skip checks. The framework adds no container, OS sandbox or filter and says plainly that isolation is the operator's job. The repository's Docker image is a separate tool image that does not contain the framework, gives its user passwordless sudo and adds a network-admin capability, so it is not a boundary for the scored mode.

Target responses and files are the agent's main input, and they flow into the model and into stored observations that later steer new tasks. The only defence is prompt text telling the roles to treat them as data. A hijacked run still has an unrestricted shell, network access and the operator's credentials with no human step, so it can both leak data and take irreversible actions.

Run state lives in a per-run SQLite file; each episode starts fresh and the maintained code turns off the Claude provider's own auto-memory. Stored observations must be exact slices of captured tool output, which gives provenance but also means target-controlled text is persisted and re-shown to later model calls. Instruction and settings files in the agent workspace are loaded by the provider CLI in the wrapper copy in the repo, which was not audited for the pinned external wrapper, so that path is treated as uncontrolled.

The framework ships no plugin, MCP or marketplace loader of its own; the third-party code that runs is the provider CLI and the pinned wrapper package. The wrapper is pinned to one commit, but the provider CLIs are installed by the operator with no version or integrity check, and the tool image installs them unpinned. The model can also install anything through its unrestricted shell, which no control in the repo limits.

The repo's code never masks, redacts or scrubs anything, and the full-access shell can read the provider login tokens that the Docker helper scripts store and export. Run traces record full prompts, commands and outputs locally, but the files are created owner-only. The README describes default-on analytics, but no telemetry code exists in the maintained packages, so that was not credited or penalized beyond a documentation mismatch.

Every provider event is written to an append-only per-episode journal with a flush to disk per event, tagged with run, role, task, attempt and revision identifiers, and a separate SQLite transition log records state changes. A bundled audit tool replays a finished run from these files. The journal sits in the operator's working directory, so a full-access agent could alter or delete it, and there is no approver record because there are no approvals.

The loop is bounded by a count of supervisor decisions (default 20, hard maximum 1000), per-episode turn limits (executor 12, supervisor 4, with per-task-kind budgets) and two attempts per task, all validated in code and unalterable by the model. There is no wall-clock limit, cost cap, rate limit or tool timeout in the framework's own code; command timeouts are only requested in the prompt. Nothing in the repo handles interruption or kills in-flight commands.