Wrkr

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 gives developers a deterministic local-machine hygiene path when they want to inspect their own setup first. It discovers supported AI dev tools, MCP servers, and agent frameworks, maps what they can touch, shows what changed, and emits proof artifacts for audits and CI.

Security/platform-led. Developer hygiene included. Deterministic by default.

Docs: clyra-ai.github.io/wrkr | Command reference: docs/commands/ | Examples: docs/examples/

Install

Homebrew

brew install Clyra-AI/tap/wrkr

Go install

go install github.com/Clyra-AI/wrkr/cmd/wrkr@latest

Start Here

Recommended minimum-now public path: start with the security/platform workflow below when you need org posture and evidence. The developer-machine path remains available as a secondary self-serve hygiene flow.

Developers (Secondary local hygiene)

Start with your own machine.

wrkr scan --my-setup --json
wrkr mcp-list --state ./.wrkr/last-scan.json --json

cp ./.wrkr/last-scan.json ./.wrkr/inventory-baseline.json
wrkr inventory --diff --baseline ./.wrkr/inventory-baseline.json --state ./.wrkr/last-scan.json --json

In one flow, Wrkr answers:

• What AI tools, agents, and MCP servers are configured in my local setup?
• Which API-key environments are present without exposing secret values or creating approvable identities?
• Which MCP servers are requesting access, over what transport, and with what trust status?
• What changed since my last known-good snapshot?

Environment-key presence and source-bookkeeping signals stay in findings and risk output. Lifecycle identities and approvals are reserved for real tool, agent, and MCP surfaces. For scan --my-setup, Wrkr also emits additive activation.items when concrete local tool, MCP, or secret signals exist so the first-value path stays concrete without mutating the raw top_findings ranking.

Abbreviated scan --my-setup example:

{
  "status": "ok",
  "target": {
    "mode": "my_setup"
  },
  "top_findings": [
    {
      "risk_score": 9.3,
      "finding": {
        "severity": "high",
        "finding_type": "mcp_server",
        "tool_type": "mcp",
        "location": ".claude/settings.json"
      }
    },
    {
      "risk_score": 7.4,
      "finding": {
        "severity": "high",
        "finding_type": "secret_presence",
        "tool_type": "secret",
        "location": "process:env"
      }
    },
    {
      "risk_score": 6.8,
      "finding": {
        "severity": "medium",
        "finding_type": "tool_config",
        "tool_type": "agent_project",
        "location": "Projects/payments-bot/AGENTS.md"
      }
    }
  ],
  "warnings": [
    "MCP visibility may be incomplete because these declaration files failed to parse: .codex/config.yaml"
  ],
  "activation": {
    "target_mode": "my_setup",
    "message": "Review 3 concrete local AI tool, MCP, or secret signal(s) first. Policy-only items remain in the raw ranking but are suppressed from this activation view.",
    "eligible_count": 3,
    "suppressed_policy_items": true,
    "items": [
      {
        "rank": 1,
        "risk_score": 9.3,
        "finding_type": "mcp_server",
        "tool_type": "mcp",
        "location": ".claude/settings.json"
      }
    ]
  }
}

Abbreviated mcp-list example:

{
  "status": "ok",
  "rows": [
    {
      "server_name": "postgres-prod",
      "transport": "stdio",
      "requested_permissions": ["db.write"],
      "privilege_surface": ["write"],
      "gateway_coverage": "unprotected",
      "trust_status": "unreviewed",
      "risk_note": "Gateway posture is unprotected; review least-privilege controls."
    },
    {
      "server_name": "slack",
      "transport": "http",
      "requested_permissions": ["network.access"],
      "privilege_surface": ["read"],
      "gateway_coverage": "protected",
      "trust_status": "trusted",
      "risk_note": "Static MCP declaration discovered; verify package pinning and trust."
    }
  ]
}

Wrkr is not a vulnerability scanner. It inventories what is configured and what it can touch. Use dedicated tools such as Snyk for package and server vulnerability assessment.

Security Teams (Recommended first path)

Start here when you need organization-wide posture, ranked risks, and compliance-ready proof artifacts.

