Tripwire

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

Security gateway for MCP agents: blocks prompt-injection-driven tool calls before they execute.

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

概览

AI 生成的概览

Tripwire 是一个本地 MCP 代理,置于工具服务器之前,在执行前拦截由提示注入驱动的工具调用。

可以做什么
  • 代理并合并多个上游 MCP 服务器的工具,以带前缀的工具名重新暴露,定义原样透传
  • 为每次工具结果生成 HMAC 签名收据,并记录哈希链式审计日志
  • 检查敏感参数(地址、金额、邮箱、URL、ID)是否来自可信来源,拦截仅出现在不可信文档中的值
  • 记录声明的意图,并对高风险调用用多模型共识校验意图匹配、来源依据与数值合理性
  • 用通俗语言查看会话记录,并以密码学方式验证日志与收据未被篡改
适用场景
当智能体可以执行付款、交易、写入或发送等有实际后果的操作,而你需要从结构上确认参数有可信证据支撑、而非仅靠正则白名单时适用。也适合事后审计智能体在会话中实际做了什么。
运行要求
以 stdio 本地进程运行,通过 npm 包 tripwire-mcp 安装(需 Node.js),用 tripwire init 或策略 YAML 文件配置。服务端可选的 HTTP 传输在绑定到回环地址之外时必须提供认证令牌。Tier 2 共识需要 Anthropic、OpenAI 或 Google 的 API 密钥;没有密钥时确定性层级仍可运行。
安装前请注意
它位于工具服务器之前并可见全部工具流量,因此会接触这些服务器处理的凭据与数据。它会在本地写入会话文件,包括 HMAC 密钥(除非设置了 TRIPWIRE_HMAC_KEY)。Tier 2 会把包含意图、拟执行调用和证据摘录的校验包发送给第三方模型提供商。README 记录了已知的漏检与误报,因此它是缓解措施而非保证。

安装

在 SourceWeft 中

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

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

其他 MCP 客户端

参照 仓库 中的启动说明。

README

Tripwire

The security gateway for MCP agents that other gateways can't be: it blocks prompt-injection-driven tool calls by checking whether an action is grounded in evidence and intent — not just whether it matches a regex.

[Tripwire stops the poisoned-invoice attack: the same agent pays an attacker when undefended, and is blocked then self-corrects when Tripwire is on]

sh
npm install -g tripwire-mcp   # then: tripwire init

AI agents now take real actions — payments, trades, writes, sends — and the parameters of those actions are taken on faith. Existing MCP security gateways are syntactic (globs, allowlists, regex); none can answer the question that matters: is this action grounded in the evidence and consistent with the user's intent? A payment to an attacker's address looks identical to a payment to the real vendor.

Tripwire is an MIT-licensed MCP proxy. Point any MCP agent at Tripwire instead of its tool servers; Tripwire forwards everything transparently while running a three-tier verification pipeline on calls that policy marks as consequential:

  • Tier 0 — Receipts (deterministic, ~1ms). Every tool result is signed with HMAC-SHA256 into an unforgeable ledger of what actually happened. Fabricated tool results and tampered values fail against the receipts.
  • Tier 1 — Provenance (deterministic, ~ms). Every value observed in tool results is indexed with its origin and trust label. A payment address that only ever appeared inside an untrusted document is blocked by construction — no model call, no heuristic.
  • Tier 2 — Multi-model consensus (probabilistic, high-stakes only). Independent models from different providers check intent match, source grounding, and bounds/sanity, with strict-JSON verdicts, quorum aggregation, and fail-closed semantics.

Every decision — including passes — lands in a hash-chained, append-only audit log that tripwire verify-log re-validates.

The full design and build plan is in TRIPWIRE_PLAN.md.

Read next: docs/THREAT_MODEL.md — what each tier defends against, and exactly what Tripwire cannot do. docs/POLICY.md — the policy YAML reference.

Status

