在本系列的最后两部分中，我介绍了 模型上下文协议如何映射到货运 API，然后是 拆除了 2026 年出货的货运 MCP 服务器。两者都以同样悬而未决的问题结束，因此本部分直接回答了这个问题：一旦代理能够预订实际的货物，您如何阻止它为错误的人预订错误的东西？安全是货运 MCP 服务器停止看起来像开发者的玩具并开始看起来像一个处理金钱和卡车的系统的地方。
我在一个提供 API 的市场运营，所以我的观点是基于实践而非学术的。以下威胁是我在决定代理可以不经人工干预而调用哪个工具时真正建模的。
为什么货运服务器会提高风险
一个通用的 MCP 服务器在你失败时会泄露信息。一个预订货物的货运服务器会造成更严重的后果。一个糟糕的指令可能会导致卡车被派往错误的场地，在运送中的货物上更改收货人，取消客户寄予厚望的预订，或者拉出一个本不该从账户中导出的提货单。这些并非数据泄露的错误。它们是收款凭据和实体货物在无人键入指令的情况下正常运行。
这个差异重新定义了整个问题。使用聊天助手，最坏的情况就是给出令人尴尬的答案。涉及货运，最坏的情况就是附带一张货运账单，并且货物被运到了不该去的地方。因此，问题从来不是抽象意义上的“这个服务器安全吗”。而是“代理可以采取哪些具体行动，以及每项行动如果出错的成本是多少。”
最值得担心的两种故障模式
2026年大多数MCP风险将归结为两种模式，而货运会使这两种模式都变得更糟。
提示注入是穿着新衣的旧网络问题。代理从它无法完全控制的地方读取文本，例如运单、PDF、电子邮件正文，而这些文本包含模型会遵循的指令。在货运领域，被“投毒”的文本通过合法渠道全天候到来：订舱评论、报关描述、承运商的状态更新。如果您的订舱工具信任模型传递的任何内容，那么隐藏在送货单中的一句话就可能导致实际的取消。
**工具投毒** 更加隐蔽，并且是 MCP 特有的。该协议允许服务器描述其自身的工具，然后代理会读取这些描述来决定调用哪个工具。恶意或受损的服务器可以编写一个描述，悄悄地指示模型窃取 API 密钥或重新路由货物，而用户永远不会看到这些文本。Anthropic 和独立研究人员在 2026 年初记录了这种变体，对货运行业的教训是明确的：描述层是可执行的，因此应像对待第三方代码一样，同样怀疑地对待第三方工具描述。
读取与写入：决定您授权的界限
我做出的最有用的一个安全决定是停止将“MCP 服务器”视为一个信任边界，而是根据每种工具对世界的作用来划分它。
什么可以保持开放
报价航线、列出运力、计算过境估算、查找港口代码。这些都不会改变任何事情。让代理人能够几乎无阻碍地联系到他们，这才是重点，也是日常价值所在。想要比较三条航线的读者，不应该被迫铸造一个代币才能做到。在拆解的服务器中，严肃的那些之所以保持低摩擦的报价和参考工具，正是出于这个原因。
什么必须被限制
预订、取消、更改收货人、编辑地址、提取文件，任何与发票相关的事项。这些操作中的每一个都会写入真实世界，并且每一个都需要一个经过身份验证、授权和可审计的调用。我们遵循的规则很简单，但很难执行：读取工具可以是开放的，写入工具则绝不是。
OAuth 2.1 和 PKCE，不是配置文件中的长效密钥
MCP 授权规范为远程服务器选择了 OAuth 2.1，这一选择对于货运业具有实际意义。将静态 API 密钥粘贴到配置文件中对于在自己的机器上通过 stdio 运行服务器的独立开发者来说是没问题的。但只要服务器可以通过 HTTP 访问，并且某个代理代表共享账户内的某个命名用户进行操作，这就不是一个合适的模型。
有三个重要的属性。作用域（Scoped）令牌意味着为引用而生成的令牌无法用于预订。短暂（Short-lived）令牌意味着泄露的凭证会自动过期，而不是永远保留在日志中。可撤销（Revocable）令牌意味着当出现异常情况时，您可以立即撤销访问权限，而不是像轮换共享密钥那样，让每个人都依赖它。OAuth 2.1 还要求在授权码流程（authorization-code flow）中使用 PKCE，这弥补了早期 OAuth 部署遗留的拦截漏洞。这一切并非前沿技术。这只是任何支付 API 在代理说“预订”的那个时刻所采用的相同加固措施。
这就是我们强制执行的边界的形状，写成我希望每个货运服务器都发布的表格。
| 代理行动 | **读写** | 身份验证要求 | 万一出错 |
| 获取报价 | 阅读 | 开放式或基础密钥 | 白打的电话，没造成伤害 |
| 检查容量、中转、追踪 | 阅读 | 开放式或基础密钥 | 最差的也是过时的答案 |
| 预订货件 | 写 | 作用域 OAuth token，确认步骤 | 真实价格，真实卡车 |
| 取消或重新预订 | 写 | 作用域令牌，幂等键 | 丢失时段，处罚 |
| 更改收货人或地址 | 写 | 作用域令牌，人工确认 | 误送，欺诈 |
| 拉取提单或发票 | 读取敏感信息 | 作用域令牌，每份文档检查 | 数据和文件泄露 |
该表中的模式是实际的产品决策。读取位于左侧，价格便宜。写入位于右侧，并会因其摩擦力而产生收益。
公开实例问题
令人惊讶的是，MCP 风险的很大一部分根本不巧妙。它是一个本该本地运行的服务器，但由于以这种方式发布更简单，而被暴露在开放的互联网上，并且没有进行身份验证。该协议支持两种传输方式。stdio 服务器作为一个本地进程运行，由客户端启动，这使得它保留在您的机器上，而不是在网络上。托管的 HTTP 服务器则可以被任何能够找到其 URL 的东西访问。
对于一个只读的实用服务器来说，HTTP暴露几乎没有危害。而对于一个带有预订工具的服务器来说，它就是一切。如果你的写入工具可以通过公共HTTP访问，那么认证不是你之后添加的功能，它是陌生人和你的调度队列之间的屏障。我们的规则是，预订和文档工具绝不能通过未经身份验证的HTTP端点提供服务，这一点是绝对的。如有疑问，一个具有写入能力的服务器应该默认使用stdio和本地启动，并且只有在上述OAuth流程到位后才能升级为主机HTTP。
抵御描述层免受工具投毒攻击
因为工具的描述会引导模型，所以它们值得受到与你部署的代码相同的控制。养成三个习惯就能涵盖大部分的风险。
- **钉住并评审您连接的服务器。** 连接到一组经过精心挑选的已知服务器的代理比安装注册表中任何内容的代理目标更小。将新服务器视为新的依赖项，因为它本身就是。
- 每次写入都要有人工审核。 在预订、取消或更改收货人之前进行确认，可以将静默注入的指令转变为用户可以拒绝的可见请求。这是成本最低、回报最高的控制方式。
- **在 API 中验证，而不是在提示中验证。** 服务器应重新检查其接收到的每个参数与账户的真实权限和预订的真实状态，而不是相信模型组装了一个明智的调用。模型提出建议，API 做出决定。
一个市场服务器需要强制执行什么，才能让单个运营商可以跳过
单载波服务器仅在其自己的网络上运行，因此其影响范围仅限于一个运营商。而市场服务器则代表许多用户在多个运营商之间进行报价和预订，这从两个方面改变了安全工作。
首先，范围必须是每个用户和每个运营商，而不是每个服务器。允许代理与一个运营商预订的令牌不应默默地触及另一个运营商，并且一个客户的代理绝不能看到另一个客户的文档。其次，审计跟踪更加重要，因为当代理在市场上进行预订时，您需要针对每次写入回答“哪个用户、哪个令牌、哪个运营商、什么时间”。我们将该日志视为产品的一部分，而不是事后诸葛亮，因为它使我们能够进行细粒度的撤销，而不是关闭所有人的访问权限。
预订上线前的实用清单
- 将工具按读写分开，并将划分结果写在代理和您的团队都能看到的地方。
- 保持引用和参考工具的低摩擦性，以确保日常价值得以延续。
- 为每一次写操作提供一个作用域受限、生命周期短暂、可撤销的、支持 PKCE 的 OAuth 2.1 令牌。
- 预订、取消、收货人及地址变更都需要确认步骤。
- 重新验证 API 中的每个参数，检查其真实权限和实际的货运状态。
- 切勿通过未经验证的 HTTP 提供写工具，并默认将写能力服务器设置为本地 stdio。
- 固定代理连接到的服务器，并像审查新代码一样审查新的服务器。
- 记录每次写入，包括用户、令牌、载体和时间，并在需要之前演练撤销。
这些都不是人工智能独有的。它们是货运和支付已经在使用的控制，指向了一个可以发出指令的新地方。代理是一个新调用者，而不是一套新规则。
常见问题解答
让 AI 代理预订货运安全吗？
是的，预订发生在经过身份验证和授权的调用之后，并且有一个确认步骤，并且服务器会重新检查每个参数，而不是信任模型。不安全的版本是一个开放的写入工具，没有人机交互。将预订视为任何其他涉及资金的操作，代理将成为另一个经过身份验证的调用者。
为什么使用 OAuth 2.1 而不是简单的 API 密钥？
静态密钥通常是长期有效、作用范围广且难以吊销，否则会影响所有共享它的人。OAuth 2.1 提供了具有作用域、短期有效、可吊销的令牌，并要求在授权流程中使用 PKCE。对于本地 stdio 服务器，密钥是可以接受的，但任何可通过 HTTP 访问且可以写入的内容都应使用 OAuth 模型。
MCP 中的工具投毒是什么？
工具投毒是指服务器的工具描述（代理阅读该描述来决定调用哪个工具）包含隐藏的指令，这些指令会诱导模型执行有害操作，例如泄露密钥或重新路由运输。由于描述会影响行为，您应该像防御代码一样防御它：固定受信任的服务器、由人工进行写入操作，并在 API 层面进行验证。
货运 MCP 服务器应该作为 stdio 运行还是托管 HTTP 运行？
一个只读的实用程序服务器通过托管的 HTTP 运行是没问题的。而一个带有预订或文档工具的服务器，应该默认使用本地 stdio，并且只有在设置了范围限定的 OAuth 之后，才移至托管的 HTTP，因为一个暴露的写入端点如果没有进行身份验证，任何找到该 URL 的人都可以访问。
这为本系列开头铺平了道路。如果您还没有阅读早期部分，协议入门 解释了货运 API 如何成为一套工具，而 拆卸 则展示了已发货的服务器在实践中是如何划定这些界限的。