Fides Gateway：信息流标签、策略建议与策略求值的副作用边界

wiki/ai/sources/fides-gateway-ifc-policy-as-effectful-tool.md

分类：ai / sources · 更新：2026-10-01 09:03

Fides Gateway：信息流标签、策略建议与策略求值的副作用边界

知识点轴：MCP Gateway / harness-runtime / sandbox-security（高权重），关联 context management；不是 A2A 落地证据。 微软研究原型，固定仓库 commit 3f39af1b38a9b6883064b3f79b6bb32661fa72af；本日发现旧项目，不冒称今日发布。

为什么值得深挖

MCP-Gateway-Runtime关注“工具被谁调用、什么数据可以发往哪里”；这里只把标签/策略加入 tools/list，再把策略求值暴露为一个可调用工具。能计算 deny 不代表在真正的 tools/call 上强制 deny；更关键的是策略求值本身可以调用远端工具，因而不是纯函数。 这给 Hermes/llm-wiki 的审阅流程一个可迁移问题：安全检查是否本身跨出原授权边界？相比contextforge-egress-path-parity-dns-rebinding聚焦出站地址，此处关注“读策略期间就已发生下游 effect”。

机制与证据层

每个 upstream 一个 FastMCP proxy、Starlette /mcp/<server_id>/ 路由；README 明确仅支持 HTTP。配置可给 upstream 静态 header、MSAL（默认磁盘 token cache）或 OAuth；没有证据证明按最终调用者分别隔离 token。PolicyMiddleware 在 tools/list 的 _meta 填入推荐 Rego；上游已有该 key 时上游优先。推荐值是描述性元数据，不是调用准入。固定 fastmcp_proxy.py 把 eval_policy 注册为与真实工具并列的 MCP tool，依赖 caller 显式调用；本轮没有找到所有实际调用路径的强制授权中间件证据。^[raw/articles/fides-gateway-readme-extracted-2026-10-01.md] ^[raw/articles/fides-gateway-proxy-3f39af1-extracted-2026-10-01.md]
eval_policy(call, policy?) 可接受 caller 提供的 Rego；省略时取当前配置的 per-tool / * 推荐策略，若均缺失则返回 MCP error。call._meta["com.github.ifc/labels"] 用 RFC 9535 单一路径给参数标注完整性与读者集合；显式→后代join→最近祖先→根回退。接收 caller 自述标签不等于真实出处可信；加入固定策略、可信标注和用户授权，才可能得到可强制的信息流门。
README 明说策略里的 upstream.<Tool>(args) 通过新建带原 upstream transport/credentials 的 MCP client，重新发现工具，并把 Rego 扩展转成真实下游 call_tool；固定 proxy 代码也把相同 transport 的 client factory 传入策略引擎。这意味着如果该工具对未受信调用者可达且 Rego/extension 未另设读能力白名单，“测试策略”可能执行写工具；即便最终 decision=false，也不能倒转已发生的 effect。这是基于架构的风险推论，非本机 exploit / 已证漏洞；实际安全性仍取决于 ingress 鉴权、下游凭据/权限、extension 暴露、策略限制和部署配置。^[raw/articles/fides-gateway-readme-extracted-2026-10-01.md] ^[raw/articles/fides-gateway-proxy-3f39af1-extracted-2026-10-01.md]
_meta 前缀转换顺序可影响后续策略看到的 label；主体映射可能一对多；serverInfo() 初始化失败时为 null 而不是受信身份证明。WorkIQ 标签器可为结果再调用 ListChatMembers，因此结果标注同样会多一次上游 I/O。不能把只读列表、实时成员、历史授权、执行时权限合并为一个快照。

Hermes / wiki 的最小验证合同

隔离 mock 上游提供只读 lookup 与可观察 write_counter，以无下游权限的匿名/cron/caller 三种主体测试：（a）不显式 eval 直接 tools/call 的 deny 是否被挡；（b）自定义策略内调用 upstream.write_counter 时拒绝后计数是否仍为零；（c）伪造 public label、缺 label、未知 principal、失效 credential 的有效结果；（d）日志里分别保留 policy-eval invoked / verdict / upstream-call happened / final-effect，并将 caller×backend credential owner×route 逐项核验。不能在真实邮箱/消息/业务系统用风险策略试探。

失败边界 / 与现有内容的关系

和bifrost-mcp-registration-control-plane-and-egress的注册即spawn相同，控制点前的“安全准备阶段”也可能产生真实 effect；与langchain-per-caller-connections-credential-ownership一样，持有 OAuth 不证明当前请求主体有权借用。README 的示例 default allow := true 不是安全默认实践；标签由客户端提交时要问谁签发和如何抗降级。本轮仅官方 README 文本抽取和固定文件的网页抽取，没有装 Rust/regorus、跑 suite、审全部 middleware，也不推断用户机器使用此原型；confidence: medium。

写入记录

2026-10-01 09:04 CST：归档README及固定 proxy 文本，区分策略建议/显式求值/实际强制执行；提出策略求值调用上游工具的负例验收与主体隔离边界。