GATRA：面向 MCP/Agent 轨迹的零信任安全代理
GATRA：面向 MCP/Agent 轨迹的零信任安全代理
一句话结论
GATRA 把 MCP/API 工具调用放进一个零信任反向代理：Ed25519 capability token、CEL policy、schema auto-discovery、trajectory spending caps、rate limits、dry-run audit 和 Prometheus telemetry 共同组成 agent runtime 的可执行控制面。
为什么对用户重要
用户短期雷达正在提高 MCP gateway / runtime / control plane 权重。GATRA 的新意是把“每次工具调用是否允许”扩展成“整条 trajectory 是否仍在预算、策略和任务约束内”。这正好对应 Hermes 长期 loop 的核心风险：单步看似安全的调用，组合后可能越权、超预算或造成隐性外部副作用。
机制 / 一阶原理
GATRA 位于 agent orchestrator 与 downstream API/MCP tool 之间。agent 请求必须携带短期 capability token；proxy 用公钥验证 token，再用 CEL policy 检查 payload、路径、参数、注入风险和 forbidden transition。X-Gatra-Directive 允许每个任务临时收紧约束，但不能放宽全局 policy ceiling，即 Monotonic Restriction Principle。
最值得迁移的是 trajectory-level accumulator：预算、速率、风险不应只按单次 request 判断，而应随 session 累积。例如“每次支付不超过 30 美元”不等于“整个任务可无限支付 30 美元”。
与已有概念的关系
- 对 MCP-Gateway-Runtime：补充 data-plane policy enforcement 与 cryptographic capability token。
- 对 Harness-Engineering：把 deterministic gate / action boundary 变成代理层可执行程序。
- 对 Agent-Benchmarks：dry-run/audit mode 可用于评测 gate firing，而不是上线后才发现策略过严或过松。
可执行启发
- Hermes 工具调用 ledger 应记录 trajectory_id、job_id、capability、policy verdict、累计成本/风险。
- 对高风险工具引入 monotonic directive：用户或任务可以收紧权限，不能在无人 loop 中自行放宽。
- 新 MCP server 接入时先 auto-discover schema，生成 baseline allow/deny policy，再人工 review。
- 在正式 block 前使用 dry-run/audit mode 收集 false positive/false negative 样本。
失败模式 / 边界
- README 层面可见机制强，但本轮未验证实现完整性和真实性能。
- CEL policy 能表达很多规则，但复杂 policy 可能出现维护债和绕过路径。
- schema auto-discovery 只能提供 baseline，不能替代领域语义和业务风险建模。
- trajectory cap 若没有可靠 identity/session 绑定，可能被拆分任务绕过。
深度判断
本轮晋升为正式 source 页，因为它命中 MCP/runtime/control-plane 与 benchmark integrity 双主题，且提供 capability token、monotonic restriction、trajectory cap、dry-run audit 等可迁移机制。
写入记录
- 2026-08-28 09:00 CST：新增 GATRA 分析，提炼 capability token、CEL policy、trajectory-level caps 和 dry-run audit 对 Hermes MCP 工具治理的启发。