v0.3.0 — all five build phases complete, plus a no-engineering-required setup flow (tripwire init / check / logs) and HTTP transport for server-side deployments (one Tripwire process, many isolated agent sessions). See docs/GETTING_STARTED.md and Server-side (HTTP).

  • Phase 1 — Transparent proxy + receipts. stdio MCP proxy; tools from multiple upstreams merged and re-exposed as <upstream>__<tool> with definitions passed through verbatim; byte-equivalent passthrough proven by integration test; HMAC-SHA256 receipt ledger over canonical JSON (in-memory + JSONL); hash-chained audit log of all traffic; tripwire verify-log.
  • Phase 2 — Policy engine + provenance index. Zod-validated YAML policy (tool globs, upstream, annotation matching; first rule wins); session value-provenance index over every receipted result (addresses, amounts, emails, URLs, ids — normalized across case, whitespace, hex prefixes, number formatting); structural Tier 1 enforcement of sensitive_params provenance, with anti-laundering (echoed inputs never gain a tool's trust label, failed executions are not evidence); structured machine-actionable BLOCK results built for agent self-correction. The poisoned-invoice attack is blocked by Tier 1 alone — zero model calls.
  • Phase 3 — Intent capture + Tier 2 consensus. Synthetic tripwire__declare_intent tool (receipted; policy can require it via require_intent, and the block error tells the agent how to self-serve); verification packet builder (intent + proposed call + Tier 1 provenance + receipted evidence excerpts); thin fetch-based verifier clients for Anthropic/OpenAI/Google with strict JSON verdict parsing; parallel panel with majority/unanimous quorum; timeouts, malformed output, and missing keys all count as failed verdicts under fail-closed; verifier disagreement flagged as signal; versioned prompt templates pinned in every audit entry. Live smoke script gated behind env keys (npm run smoke:live); CI stays fully deterministic with mocked verifiers.
  • Phase 4 — Benchmark + demo. 42-scenario corpus (21 attacks, 21 legitimate false-positive traps); deterministic harness whose numbers reproduce in CI with zero API calls; npm run demo shows the disarmed agent paying the attacker, the identical agent blocked structurally and self-correcting, and Tier 2 catching a plausible-but-wrong amount.
  • Phase 5 — Threat model + launch. docs/THREAT_MODEL.md (per-tier defenses, assumptions stated as attack surface, and a plain list of what Tripwire does NOT defend against), docs/POLICY.md policy reference, v0.1.0.

The demo

sh
npm installnpm run demo          # deterministic, no API keys needednpm run demo -- --live  # same demo with a real multi-provider verifier panel

Three runs of the same scripted agent against the same poisoned invoice ("our banking details changed — remit to 0xBBBB…"):

  1. Disarmed: the agent reads the invoice, believes it, and pays the attacker. The money is gone.
  2. Armed: the identical script is blocked by Tier 1 — the address only ever appeared inside untrusted document content, so the call is refused structurally, with zero model calls. The agent reads the machine-actionable error, re-queries the trusted vendor record, and pays the real vendor.
  3. Armed, Tier 2: the agent fat-fingers the amount (the full treasury balance — a value that is receipted, so Tier 1 passes). The consensus panel's bounds_and_sanity check blocks it; the agent re-reads the invoice and pays the right amount.

The demo ends with the audit excerpt: every decision hash-chained, every execution HMAC-receipted.

Benchmark

42 scripted sessions: 21 attacks, 21 legitimate flows built to tempt false positives (vendors genuinely rotating banking details, unusual-but-correct amounts, batches, encoding variations, partial payments). Reproduce with npm run bench; the numbers are pinned by test/bench.test.ts.

MetricResult
Attacks caught19/21 (90.5%)
— caught by Tier 1 (structural, 0 model calls)15/21
— caught by Tier 2 (consensus)4/21
Attacks missed (documented)2/21
False-block rate (the headline)1/21 (4.8%)

Honesty notes, because alert fatigue is how security tools die:

  • The two misses are documented in the corpus: conflicting "amount due" figures across documents (requires live-model judgement; the offline heuristic accepts any documented amount), and a stale-but-trusted rotated wallet (receipt-ordering staleness flags are the Tier 0 roadmap item).
  • The one false positive is a partial payment (5,000 against a 12,500 invoice): the offline bounds heuristic can't read the installment agreement; live verifier panels can.
  • Tier 2 numbers above use the deterministic offline reference verifier so they reproduce exactly in CI. npm run bench -- --live re-runs the corpus against a real Anthropic/OpenAI/Google panel.

What a Tier 1 block looks like

The agent reads a poisoned invoice ("our banking details changed: 0xBBBB…") and tries to pay it. The address only ever appeared inside untrusted document content, so the call never reaches the payment rail:

json
{  "tripwire": "blocked",  "code": "provenance_violation",  "tool": "payments__send_payment",  "violations": [    {      "param": "recipient",      "reason": "untrusted_provenance",      "required_provenance": "trusted",      "value_preview": "0xBBBB000000…0000BBBB",      "observed_origins": [        {          "upstream": "docs",          "tool": "docs__read_document",          "trust": "untrusted",          "receipt_seq": 2        }      ]    }  ],  "remediation": "Fetch the required value from a trusted tool in this session…"}

A well-built agent reads this, re-queries the vendor record (trusted), and retries with the real address — which passes. That loop is tested end-to-end with zero verifier models in test/tier1.integration.test.ts.

Set it up (no config files to hand-write)

New to this? Follow docs/GETTING_STARTED.md — written for non-engineers.

sh
npm install -g tripwire-mcp     # or, before the npm release: github:bonesdefi/tripwire
tripwire init     # answers a few plain-language questions, writes your configtripwire check    # confirms your servers start and your rules make sense

tripwire init also writes tripwire-agent-config.json — paste it into your AI agent's MCP settings (Claude Desktop, Claude Code, etc.), replacing the tool servers it lists today. Tripwire now sits in front of them. Then use your agent normally; dangerous calls are verified, and tripwire logs shows you what happened in plain English.

See the attack and the defense first

sh
npm run demo      # the poisoned-invoice story, no API keys needed

Server-side (HTTP)

Running agents server-side rather than on a laptop? Switch the transport and one Tripwire process serves many agents — each in a fully isolated verification session (own receipts, provenance, audit, upstream connections):

yaml
transport:  type: http  http: { host: 127.0.0.1, port: 8765, auth_token: a-long-random-secret }

Agents connect to http://…:8765/mcp with Authorization: Bearer …. Binding beyond loopback requires the token — Tripwire refuses to start exposed-but-unauthenticated. Details and the threat model for network exposure: docs/POLICY.md, docs/THREAT_MODEL.md.

Run it by hand

sh
tripwire run --config tripwire.example.yaml

That proxies three toy servers (a trusted vendor DB, an untrusted document reader, a payments rail). Point any MCP client at that command:

json
{  "mcpServers": {    "tripwire": {      "command": "tripwire",      "args": ["run", "--config", "tripwire.example.yaml"]    }  }}

Every session records to .tripwire/sessions/<session-id>/:

FileContents
receipts.jsonlHMAC-signed receipt for every tool execution (created mode 0600)
audit.jsonlhash-chained audit log — hashes and receipt refs, no raw values
hmac.keysession receipt key (omitted when TRIPWIRE_HMAC_KEY is set)

Read a session in plain English, or verify it cryptographically:

sh
tripwire logs .tripwire/sessions/<session-id>        # what happened, in plain Englishtripwire verify-log .tripwire/sessions/<session-id>  # prove the record wasn't altered# audit chain    OK   (14 entries)# receipts       OK   (7 receipts)

Tamper with a single byte of either file and verification fails loudly, naming the line.

Development

sh
npm test            # deterministic; spawns real MCP servers over stdio, no API keys needednpm run typechecknpm run lintnpm run build

License

MIT

来源:README.md,提交 142dbc4

工具

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

版本历史

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

评分

已满足适用检查项的 50%

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

  • 近 30 天内可连通25 分

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

  • 已声明认证方式10 分

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

  • 已列出工具15 分

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

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