Get started Star on GitHub
ROADMAPsubject to change, version numbers are examples

What exists now, what comes next, and where help is wanted.

The LLM planner is already implemented in the pre-release build, so the list starts there. Everything marked next or later is a plan, not a promise, and none of it loosens the scope file, allowlist, audit log or approval gates.

ContributeGuardrails
stars --forks --release v0.xlicense Apache-2.0

sample data Badge values are live-badge slots and the license is a stand-in until the repository is public.

NOWin the current build

Implemented in the current build.

Six pieces make up the core today. The planner sits on top of the scope engine, not beside it, so a model can propose a step but cannot approve its own scope.

example Build status shown here is a stand-in until a tagged release exists.

LLM plannerimplemented
Bring-your-own-model planning. Reads the graph, ranks candidate paths and proposes the next step. Works with a local or hosted model you configure. Every proposal passes the scope check and the approval gate before anything runs.
pwner agent run
scope + auditimplemented
Scope engine and audit log. No scope file, no run. Each action is appended to the log with the rule that allowed it.
scope.yaml
core verbsimplemented
discover, enumerate, paths, validate. Validation is read-only: it confirms a weakness exists and stops there.
pwner <verb>
autonomy levelsimplemented
Approval gates. Starts at approve-each-step. Gates are defined in the playbook, which the agent cannot edit.
--autonomy
hygienepartial
Identity hygiene checks. Stale accounts and over-broad groups, reported as weaknesses rather than recipes. Coverage is thin for now.
--checks identity
outputimplemented
Reports and playbooks. SARIF, JSON and Markdown export, plus YAML playbooks you can review in a pull request.
--format sarif
NEXTplanned, in this order

Extend it without widening it.

Next is mostly about letting other people add to pwner safely, and about making runs repeatable enough to test the planner.

  • Plugin SDK

    pwner plugin new (planned)
    Go or sandboxed WASM. A plugin declares the hosts, ports and files it touches, and the scope engine refuses the rest. See the manifest sketch.

  • Replayable runs

    pwner replay (planned)
    Re-run a recorded session against a frozen graph so a change in the planner shows up as a diff, not a hunch.

  • Graph export

    --format neo4j,mermaid
    Take the path graph into tools you already use.

  • Wider hygiene

    --checks ad (expanding)
    More identity and directory checks, each with a plain-language finding and a fix.
shippednextafter next, dashed boxes

Why the SDK comes first. Plugins are the one place new code could try to reach hosts it should not. The manifest and the scope check ship together, or neither ships.

LATERideas, no dates

Maybe, if the core holds up.

These depend on what people actually need once the plugin SDK is in their hands.

  • Multi-operator engagementsSeveral testers share one graph and one audit log, each with their own approvals.
  • Cloud network discoveryInventory of in-scope cloud ranges, read-only, same scope rules as on-prem.
  • Signed, reproducible buildsRelease artifacts you can rebuild and compare yourself.
  • Your ideaOpen an issue in the project repository once it is public, and say what you would test.
CHANGELOGnone yet

Release notes will appear here once there is a release. No versions or dates are set.

CONSTANTStrue on every release
No roadmap item ships if it makes the scope file optional.

Features are reviewed against four things that do not change: the allowlist, the signed rules of engagement reference, the append-only audit log and the approval gates. A pull request that weakens one of them will not be merged, however useful it is. pwner is for authorized testing only.

Read the rulesSee how scope is enforced
scope check firstPlugins and planner steps go through the same check as built-in verbs.
audit stays append-onlyNo export or replay feature may rewrite it.
gates live in the playbookThe model cannot lower its own approval level.
read-only validationNew checks confirm a weakness. They do not exploit it.
COMMUNITYcontributing

How to contribute.

Small, reviewed changes beat large surprises. Most first contributions are docs, error messages and exporters.

  1. Pick an issue from the list, or open one describing what you want to change.
  2. Say you are on it in a comment so two people do not build the same thing.
  3. Test in a lab. Run against your own lab range only, such as 10.0.0.0/24, never someone else's network.
  4. Open a pull request with a note on how the change interacts with scope enforcement.
  5. Respond to review. Reviewers will reply, and so should you.

Good first issues (example titles)

  • [core]Add Windows path handling to the evidence writer
  • [core]Improve error text for malformed scope files
  • [docs]Document the plugin manifest, see architecture
  • [export]Add a Mermaid export for the path graph

Placeholder list. A live feed of labeled issues replaces it when the repository is public.

  • GitHub placeholder
  • Discord soon
  • Matrix soon
  • Contributing guide soon

Links go live with the public repository. Chat rooms open at launch, with a code of conduct.