MCP信任网关
  
MCP的信任、声誉和经济责任——OAuth之上缺失的一层。
MCP的OAuth 2.1基础答案 *这个代理人是谁?* 此网关回答了更难的问题: 经过认证,但值得信赖? 它作为一个协议透明的代理,位于MCP客户端和上游MCP服务器之间,通过由 A2A结算交易所 声誉、KYA等级、支出限制和授权链。
MCP Client Upstream MCP Servers
(Claude, Cursor, agents) (any MCP server)
│ ▲
│ MCP Streamable HTTP │
│ + OAuth 2.1 / PKCE │
▼ │
┌───────────────────────────────────────────────────────────────┐
│ MCP Trust Gateway │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ OAuth 2.1 │ │ Trust │ │ Pre-Auth Tool │ │
│ │ + Settlement│ │ Evaluator │ │ Discovery │ │
│ │ Claims │ │ (KYA + EMA) │ │ (/.well-known/ │ │
│ │ │ │ │ │ mcp-tools) │ │
│ └──────┬──────┘ └──────┬───────┘ └──────────────────────┘ │
│ │ │ │
│ ┌──────┴──────┐ ┌──────┴───────┐ │
│ │ RFC 8693 │ │ Scope-to-KYA │ │
│ │ Token │ │ Tier Mapper │ │
│ │ Exchange │ │ │ │
│ │ + Trust │ │ │ │
│ │ Decay │ │ │ │
│ └─────────────┘ └──────────────┘ │
└───────────────────────────┬───────────────────────────────────┘
│ queries
▼
┌───────────────────────┐
│ A2A Settlement │
│ Exchange │
│ (reputation, KYA, │
│ agent directory) │
└───────────────────────┘差距
MCP在身份验证方面取得了真正的进展。带有PKCE的OAuth 2.1、可流式HTTP传输、Claude的API中的MCP连接器,以及Auth0和AWS的企业IdP集成。这 *身份* 问题基本解决了。
但仍然存在四个缺口,它们都位于身份验证之上:
| MCP挑战 | 根本问题 | 此网关提供什么 |
|---|---|---|
| 范围标准化 | read:files 表示每个服务器决定的任何内容 | 信任层映射的作用域:KYA级别给出的作用域含义超出了任意字符串 |
| 第三方代理被重定向阻止 | 自治代理无法执行基于浏览器的OAuth重定向 | 授权中介:网关使用经济气隙模式代表代理处理OAuth |
| 在身份验证后进行工具发现 | 代理必须先进行身份验证,然后才能知道存在哪些工具 | 预身份验证发现端点(/.well-known/mcp-tools)由交易所的代理目录和代理卡支持 |
| 多跳代币交换 | RFC 8693没有解决跨委派跳的信任衰减问题 | 信任衰减令牌交换:EMA声誉评分分层在RFC 8693之上,委派链限制了每跳的权限 |
共同点: 身份验证对于自主代理是必要的,但还不够OAuth表示“此令牌有效。”信任网关补充道“以下是您应该信任呈现它的代理的程度。”
运作原理
1.信任丰富的OAuth
该网关实现了MCP的OAuth 2.1流(授权码+PKCE),但通过以下方式丰富了已发行的令牌 和解索赔:
{
"sub": "agent:analytics-bot-7f3a",
"scope": "settlement:transact mcp:tool:invoke",
"https://a2a-settlement.org/claims": {
"agent_id": "analytics-bot-7f3a",
"org_id": "org-acme-corp",
"kya_level": 1,
"reputation": 0.87,
"spending_limits": { "per_transaction": 500, "per_day": 5000 },
"counterparty_policy": { "require_min_reputation": 0.7 },
"delegation": {
"chain": [{ "principal": "user:julie@acme.com", "delegated_at": "2026-03-01T09:00:00Z" }],
"transferable": false
}
}
}令牌携带身份(OAuth) *和* 单个工件中的可信度(结算索赔)。
2.预授权工具发现
代理可以发现可用的工具及其信任要求 *之前* 身份验证:
GET /.well-known/mcp-tools{
"tools": [
{
"name": "query_database",
"description": "Run read-only SQL queries",
"required_kya_level": 0,
"required_reputation": 0.0,
"required_scope": "mcp:read"
},
{
"name": "execute_trade",
"description": "Submit a trade order",
"required_kya_level": 2,
"required_reputation": 0.8,
"required_scope": "mcp:tool:financial"
}
]
}客户端在启动OAuth之前评估他们需要什么权限。不再有盲目的授权提示。
3.每次通话的信任评估
在每一个代理 tools/call,网关评估:
- KYA层 >=工具所需的层(身份验证深度)
- EMA声誉 >=工具的最低阈值(跟踪记录)
- 支出限额 未超过(经济护栏)
- 交易对手政策 允许上游服务器(组织约束)
- 授权链 完好无损,可转让的旗帜允许跳跃
如果信任不足,网关将返回带有升级路径的结构化拒绝:
{
"error": "trust_insufficient",
"required_kya_level": 2,
"current_kya_level": 1,
"upgrade_url": "https://exchange.example.com/kya/upgrade",
"message": "This tool requires AUDITABLE identity verification. Current level: ORGANIZATIONAL."
}4.信任衰退代币交换
对于多跳场景(代理A委托给调用工具C的代理B),网关实现了扩展了信任衰减的RFC 8693令牌交换:
Agent A (reputation: 0.92)
│
│ RFC 8693 token exchange
│ trust_score = 0.92 × 0.85 decay = 0.782
▼
Agent B (delegated token, effective trust: 0.782)
│
│ second hop
│ trust_score = 0.782 × 0.85 decay = 0.665
▼
Tool C (requires min reputation: 0.6) ✓ allowed委托链中的每一跳都会通过EMA加权衰减降低有效信任。范围狭窄(从不扩大)。支出限额按比例降低。结果是:“是的,这个令牌是有效的,但它离原始主体越远,它的权威就越小。”
5.信任层映射的范围
网关将MCP工具类别映射到信任层,而不是任意服务器定义的作用域字符串:
| MCP范围 | 需要KYA级别 | 含义 |
|---|---|---|
mcp:read | SANDBOX(0) | 只读访问,任何代理 |
mcp:tool:invoke | SANDBOX(0) | 基本工具调用 |
mcp:tool:write | 组织(1) | 改变状态的工具 |
mcp:tool:financial | 可审计(2) | 具有经济影响的工具 |
mcp:delegate | 可审计(2) | 次级授权 |
这赋予了范围以经过验证的身份为基础的意义,而不是服务器的突发奇想。
安装
pip install -e .或者从git:
pip install git+https://github.com/a2a-settlement/mcp-trust-gateway.git快速开始
1.启动网关
export A2A_EXCHANGE_URL=http://localhost:3000
export MCP_TRUST_GATEWAY_PORT=3100
python -m mcp_trust_gateway网关从端口3100开始,代理到交换机代理目录中注册的上游MCP服务器。
2.连接克劳德桌面
添加 claude_desktop_config.json:
{
"mcpServers": {
"trust-gateway": {
"url": "http://localhost:3100/mcp",
"authorization": {
"type": "oauth2",
"authorization_url": "http://localhost:3100/oauth/authorize",
"token_url": "http://localhost:3100/oauth/token"
}
}
}
}3.连接光标
添加 .cursor/mcp.json:
{
"mcpServers": {
"trust-gateway": {
"url": "http://localhost:3100/mcp",
"env": {
"A2A_EXCHANGE_URL": "http://localhost:3000"
}
}
}
}配置
| 变量 | 默认值 | 描述 |
|---|---|---|
A2A_EXCHANGE_URL | http://localhost:3000 | A2A结算交易所URL |
MCP_TRUST_GATEWAY_PORT | 3100 | 网关侦听端口 |
MCP_TRUST_DECAY_FACTOR | 0.85 | 每次代表团跳跃时信任度下降 |
MCP_TRUST_MIN_REPUTATION | 0.0 | 全球最低信誉底线 |
MCP_TRUST_DEFAULT_KYA | 0 | 未经验证的代理的默认KYA级别 |
OAUTH_ISSUER | (必需) | OAuth令牌颁发者URL |
OAUTH_SIGNING_KEY | (必填) | 用于签署已发行代币的密钥 |
项目结构
mcp-trust-gateway/
SPEC.md # RFC-style trust layer specification
README.md
pyproject.toml
src/mcp_trust_gateway/
__init__.py
__main__.py # Entry point
config.py # Environment configuration
server.py # MCP server (client-facing)
proxy.py # MCP client (upstream-facing proxy)
oauth/
provider.py # OAuth 2.1 + PKCE authorization endpoint
token_exchange.py # RFC 8693 with trust decay
metadata.py # RFC 8414 / RFC 9728 metadata
trust/
evaluator.py # Trust evaluation engine
scope_mapper.py # MCP scope SettlementScope KYA tier
trust_decay.py # EMA-weighted trust decay for delegation
discovery/
well_known.py # /.well-known/mcp-tools endpoint
registry.py # Exchange directory -> tool manifest bridge
tests/
examples/设计原则
协议透明代理。 网关没有定义自己的MCP工具。它代理上游MCP服务器,并添加信任评估作为中间件。任何现有的MCP服务器都可以在不进行修改的情况下工作。
规格优先。 这 规格.md 这是主要的可交付成果,也是作为缺失的信任层向MCP生态系统提出的。代码是参考实现。
添加剂,没有竞争力。 这建立在MCP的OAuth 2.1基础之上。它不会取代它、分叉它或与它竞争。它回答了OAuth从未设计过的问题: *你应该信任这个代理人吗?*
相关项目
| 项目 | 描述 |
|---|---|
| a2a结算 | 核心结算交易所+SDK(信誉、KYA、托管) |
| a2a结算授权 | OAuth结算范围、索赔、支出限制、委托链 |
| a2a结算mcp | MCP服务器将结算操作作为工具公开 |
| a2a和解调解员 | 基于人工智能的争议解决 |
| a2a结算仪表板 | 人工监督仪表板 |
| 赛特布里奇艾 | SettleBridge网关——结算请求的信任/策略执行 |
| otel代理商来源 | OpenTetry来源约定 |
| a2a联盟rfc | 联邦协议——跨交易所的信任折扣 |
| langgraph-a2a-结算 | LangGraph集成 |
| 克鲁瓦伊-a2a-定居点 | CrewAI集成 |
| litellm-2a-定居点 | LiteLLM集成 |
| adk-a2a-setting | 谷歌ADK集成 |
此网关与a2a结算mcp: 这 MCP服务器 暴露结算 *运营* 作为工具(创建托管、检查余额等)。此网关评估 *信任* MCP工具调用。它们是互补的——您可以使用此网关后面的MCP服务器,也可以使用网关来保护任何其他MCP服务器。
贡献
看 贡献.md目前最具影响力的贡献是 规格.md --帮助将信任层正式化,以便可以在MCP生态系统的上游提出。
许可证
MIT。看 许可证.
