上个月，我目睹了一名开发者在不到四小时的时间内因欺诈性条纹支付（Stripe）扣款损失了 12,000 美元。他们甚至没有成为复杂黑客组织的目标；他们的目标是那些抓取公开吉特哈布（GitHub）提交的自动化机器人。这位“攻击者”是一个人工智能代理，其任务是为一个代码仓库快速添加功能，而在急于提供帮助的过程中，它将应用程序接口（API）密钥硬编码到了配置文件中。
当这名开发者意识到发生了什么并试图从最新的提交中删除该行时，损害已经造成。该密钥永远留在了吉特（Git）历史记录中。机器人已经找到了它。这就是软件工程的新现实：我们通过模型上下文协议（MCP）赋予大型语言模型（LLM）“双手”，使它们能够接触、操作我们的应用程序接口（API）并修改我们的基础设施。但是，如果我们不赋予它们进行安全推理的能力，我们不仅仅是在自动化开发，更是在自动化灾难。
目前，行业对防御层面的关注点出现了偏差。每个人都在谈论更好的扫描工具——声纳队列（SonarQube）、斯尼克（Snyk）、吉特哈布高级安全（GitHub Advanced Security）。这些工具在代码编写并推送之后捕捉模式方面表现出色。但它们是被动的。它们在持续集成/持续部署（CI/CD）流水线中运行，通常在开发者（或代理）成功将漏洞合并到主分支后的几分钟甚至几小时内。
当你使用克劳德（Claude）或光标（Cursor）配合模型上下文协议（MCP）服务器时，“开发者”不再只是一个以每分钟 80 个单词速度打字的人类；它是一个能够在几秒钟内重构整个模块的代理。如果该代理能够编写代码，它也能比任何以人为中心的代码检查规则更快地编写出不安全的代码。我们需要将安全关口从“构建后扫描”阶段转移到“编码前推理”阶段。
这就是我构建安全审计证明器模型上下文协议（MCP）服务器的原因。它不是一个扫描器。如果你希望有人检查你的编译二进制文件或已部署的容器，请使用专门的工具。证明器是一种强制机制，旨在在人工智能代理接触你的文件系统之前，审计其意图和策略。
“信任”代理的问题
在我构建 MCPFusion 时，我注意到了一个反复出现的模式：代理倾向于默认选择阻力最小的路径。如果你要求代理实现一个读取用户提供路径的功能，它的第一反应往往是直接将该路径传递给文件系统调用，因为“这是一个内部工具，我们信任我们的用户。”
这种心态正是路径遍历攻击发生的原因。无论应用程序是否是内部的，一旦攻击者攻陷了一个低权限服务，他们就会利用这些“受信任”的路径在你的基础设施中层层渗透。
安全审计证明器通过强制代理针对五个特定的决策维度验证其实现来工作。它使用一个结构化推理引擎，拒绝任何未提供明确安全策略证明的配置。
代理安全的五大支柱
如果你使用代理来构建功能，你不能简单地假设它知道开放网页应用安全项目（OWASP）十大安全风险。你必须强制它在这五个关键点上证明其工作：
1. 输入清洗（信任问题）
代理可能会告诉你，“我已经检查了输入格式。”这是一句毫无意义的话。证明器拒绝模糊的声明。它要求提供如何清洗输入的证据。你是否使用 DOMPurify 处理超文本标记语言（HTML）？是否有针对长度和字符集的正则表达式约束？对于文件上传，你是对白名单中的多用途互联网邮件扩展（MIME）类型进行限制，还是仅仅信任文件扩展名？代理必须证明它假定所有输入——从请求头到查询参数——都是恶意的。
'n#### 2. 密钥管理（吉特历史记录问题）
正如我提
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
