W
Wrkr

Positioning

Positioning

Know what AI tools, agents, and MCP servers are configured on your machine and in your org before they become unreviewed access.

Wrkr gives security and platform teams an evidence-ready view of org-wide AI tooling posture and keeps a deterministic local-machine hygiene path available for developers. It stays deterministic, file-based, and standalone by default.

Category Position

Wrkr is the discovery/posture layer in the See -> Prove -> Control sequence.

  • See: Wrkr inventories and scores AI tooling posture.
  • Prove: downstream proof consumers can ingest Wrkr artifacts.
  • Control: Gait is the optional runtime control counterpart.

What Wrkr Is

  • Deterministic AI tooling posture scanner.
  • Command-first evidence and regress gate source.
  • Static discovery engine for repo/config/CI posture surfaces.
  • Minimum-now public launch path through hosted org posture and evidence flows; when hosted prerequisites are unavailable, local --path and --my-setup scans remain the explicit zero-integration fallback.
  • Thin browser bootstrap at /scan/ for optional read-only org scan handoff and summary projection when teams explicitly want a secondary browser handoff.

What Wrkr Is Not

  • Runtime side-effect enforcement gateway.
  • Live network telemetry platform.
  • Dashboard-only reporting product.
  • MCP or package vulnerability scanner.
  • Browser extension, IdP grant, or GitHub App inventory product in OSS default mode.
  • Browser-resident replacement for the Go CLI scan/risk/proof pipeline.

Persona Fit

  • Security/platform team: start with wrkr init --org ... --github-api ..., then wrkr scan --config ..., wrkr evidence, wrkr verify, and optional wrkr report / wrkr mcp-list for org posture and compliance-ready handoff.
  • Evaluator: start with wrkr scan --path ./scenarios/wrkr/scan-mixed-org/repos --json when you need the shipped wedge without repo-root fixture noise; that sample is intentionally risky by design, so a low score is expected.
  • Developer: use wrkr scan --path, wrkr scan --my-setup, wrkr mcp-list, and wrkr inventory --diff when you want repo-local or machine-local hygiene before moving to the hosted org flow.
  • Buyer: CISO / VP Engineering
  • Consumer: CI pipelines and audit workflows

Proof Point Workflow

wrkr init --non-interactive --org acme --github-api https://api.github.com --json
wrkr scan --config ~/.wrkr/config.json --json
wrkr evidence --frameworks eu-ai-act,soc2,pci-dss --json
wrkr verify --chain --json

If hosted prerequisites are not ready yet, start with wrkr scan --path ./your-repo --json or wrkr scan --my-setup --json and return to the org posture flow once GitHub access is configured. --path scans the selected directory itself when it is the repo root and uses bundle roots such as ./scenarios/wrkr/scan-mixed-org/repos when you want immediate child repos scanned as a repo-set. If you are evaluating Wrkr itself, prefer the curated ./scenarios/wrkr/scan-mixed-org/repos repo-set first. A low posture score or sparse first-run evidence on that bundle is expected and demonstrates the ranking/evidence model.

Low first-run framework_coverage is an evidence-state signal, not a parser failure. Wrkr measures what is currently documented in the scanned state, and wrkr evidence --json now emits additive coverage_note guidance with the same interpretation for operator and automation handoffs.

Boundary With Gait and Vulnerability Scanners

  • Wrkr inventories posture and emits proofable state; it does not enforce runtime tool decisions.
  • Gait is the optional control-layer counterpart when runtime enforcement is needed.
  • Dedicated scanners such as Snyk remain the right tool for package and server vulnerability assessment.