MCP Trust Gateway

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集成。这 *身份* 问题基本解决了。

但仍然存在四个缺口，它们都位于身份验证之上：

共同点： 身份验证对于自主代理是必要的，但还不够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工具类别映射到信任层，而不是任意服务器定义的作用域字符串：

这赋予了范围以经过验证的身份为基础的意义，而不是服务器的突发奇想。

安装

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"
      }
    }
  }
}

配置

项目结构

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结算mcp： 这 MCP服务器 暴露结算 *运营* 作为工具（创建托管、检查余额等）。此网关评估 *信任* MCP工具调用。它们是互补的——您可以使用此网关后面的MCP服务器，也可以使用网关来保护任何其他MCP服务器。

贡献

看 贡献.md目前最具影响力的贡献是 规格.md --帮助将信任层正式化，以便可以在MCP生态系统的上游提出。

许可证

MIT。看 许可证.