Keel

io.github.lutfizp由 GitHub 账号 lutfizp 发布v0.3.0更新于 Oct 24, 2026

Control plane MCP that dedups scanner output, rate-limits hosts, and runs non-destructive proofs.

已验证STDIO仅桌面开发者工具安全与监控

概览

AI 生成的概览

Keel 是本地 MCP 控制平面,用于授权安全测试:对扫描器结果去重、限制主机请求速率,并执行非破坏性的只读验证。

可以做什么
  • 登记测试范围与流量上限,起草可达性与模板微批次方案,此阶段不发送流量
  • 排队、轮询并取消后台扫描批次,或仅重跑某条来源 Nuclei 模板
  • 查询合并重复扫描结果的语义卡片,并评估可利用性、缺失证据与阴性对照
  • 针对测试者自有数据起草并执行只读验证剧本,返回 proven 或 protected 结论及 curl 复现
  • 记录测试假设,查看参与健康度、冷却、预算与仅追加的审计日志
适用场景
适用于已获授权的漏洞赏金或渗透测试场景:扫描结果噪声大,希望助手协助分诊、避免对目标造成压力,并产出安全可复现的影响证明,而不是原始工具输出。
运行要求
以本地 Python 进程运行,需 Python 3.10 及以上,从 keel-pentest 包安装;setup 会把 ProjectDiscovery 的 httpx 与 nuclei 下载到本地目录。可选 KEEL_APPROVAL_FILE 固定范围与模板,KEEL_CREDENTIALS_FILE 按名称提供测试账号凭据。需要能访问你获授权测试的目标网络。
安装前请注意
它会向你设定范围内的主机发送真实 HTTP 流量,只能用于获授权的测试项目;默认模式为自我声明,即 begin_engagement 本身即为授权。执行验证需开启 allow_safe_proof,并可能使用 KEEL_CREDENTIALS_FILE 中的测试凭据,该文件应存放密钥而非写入工具参数。它会把参与状态写入本地 SQLite 数据库并保留仅追加的审计日志。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Keel,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

[Keel]

Keel

The MCP control plane that turns scanner noise into hunter-grade, non-destructive proofs

[Python] [License] [MCP] [PyPI] [Registry] [Version]

Thirteen MCP tools. Semantic dedup. Per-host rate limits. Safe proofs that show what a hunter can do — without damaging the target.

Why Keel · Install · Clients · Proofs · Tools


Dumping 150 tools on an agent is easy. The hard problems are dedup across tools, exploitable vs noise, and not hammering the target. Keel is the control plane for those three.

An AI client talks to Keel, not to httpx, nuclei, or a shell. Keel drafts one wave at a time, enforces scope and rate limits, merges scanner hits into semantic cards, and runs GET-only playbooks on tester-owned data. When a playbook returns proven, you get a curl replay a hunter can follow — still without writes, shells, or payload spam.

Use it on programs you are authorized to test.

Why Keel

Hard problemWhat scanner dumps doWhat Keel does
Dedup across toolsOne Nuclei template id per row; the same IDOR appears five timesSemantic key from vulnerability class + normalized route + method + parameter. UUID/id/hex tokens collapse. Compatible observations merge.
Exploitable vs noiseHigh severity = "ship it"Cards move through observed → hypothesis → corroborated → proven / refuted. Informational and hardening stay hidden. Typed exploitability names the missing evidence and the negative control.
Not hammering the targetFire every template at once, retry on 429One active wave per host, token buckets, Nuclei concurrency 1, no OAST, no redirects, no unsigned templates, no dos/fuzz/bruteforce/intrusive tags. HTTP 429 becomes a cooldown.

A wrapper that shells out to a huge toolbox does not have that layer. Keel does — in the scheduler, in the adapters, and in the proof broker.

Architecture

mermaid
flowchart TD    A[AI coding client] -->|stdio MCP| B[Keel]    B --> C[Scope and rate gate]    C --> W[Background job and wave scheduler]    W --> H[httpx: one target]    W --> N[nuclei: HTTP templates, bounded]    C --> P[Proof broker: GET only]    P --> T[Tester-owned resource]    H --> S[Semantic card store]    N --> S    P --> S    S --> Q[Triage and evidence states]
  1. begin_engagement with the hostname you are authorized to test.
  2. draft_waves proposes reachability plus template micro-waves. No traffic yet.
  3. execute_wave returns a job immediately. Poll wave_status. cancel_wave kills the scanner.
  4. query_cards returns hunter-relevant cards. assess_exploitability says what would prove it.
  5. draft_proof then execute_proof run a GET-only playbook against tester data. proven means the invariant held. protected means the control worked.

Installation

macOS (Homebrew). pipx is a separate tool — install it first. Apple's /usr/bin/python3 is often 3.9 and cannot install Keel.

bash
brew install pipx [email protected]pipx ensurepath# open a new terminal, then:pipx install keel-pentestkeel-pentest setupkeel-pentest doctor

If python3.12 is already on the machine and you do not want Homebrew pipx:

bash
python3.12 -m pip install --user pipxpython3.12 -m pipx ensurepathpython3.12 -m pipx install keel-pentest

