Pipelock 代理出站与泄密拦截

要解决的具体问题

当 Agent 被赋予工具调用能力并开始访问外部站点、MCP 服务或 IDE 集成链路时，它的网络边界往往比预期更宽。几个典型风险：

• 出站请求缺乏过滤，Agent 可能访问未预期的域名、协议或端口，绕过原本设定的允许清单。
• MCP 返回内容可能夹带指令，影响后续工具调用决策，形成间接的提示注入路径。
• 本地机密、环境变量、凭证或代码片段可能随输出或请求体离开环境，且难以追溯。

这些风险并非单纯依赖模型自身行为，而是由真实网络路径、工具参数、外部响应内容共同触发。只靠模型侧的系统提示很难完全覆盖。

技能如何工作

Pipelock 的思路是在 Agent 真正接触开放互联网之前，插入一层内联防火墙与隔离层。它不替换 Agent，而是在以下路径上做前置拦截：

• 代理网络流量：检查每一次出站请求的目标、协议与端口，决定放行或阻断。
• 工具调用链路：在 Agent 发起工具调用前后介入校验，防止参数携带越界内容。
• MCP 流量：对 MCP 交互内容做审查，降低提示注入通过响应内容回灌的风险。

核心流程可以拆成三步：

1. 配置策略：通过 pipelock.yaml 定义允许/阻断规则，明确哪些出站目标可信。
2. 前置校验：在请求发出前执行检查，例如用 pipelock check --url 验证目标是否在允许范围内。
3. 拦截与隔离：未通过校验的请求被阻断，避免 Agent 直接把机密或上下文带出边界。

适用边界与注意点

这套方案适合作为 Agent 访问外部世界前的第一道防线，但它并非万能：

• 策略配置质量直接决定拦截效果，过于宽松的规则等于没开。
• 它不能替代对 MCP 服务本身的安全审计，上游服务被攻破时仍需额外兜底。
• 对已经授权放行的流量，内部内容二次污染仍需结合日志与运行时监控。

实践中建议把它与最小权限原则、机密管理策略配合使用，形成多层防护。