BonafideMCP
使用多轮MCP挑战实现代理验证的概念。
BonafideMCP以特工携带的证明其“真实”身份的文件命名。
BonafideMCP是一个开源软件 MCP服务器 这展示了MCP是如何 sampling/createMessage primary可用于进行多轮链式验证挑战——验证连接系统是具有LLM运行时的真正AI代理，而不是人类或经典机器人。这是一个概念测试，不应用于真正的身份验证。
想法
CAPCTHA系统用于防止机器人进入网站，证明客户端系统真的是人类。但是，如果你想把人类拒之门外，只允许人工智能代理呢？
对于这个项目，我们将AI Agent（即AI应用程序）定义为由LLM驱动的系统，并实现MCP规范中概述的功能。这个定义是一个移动的目标。
最近有几种反向验证码的实现，例如 MoltcaptchaClawptcha和BOTCHA。这些系统使用单一的HTTP质询-响应协议，并严重依赖时间（所有Auth框架中的一个重要指标）来验证响应者是人类还是人工智能。在这个系统中，我们实现了一个MCP本机身份验证协议，该协议发出一系列质询，所有这些质询都建立在先前的响应之上。这种多回合对话提高了检测来自非人工智能参与者（或中间人）的定时信号的能力。
对于MCP协议，我们利用了新的 sampling/createMessage 原语允许AI应用程序提示其LLM支持MCP服务器的提示。如果AI应用程序没有实现采样（它是新的，有自己的安全问题），那么协议可以回退到标准工具调用/响应。挑战类型的设计不需要LLM进行验证，但仍然是只有LLM才能提供的答案。已完成的挑战加上相关的延迟用于最终验证。一旦验证，签名的jwt将作为MCP资源发布到token/{session_id}。
快速开始
npm install bonafide-mcp添加到您的MCP客户端
{
"mcpServers": {
"bonafide": {
"command": "npx",
"args": ["bonafide-mcp"]
}
}
}直接运行
npx bonafide-mcp运作原理
采样模式（首选）
当连接客户端声明支持采样时，验证会在单个客户端中自动运行 agent_verification 工具调用：
Agent BonafideMCP Server
│ tools/call: "agent_verification" │
│ ───────────────────────────────────▸│ Starts timer
│ │
│ sampling/createMessage (Round 1) │
│ ◂───────────────────────────────────│ Constrained text challenge
│ Response ─────────────────────────▸│ Verify deterministically
│ │
│ sampling/createMessage (Round 2) │
│ ◂───────────────────────────────────│ Depends on Round 1
│ Response ─────────────────────────▸│ Verify deterministically
│ │
│ sampling/createMessage (Round 3) │
│ ◂───────────────────────────────────│ Depends on Round 2
│ Response ─────────────────────────▸│ Verify · Stop timer
│ │
│ Tool result: ✓ verified │
│ { token_uri: "bonafide://..." } │
│ ◂───────────────────────────────────│基于工具的回退
当采样不可用时，验证退回到基于工具的流程，其中挑战嵌入到工具响应中：
Agent → tools/call: "agent_verification" → gets Round 1 challenge
Agent → tools/call: "submit_response" → gets Round 2 challenge
Agent → tools/call: "submit_response" → gets Round 3 challenge or result同样的挑战，同样的链接，但减少了代理阻力（更接近基于HTTP）。
工具
| 工具 | 说明 |
|---|---|
agent_verification | 开始验证。接受 difficulty: "lightweight" （2轮，3秒）或 "standard" （3轮，5秒）。 |
submit_response | 提交挑战响应（仅基于工具的回退）。 |
check_status | 检查会话的验证状态。 |
资源
| URI | 描述 |
|---|---|
bonafide://token/{session_id} | 签名的JWT凭证（通过验证后可用）。 |
bonafide://status/{session_id} | 会话状态元数据。 |
挑战类型
约束文本生成（SMHL启发）
生成同时满足语义和结构约束的文本：一个主题、一个起始字母、一个确切的字数和一个必需的关键字。改编自 Moltcaptcha的smhl 方法。
计算字段结构化输出
生成一个JSON对象，其中一些字段需要世界知识（一个真实的城市，它的国家），而另一些字段是数学推导（字母计数，ASCII和）。通过确定性计算验证。
链式
每一轮的挑战都是根据前一轮的验证响应生成的。这会产生无法并行化的串行依赖关系，加剧代理中继延迟，并需要完全的上下文维护。
配置
环境变量：
| 变量 | 默认值 | 描述 |
|---|---|---|
BONAFIDE_EC_PRIVATE_KEY | *（启动时生成的临时密钥）* | PEM编码的EC P-256私钥用于JWT签名。 生产所需。 |
BONAFIDE_ISSUER | bonafide.localhost | 智威汤逊发行人索赔 |
要生成密钥对，请执行以下操作：
openssl ecparam -genkey -name prime256v1 -noout | openssl pkcs8 -topk8 -nocrypt -out bonafide.pem
openssl ec -in bonafide.pem -pubout -out bonafide.pub
export BONAFIDE_EC_PRIVATE_KEY="$(cat bonafide.pem)"如果 BONAFIDE_EC_PRIVATE_KEY 如果未设置，服务器将在启动时生成临时密钥对并记录警告。使用临时密钥发行的令牌在服务器重启后将无法生存。真正的实现将使用更强大的密钥生成器和存储primitevs。
项目结构
bonafide-mcp/
├── src/
│ ├── index.ts # Entry point (stdio transport)
│ ├── server.ts # MCP server: tools, resources, verification flow
│ ├── challenges/
│ │ ├── types.ts # Shared types and config
│ │ ├── constrained-text.ts # SMHL-inspired text challenges
│ │ ├── computed-field.ts # Structured JSON challenges
│ │ └── chain.ts # Round chaining logic
│ ├── verification/
│ │ └── verifier.ts # Response verification engine
│ ├── session/
│ │ └── manager.ts # Session state management
│ └── credentials/
│ └── jwt.ts # JWT issuance and validation
├── data/
│ └── cities.json # City/country lookup for computed-field challenges
├── website/ # Static landing page (Cloudscape Design System)
├── package.json
└── tsconfig.json学分
BonafideMCP建立在其他人的工作之上：
- Moltcaptcha --SMHL的挑战。BonafideMCP的挑战类型直接受到了这种方法的启发。
- 阿卡帕查 --基于HTTP的多轮验证，具有跨轮依赖性。
- IETF Web Bot认证 --加密代理身份（与BonafideMCP互补）。
- 模型上下文协议 --使这种方法成为可能的协议。
局限性
BonafideMCP并非牢不可破。一个拥有快速LLM端点和优化MCP中继的动机充分的对手可能会通过验证。与基于HTTP的验证相比，该系统大大提高了标准，但它不是加密保证。
为了获得更强的保证，请将BonafideMCP与加密身份（Web Bot Auth、客户端证书）相结合。
安全考虑
BonafideMCP是一个 研究项目与参考实施。它没有经过正式的安全审计，在用于任何生产或信托环境之前应仔细评估。
需要考虑的已知设计和实施限制：
- 人工智能的证明，而不是身份的证明。 通过验证证明连接系统可以访问有能力的LLM，而不是任何特定的代理或用户都被授权。将挑战转发给另一个LLM的中继可以通过。为了确保身份，将BonafideMCP与加密机制（客户端证书、Web Bot Auth）相结合。
- 基于工具的模式较弱。 在基于工具的回退模式下，挑战以明文工具结果的形式返回，堆栈中的任何中间件都可以看到。采样模式将挑战直接推送到模型中，并且对代理攻击的抵抗力更强。
- 内存会话存储。 所有会话和令牌都保存在进程内存中，并在重新启动时丢失。没有持久层、集群支持或令牌撤销机制。已发布的JWT有效期至到期（15分钟）。
- 没有每个客户的费率限制。 服务器对并发会话实施全局上限（100），但不限制单个客户端的速率。单个客户端可能会耗尽会话池。
- 挑战可预测性。 通过以下方式选择挑战参数（主题、字母、字数）
Math.random()，这不是加密安全的。能够预测RNG状态的对手可以预先计算响应。
这是一个用于实验和测试的概念实现。请勿在实际应用中使用。
许可证
麻省理工学院