setup downloads ProjectDiscovery httpx and nuclei into ~/.keel/bin. Keel finds them there even when a GUI client has a thin PATH. No extra KEEL_HTTPX_BIN for a first scan.

Then point your MCP client at the keel-pentest executable:

bash
claude mcp add --scope user --transport stdio keel -- keel-pentestcodex mcp add keel -- keel-pentesthermes mcp add keel --command keel-pentest

OpenCode: "command": ["keel-pentest"].

Python 3.10+. Do not pip install keel — that is a different project. OS notes and pip/venv: INSTALL.md. Client shapes: clients/README.md.

Optional later: KEEL_APPROVAL_FILE for a team manifest that pins scope, template IDs, and proof targets. Default mode is self-attested — begin_engagement is the authorization. Rate limits, one-wave-per-host, signed templates, and sanitized evidence still apply.

Safe proofs that still prove impact

Scanner output is a hypothesis. Keel proves (or refutes) it with disposable tester accounts and a unique canary. Every playbook is GET-only, budgeted, and returns a curl replay. The replay is the report artifact: if this is not fixed, a hunter with a normal account can do this.

PlaybookProvesHow, without damage
cross_account_readIDOR / BOLATester A reads its canary; tester B GETs the same A-owned URL. Identical canary + 2xx = proven. 401/403/404 or 2xx without the canary = protected (refuted).
reflected_markerReflected XSS / HTML injectionInject a unique marker plus a harmless <keel> probe. Unescaped reflection = proven. HTML-encoded reflection = protected. Control GET must not already contain the probe.
open_redirect_canaryOpen redirectPoint the redirect parameter at https://keel-proof.invalid/<marker>. A 3xx whose Location host is that canary = proven.
unauth_access_probeMissing authZTester A baseline must show the canary; the same URL with no credentials must not. 2xx + canary unauthenticated = proven.
own_session_markerReachability onlyA reads its own canary. This is corroborated, never vulnerability proof.

execute_proof stores status codes, canary booleans, truncation flags, hashes, hunter impact text, and the repro script. It does not persist response bodies or secrets.

Plant a non-secret canary in a tester-owned object before cross_account_read / unauth_access_probe. Reflected XSS and open redirect inject the marker themselves.

MCP tools

ToolRole
begin_engagementRegister scope and traffic ceilings
draft_wavesPropose reachability + template micro-waves; no traffic
execute_waveQueue one background job
wave_statusStage, progress, result; omit job_id to list
cancel_waveStop a queued or running scanner
query_cardsPrioritized semantic cards
second_lookRe-run only the originating Nuclei template
assess_exploitabilityCandidate impact, missing evidence, negative control, playbooks
state_impactRecord a hunter hypothesis
draft_proofAllowlisted proof plan; no traffic
execute_proofRun the GET-only playbook
engagement_healthCooldowns, budgets, pending waves
engagement_auditAppend-only application events

begin_engagement needs engagement_id and scope_hosts (plain hostnames, e.g. target.example). Defaults: 3 req/s, one host at a time, 120s / 120 requests per wave. allow_safe_proof=true enables proofs. Pass tester credential names only; put secrets in KEEL_CREDENTIALS_FILE.

Example prompt

text
Use only Keel MCP tools. Do not shell out to httpx, nuclei, curl, or exploit tools.
1. begin_engagement for bb-2026-01 with scope_hosts ["target.example"], 3 req/s.   Set allow_safe_proof true if I will run proofs.2. draft_waves for https://target.example.3. execute_wave for each wave. Poll wave_status until completed, retryable_failed,   terminal_failed, or cancelled.4. query_cards (include_noise false), then assess_exploitability on candidates.5. For a card with a safe playbook, draft_proof then execute_proof using tester   credential names and the canary I planted. Treat protected as refuted.6. Summarize duplicates, evidence state, hunter_impact, and the repro_script.   Claim exploitable only when Keel reports proven.

Traffic controls

  • Exact scope and exclusions on draft, admit, ingest, and proof
  • One wave per host; same-host jobs wait
  • Shared global and per-host token buckets
  • Persistent request reservations; retries consume a new reservation
  • Nuclei: signed HTTP templates, no OAST, no redirects, no retries, exclude dos/fuzz/bruteforce/intrusive
  • Isolated empty scanner configs; proxy and ProjectDiscovery-cloud env vars stripped
  • HTTP 429 stops the wave and honors Retry-After
  • Bounded response reads; evidence without raw bodies

Troubleshooting

bash
keel-pentest doctorkeel-pentest setup    # if doctor reports missing httpx/nuclei

begin_engagement after a client restart restores the SQLite engagement. If you changed scope, use a new engagement_id.

Proofs need allow_safe_proof=true and, for session playbooks, KEEL_CREDENTIALS_FILE mapping names like tester-a to Authorization or Cookie.

License

MIT. Copyright (c) 2026 Lutfi Z.P.

PyPI: keel-pentest. MCP Registry: io.github.lutfizp/keel. Source: github.com/lutfizp/keel.

来源:README.md,提交 e659b00

工具

0
SourceWeft 尚未在沙箱中启动过该软件包,因此其工具未知。

版本历史

1
  1. v0.3.0最新Sep 16, 2026

评分

已满足适用检查项的 50%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分