Agentomy MCP 网关

Agentomy 的一个开源组件，面向受监管企业中 AI 代理的治理层。其他组件见 github.com/getagentomy。

通过坐镇代理与服务器之间，治理任意 stdio MCP 服务器。每一次 tools/call 在到达服务器之前都会依据你的策略接受检查。被拒绝的请求由网关应答， 绝不会被转发，因此副作用不会发生。

上游服务器本身没有任何改变。它不会被修补、不会被分叉，也永远不会 知道自己正被治理。

为什么选择拦截而非观察

一个旁路组件观察 MCP 流量并生成报告，产出的只是它未能阻止的事件的记录。 只有坐在链路上，才能把报告变成拒绝。

Related MCP server: jamjet-policy

安装与运行

# Instead of launching the MCP server directly:
#   my-mcp-server --flag
# launch it through the gateway:
AGENTOMY_ENDPOINT=https://your-agentomy \
AGENTOMY_API_KEY=... \
  agentomy-mcp-gateway, my-mcp-server --flag

在代理的 MCP 配置中，替换服务器的 command 和 args：

{
  "mcpServers": {
    "dev-tools": {
      "command": "agentomy-mcp-gateway",
      "args": ["--", "the-original-command", "--its", "--flags"],
      "env": { "AGENTOMY_ENDPOINT": "https://your-agentomy", "AGENTOMY_API_KEY": "..." }
    }
  }
}

这就是全部集成工作。由操作员为每个代理做一处配置更改。

它对协议做了什么

请求按到达顺序裁决。并发裁决会让后到的调用先于较早的调用到达服务器， 这是一种只在负载下才会暴露的重排序缺陷。

故障即拒绝，以及它的代价

每一条故障路径都拒绝：

诚实的权衡：如果平台宕机，受治理的工具就会停止工作。 这对治理组件而言 是正确的行为，同时也是一种真实的可用性耦合。请据此运维平台。

这些原因是刻意区分的。操作员看到 governance_unreachable 意味着一次故障； 看到 policy_denied 则是一个策略问题。把它们合并成"拒绝"会在差异最关键的 时刻让两者无法区分。

缺少 authorized 字段时拒绝，而不是按真值读取，因为真值检查会把任何意外 载荷（包括错误对象）变成放行。

它不做什么

它治理的是动作，而不是发现。tools/list 直接放行。在缩小代理可以看到什么 的同时放任它可以做什么不受治理，那是放错了地方的表面文章。

它不改写结果。网关裁决请求；让它编辑响应会把它变成对话的参与者， 而不是对话上的一道闸门。

它不做参数语义检查。策略收到的是工具名和参数键，而不是值。参数级策略是 平台层面的关注点，把完整参数值发送到决策端点会把文件内容和 shell 命令 送进第二个系统。

许可证

Apache-2.0。