wrkr scan --github-org acme --github-api https://api.github.com --json
wrkr evidence --frameworks eu-ai-act,soc2,pci-dss --state ./.wrkr/last-scan.json --output ./.wrkr/evidence --json

Hosted scans usually need GitHub authentication for private repos and to avoid public API rate limits.

Abbreviated org-scan example:

{
  "status": "ok",
  "target": {
    "mode": "org",
    "value": "acme"
  },
  "top_findings": [
    {
      "risk_score": 9.7,
      "finding": {
        "rule_id": "WRKR-A004",
        "severity": "critical",
        "tool_type": "agent",
        "location": "services/ops/agent.py"
      }
    }
  ],
  "inventory": {
    "tools": 47,
    "agents": 12,
    "security_visibility_summary": {
      "reference_basis": "state_snapshot",
      "unknown_to_security_tools": 6,
      "unknown_to_security_agents": 9,
      "unknown_to_security_write_capable_agents": 3
    }
  },
  "agent_privilege_map": [
    {
      "agent_id": "wrkr:langchain-inst-a1b2c3d4e5:acme",
      "agent_instance_id": "langchain-inst-a1b2c3d4e5",
      "framework": "langchain",
      "symbol": "planner_agent",
      "bound_tools": ["postgres-prod", "slack"],
      "bound_data_sources": ["prod-db"],
      "bound_auth_surfaces": ["OPENAI_API_KEY"],
      "deployment_status": "deployed",
      "write_capable": true,
      "security_visibility_status": "unknown_to_security",
      "production_write": false
    }
  ],
  "compliance_summary": {
    "frameworks": [
      {
        "framework": "soc2",
        "mapped_finding_count": 12
      },
      {
        "framework": "eu-ai-act",
        "mapped_finding_count": 8
      },
      {
        "framework": "pci-dss",
        "mapped_finding_count": 5
      }
    ]
  }
}

Your developers are already using AI coding tools, agents, and MCP servers. That is not the problem. The problem is being unable to inventory them, map what they can touch, and prove they are governed.

Wrkr scans your GitHub org, shows supported AI tools and agents with privilege mapping and policy gaps, and emits evidence bundles your team can hand to auditors. Your developers keep moving. You get the posture and the proof.

Why Wrkr

AI tool usage is already happening across developer machines, repositories, MCP configs, and CI pipelines.

Developers need fast answers:

• What is configured on my machine?
• What can it touch?
• What changed since last scan?

Security teams need organization-wide answers:

• Which AI tools and agents exist across repos?
• Which ones are write-capable right now, and which ones become production_write only after production targets are configured?
• Which unknown-to-security paths can already write or touch credentials?
• Which findings map to policy and compliance frameworks?
• Can we hand an auditor a deterministic evidence bundle instead of a spreadsheet?

Wrkr answers both without requiring runtime interception or moving scan data out of your environment.

What You Get

• Local AI setup inventory for supported user-home config surfaces.
• MCP server catalog with transport, requested permissions, trust overlay, and posture notes.
• Org-wide inventory of AI tools, agent frameworks, CI execution patterns, and MCP declarations.
• Deterministic, instance-scoped identity and privilege mapping for real tool-bearing surfaces.
• Native structured parsing for supported agent frameworks including LangChain, CrewAI, OpenAI Agents SDK, AutoGen, LlamaIndex, MCP-client patterns, and conservative custom-agent scaffolds.
• First-class security_visibility_status for approved, known_unapproved, and unknown_to_security agent/tool paths.
• Relationship resolution from agents to tools, data sources, auth surfaces, and deployment artifacts.
• Ranked findings, attack-path context, and posture scoring.
• inventory --diff for drift review against a known-good snapshot.
• Policy findings with stable rule IDs and remediation text.
• Compliance mappings for EU AI Act, SOC 2, PCI-DSS, and related frameworks.
• Signed evidence bundles for audit and CI workflows.
• Native JSON, SARIF, and proof-friendly output contracts.

What Wrkr Detects

Wrkr is deterministic and file-based by default.

It detects supported signals from:

• Local-machine setup rooted at the current user home directory.
• Repository config and source surfaces.
• GitHub repo and org acquisition targets.
• MCP declarations and gateway posture.
• AI tool configs for Claude, Cursor, Codex, Copilot, skills, and CI agent execution patterns.
• Agent definitions and bindings from supported framework-native sources, conservative custom-agent scaffolds, and explicit wrkr:custom-agent custom-source markers.
• Deployment artifacts linking agents to Docker, Kubernetes, serverless, and CI/CD paths.
• Prompt-channel and attack-path risk signals from static artifacts.

What Wrkr Does Not Do

• It does not probe MCP endpoints live by default.
• It does not replace package or vulnerability scanners.
• It does not enforce runtime tool behavior or block agents.
• It does not monitor live runtime traffic.
• It does not turn environment-key presence or source-bookkeeping findings into approvable lifecycle identities.
• It does not use LLMs in scan, risk, or proof paths.

Wrkr is the inventory and posture layer. Gait is the control layer when runtime enforcement is needed.

Works With Gait

Wrkr discovers what is configured. Gait enforces what is allowed to execute.

Use Wrkr when you want to answer:

• What tools and agents exist?
• What can they touch?
• What changed?
• Where are the policy and compliance gaps?

Use Gait when you want to answer:

• Should this action be allowed right now?
• Should this tool be blocked, gated, or require approval?

The two products complement each other. Wrkr gives you the inventory and evidence. Gait gives you runtime control.

Typical Workflows

Personal AI setup hygiene

wrkr scan --my-setup --json
wrkr mcp-list --state ./.wrkr/last-scan.json --json
cp ./.wrkr/last-scan.json ./.wrkr/inventory-baseline.json
wrkr inventory --diff --baseline ./.wrkr/inventory-baseline.json --state ./.wrkr/last-scan.json --json

Repo or org posture review

wrkr scan --github-org acme --github-api https://api.github.com --json
wrkr report --top 5 --json
wrkr evidence --frameworks eu-ai-act,soc2,pci-dss --state ./.wrkr/last-scan.json --output ./.wrkr/evidence --json
wrkr verify --chain --state ./.wrkr/last-scan.json --json

CI distribution

wrkr scan --path . --sarif --json
wrkr regress run --baseline ./.wrkr/inventory-baseline.json --state ./.wrkr/last-scan.json --json

Command Surface

• wrkr scan scans local setup, repos, or GitHub orgs.
• wrkr mcp-list projects MCP posture from saved state.
• wrkr inventory --diff shows deterministic drift from baseline.
• wrkr report renders ranked summaries from saved state.
• wrkr evidence builds signed, compliance-ready evidence bundles.
• wrkr verify verifies proof-chain integrity.
• wrkr regress gates on drift and regressions.
• wrkr version reports CLI version in human or JSON form.

Output And Contracts

Wrkr treats machine-readable output and exit codes as product contracts.

• --json emits stable machine-readable output.
• --sarif emits SARIF 2.1.0 for security tooling and GitHub code scanning workflows.
• Partial-result mode preserves findings when a detector or source path fails non-fatally.
• --timeout and signal cancellation are enforced end-to-end.
• Exit codes remain deterministic across success, runtime failure, verification failure, policy/schema violation, approval-required, regress drift, invalid input, dependency missing, and unsafe-operation-blocked paths.

Security And Privacy

• Read-only by default.
• No raw secret values are emitted in findings.
• Local setup scans keep data in your environment.
• Local path scans stay bounded to the selected repo root; root-escaping symlinked config, env, workflow, and MCP files are rejected with explicit diagnostics instead of being read.
• Evidence is file-based, portable, and verifiable.
• Same input, same output, barring explicit timestamps and version fields.

Learn More

• Quickstart: docs/examples/quickstart.md
• Personal hygiene workflow: docs/examples/personal-hygiene.md
• Security-team workflow: docs/examples/security-team.md
• Scan command: docs/commands/scan.md
• MCP list: docs/commands/mcp-list.md
• Inventory drift: docs/commands/inventory.md
• Evidence bundles: docs/commands/evidence.md
• Positioning: docs/positioning.md