Agent 靠什么碰企业数据
智能体在企业里的活动，绝大多数不是通过「点按钮」完成的，而是通过接口完成的。它读取工单系统、写入数据库、查询订单、触发审批，路径都是一次次 API 调用。近一年又多了一类：通过 MCP 服务器访问工具与数据。
这带来一个直接的治理难题。API 本身是企业既有资产，通常已经有台账、有网关、有权限体系；但 Agent 使用 API 的方式与传统应用不同——调用密度高、路径组合多变、且部分调用由模型在运行期决定。如果安全团队看不到「哪个 Agent 在调哪些 API、通过哪些 MCP 服务器」，这些连接就会成为影子 AI 与未监控数据外流的通道。
9 月 10 日，Akamai 与 MuleSoft 宣布扩展合作，把 Akamai 的 API 安全能力与 MuleSoft 的 Agent Fabric 打通，目标是让网络边界承担策略执行的角色，并覆盖 API、Agent 与 MCP 服务器三类对象。
为什么要做这件事：一组不太好看的数字
这次集成的时间点并非偶然。按 Akamai 的《2026 年 API 安全影响研究》，87% 的组织在 2025 年至少经历过一次与 API 相关的安全事件。这个比例说明，接口层早已是主要的攻击面之一，而 Agent 的普及只是在既有问题上叠加了新的使用方式。
双方给出的方案是一个双向反馈回路。一方面，MuleSoft Exchange 把 API 规格与环境数据同步给 Akamai，让安全侧知道自己要保护的对象长什么样。另一方面，Akamai 把行为分析与威胁风险分回灌到 MuleSoft 的控制面，让编排侧在做路由与调度时能带上风险信息。
这个「双向」是关键。单向集成只能做到「安全看见编排」或「编排看见安全」，而双向意味着两边共享同一份上下文：编排知道某个 API 当前风险偏高，安全知道某个 Agent 的业务意图是什么。按公开说明，这套集成已在超过 20 家联合客户中使用。
Agent Fabric 本身是 MuleSoft 在 2025 年 9 月推出的能力，定位是统一地发现、编排与治理 Agent，让多个 Agent 能在运行期互相发现，并按意图路由任务。它处理的是「谁来做这件事」，Akamai 补的是「这件事能不能做、做得安不安全」。两层的分工相对清晰。
标准拼图：三条线同时推进
把这次集成放进更大的背景里，可以看到标准侧有三条线在并行推进。
OWASP 的 Agent 控制标准聚焦运行期执行，关注的是策略如何在动作发生时生效。NIST 的 AI Agent 标准倡议聚焦身份与授权，关注的是 Agent 作为主体如何被识别与授权。Linux Foundation 下的 AAIF 关注互操作性，试图解决不同实现之间如何互通。
这三条线恰好对应了企业落地时最头疼的三个问题：策略在哪执行、身份怎么认定、系统之间怎么对话。厂商的集成动作，实际上是把这些还在成型的框架提前「跑起来」——用真实流量验证治理思路是否可行。
但这里也埋着一个结构性矛盾。标准仍在制定，产品已经上线；产品各自实现了一套策略模型，标准要解决的是统一。如果企业的治理配置深度绑定某一家厂商的实现，未来迁移到标准方案时的成本会很高。这是所有「标准未定、产品先行」阶段的共同风险。
被反复提到的那组研究结论
这次集成同时暴露了一个更深的问题。相关分析引用了加州大学伯克利分校的 MAST 分类研究（发表于 NeurIPS 2025），指出 79% 的多智能体失败可以追溯到规格问题，而不是模型能力或基础设施限制。
这句话的含义值得展开。行业当前在努力解决的是「怎么执行」——如何让策略在运行期生效、如何让调用可见、如何让风险可评分。但「执行什么」这一层，也就是用机器可读的方式精确定义 Agent 的行为边界，目前仍然分散在各家自己的实现里。
一个直白的推论是：如果规格本身是错的，再好的执行层只会更精确地执行一个错误。策略能拦住越权调用，但拦不住「这个任务从一开始就不该交给 Agent」这类判断。执行层做得越好，这个盲区反而越不显眼——因为系统看起来一切正常。
MCP 让这件事变复杂在哪
传统 API 有相对稳定的契约：接口定义、参数结构、权限范围、调用方身份，这些都有成熟规范。MCP 的出现改变了连接方式——它把「工具」变成模型可以在运行期选择的选项，服务器代表客户端执行动作，调用路径由模型在上下文里决定，而不是由开发者写死。
这个变化的价值很明显：接入新工具不再需要改代码，只要把服务器挂上去。代价同样明显：调用路径不再经过人工审查，权限判断必须从「这个应用能不能调这个接口」变成「这次调用在当下是否被允许」。行业此前的漏洞报告也印证了这一点，多款集成 MCP 的平台被披露存在高危问题，说明这个新连接层的实现质量参差不齐。
把 MCP 纳入统一的策略执行，是这次集成值得肯定的部分。但需要注意，策略能约束的是调用本身，而 MCP 服务器的行为是否可预测，取决于其实现方。企业引入第三方 MCP 服务器时仍需要独立评估，不能因为「已被网关覆盖」就降低审查标准。
中立思辨
需要辩证看待几件事。其一，集成带来的最直接收益是可见性，而可见性是必要不充分条件。把 API 与 MCP 调用纳入台账，能显著减少影子使用；但它不解决「这次调用是否符合业务规则」，也不解决「Agent 的意图是否被正确理解」。
其二，双向集成提高了效率，也提高了绑定程度。当规格数据、风险评分与控制面深度互通后，企业实际上把治理链路交给了两家厂商的组合。这在短期内降低了集成成本，长期看需要评估可替换性——尤其是当开放标准成熟之后。
其三，MCP 的安全面本身仍在补齐。行业报告此前披露过多款集成 MCP 的平台存在高危漏洞，这说明 MCP 服务器作为新的连接方式，其权限模型与实现质量参差不齐。把 MCP 纳入统一策略是正确方向，但前提是这些服务器的行为可预测。
其四，87% 这个数字来自厂商委托或参与的研究，统计口径与样本构成需要查阅原始报告核对。类似的市场调研数字常用于说明问题严重性，不宜直接外推到具体企业的风险水平。
其五，按公开说明，后续计划包括原生的 MuleSoft 接入能力与面向 AI 与 MCP 环境的运行期安全扩展，并将在 9 月 15 日至 17 日的 Salesforce Dreamforce 上做演示。演示与生产之间通常还有距离。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
给架构团队的四张表
把这次集成背后的思路翻译成可执行的准备工作，大致是四张表。
接口台账：企业内部有哪些 API 与 MCP 服务器，分别归属哪个业务系统，负责人是谁，最近一次安全评估是什么时候。这张表决定了后续所有策略的覆盖范围。
使用映射：哪些 Agent 在调用哪些接口，调用频率与时间分布如何。这张表能暴露「名义上没人用、实际上高频调用」的隐蔽连接。
风险分层：把接口按敏感度分层。读公开数据与写核心库不应共用一套策略，跨境数据流转与内部查询也不应共用。
责任归属：每个 Agent 对应哪个业务负责人，出了问题找谁。这张表在治理讨论里最容易被跳过，但它决定了事故发生时能不能快速止血。
把这四张表放在一起看，会发现一个共同点：它们都不依赖任何特定产品，用表格就能开始做。厂商能提供的是执行与可见性的自动化，而「企业里到底有多少东西在动、各自该被允许做什么」，仍然需要企业自己回答。