当企业讨论 AI 落地时，最先被摆上台面的通常是效率、成本和业务创新。客服能不能自动回复，研发能不能提效，知识库能不能被调用，工单能不能自动流转，销售、财务、HR 能不能接入大模型工具。
但在这些问题背后，还有一个更基础的环节：API。
近日，Akamai 北亚区技术总监刘烨在一次公开分享中提到了该公司关于 API 安全的调研结果。相比传统安全报告中常见的漏洞、攻击流量、DDoS 等话题，这份报告更值得关注的地方在于，它把 API 安全和 AI 应用放到了一起讨论。
原因并不复杂。无论是大模型、AI Agent，还是接入了大模型能力的智能客服、聊天机器人、企业知识库和业务系统，本质上都需要通过 API 与数据、系统、外部工具发生交互。过去，API 更多是系统之间的接口；现在，它正在成为 AI 调用企业能力、触达内部数据、执行任务的通道。
换句话说，AI 能不能真正进入企业工作流，很大程度上取决于 API；而 AI 一旦被攻击者利用，风险也很可能沿着 API 扩散。
根据 Akamai 披露的亚太专题调研数据，过去 12 个月里，81%的亚太地区受访企业遭遇过 API 安全事件；在各类 API 安全攻击中，43%的攻击针对 AI 应用、大语言模型相关 API；亚太地区每一起 API 安全事件造成的平均经济损失超过 100 万美元，其中日本企业损失均值最高。
这组数据至少说明两件事。第一，API 安全已经不是少数技术团队内部的问题，而是会造成实际经济损失的企业风险。第二，AI 相关 API 正在快速进入攻击者视野。
刘烨提到，在亚太地区常见的 API 安全事件类型中，AI 相关 API 攻击排在前列。其后还包括权限控制缺失或不足、数据泄露、未受管理的 API，以及 API 错误配置。
这些风险本身并不新。比如越权访问一直是 API 安全中最常见的问题之一，攻击者可能只是修改 URL 参数、Token 值或对象 ID，就能看到不属于自己的数据。数据泄露也并不罕见，API 在返回信息时，可能把敏感字段一并带出。Shadow API、僵尸 API 则来自开发和运维流程中的失控：曾经上线、内部使用、无人维护或没有纳入统一管理的接口，最终都可能成为攻击入口。
不同的是，AI 把这些老问题放大了。
传统云应用中，API 调用大多来自人的明确操作。用户查订单、订酒店、购买商品、提交表单，路径相对清楚。AI Agent 进入后，调用链路变长了。用户不一定直接操作系统，而是向 Agent 描述目标，由 Agent 判断该调用哪些工具、访问哪些接口、读取哪些数据，甚至进一步触发外部应用。
这会带来一个直接后果：企业很难再只用过去的方式理解“访问主体”。过去是人访问系统，现在可能是人授权 Agent，Agent 再调用多个 API。攻击者未必直接攻击模型本身，也可能诱导 Agent 使用已有权限去访问不该访问的数据，或者执行不该执行的操作。
这也是 AI 时代 API 安全和传统 API 安全最大的区别之一：攻击边界更模糊，权限控制更复杂，风险链条更长。
刘烨在分享中提到，传统应用的身份认证和权限分配，通常围绕用户身份展开；而 AI Agent 的权限边界更难把握。它到底能访问哪些接口，能拿到哪些数据，能否跨系统执行操作，权限应该是一次性、短期、受限，还是长期有效，这些问题都比过去更复杂。
更麻烦的是，很多企业连自己的 API 资产都没有完全摸清。
报告中有一个数据值得警惕：能够清晰掌握 API 资产盘点的受访者比例平均只有约 20%。也就是说，大量企业并不知道自己到底开放了哪些接口，哪些接口可以被外部调用，返回的数据是否包含敏感信息，是否存在未被纳管的影子 API。
在这种情况下接入 AI，就像在一栋楼里安装了自动通行机器人，却没有完整门禁清单，也不清楚哪些房间放着敏感资料。AI 提升效率的同时，也可能扩大原有安全盲区。
MCP 的出现，让这个问题进一步复杂化。
随着 Claude、各类企业 AI Agent 和内部工具连接需求增加，MCP 这类模型上下文协议开始被更多开发者和企业关注。它的价值在于，让模型、工具、数据源之间的交互更加标准化。但标准化并不意味着天然安全。企业未来不只要识别 Shadow API，还要识别影子 MCP 服务器、未经批准的 Agent，以及 Agent 在访问内部工具时是否发生越权。
从这个意义上说，AI 没有改变 API 攻击的最终目标。攻击者仍然想窃取数据、越权访问、操控业务逻辑。但 AI 改变了攻击路径：过去攻击者直接找接口漏洞，现在可能利用 Agent 的权限、上下文和工具调用链路，把合法访问变成非法操作。
这也解释了为什么仅靠传统 WAF 或网关已经不够。
WAF 对特征类攻击、速率攻击、部分已知攻击模式仍然有价值，但它并不擅长识别业务逻辑漏洞、权限滥用、敏感数据泄露和凭证失效等问题。比如一个请求从协议和格式上看完全合法，但它访问了不该访问的数据，或者通过 Agent 的上下文绕开了原有业务限制，传统边界防护就很难判断。
刘烨认为，企业需要从单纯“安全防护”走向“安全治理”。这意味着，API 安全不应该只在系统上线后被动防御，而要覆盖全生命周期。
第一步是资产盘点。企业需要持续发现所有 API，尤其是 AI 生成代码、快速迭代业务和内部工具带来的新增接口。没有可视性，就谈不上防护。
第二步是态势管理。企业要知道 API 是否存在配置错误、授权问题、敏感数据暴露风险，哪些接口返回个人信息、财务数据或业务核心数据。
第三步是运行保护。系统上线后，需要建立访问行为基线，区分正常调用、异常调用和潜在攻击。AI 场景下，人工访问和 Agent 访问最好分别建模，因为二者行为模式不同。
第四步是主动测试。安全测试要前置到开发和测试阶段。无论代码由人写，还是由 AI 生成，都需要经过 API 安全审计和自动化测试。AI 可以加快开发，也会加快漏洞进入生产环境的速度。
这套思路并不新，但在 AI 场景下紧迫性更高。因为 AI 正在加快企业系统变化速度，也在增加 API 数量和调用频次。过去一个研发团队慢慢写接口，安全团队还有时间跟进；现在 AI 可以批量生成代码、快速搭建应用，如果测试和治理体系没有同步自动化，安全团队会很难跟上。
值得注意的是，中国企业在这份调研中的表现相对更好。沟通会披露的数据显示，亚太地区 API 安全事件平均发生率为 81%，中国为 63%，在中国、印度、日本、新加坡四个调研国家中最低。刘烨解释称，这与国内企业安全测试体系相对完善有关，58%的中国企业已将安全测试深度融入开发全流程。同时，国内移动应用发展成熟，企业对 API 交互模式更熟悉，也更常态化地开展 OWASP API 风险检测、红蓝对抗和模拟恶意流量测试。
但这并不意味着国内企业可以放松。因为 AI 应用接入核心业务的速度，可能比安全治理成熟的速度更快。
一个典型矛盾是：业务团队急着让 AI 接入客服、研发、知识库、工单系统和内部工具，安全团队却未必掌握 AI 背后到底连了哪些接口、能拿到哪些数据、是否存在越权路径。企业一边希望 AI 更有用，一边又需要限制 AI 不能“太有权限”。如何在效率和安全之间找到边界，会成为接下来企业落地 AI 的关键问题。
Akamai 给出的答案，仍然回到 API 全生命周期治理。其 API Security Solution 主要覆盖持续发现、态势管理、运行保护和主动测试四个环节。针对 AI 场景，Akamai 也在加入对 MCP 服务器发现、Agent 访问行为监测、越权行为识别等能力。
此外，Akamai 近期宣布拟收购 LayerX，后者提供基于浏览器的 AI 使用控制和安全企业浏览器技术，方向是管控员工使用大模型时的访问行为、提示词内容和数据上传行为。
不过，对企业来说，采购某个工具并不等于 API 安全问题自动解决。真正困难的地方，仍然在组织和流程。
报告中提到，管理层与技术团队之间存在认知偏差。高管往往更关注总体战略、合规和预算，可能认为公司已经具备较强安全能力；一线安全和开发安全团队则更清楚接口迭代、影子 API、权限漏洞和真实攻击压力。刘烨提到，要缩小这种偏差，需要统一风险评估标准，建立基于 OWASP API 风险、红蓝测试和自动化工具的客观指标，并把安全风险与业务目标绑定。
这点对 AI 尤其重要。很多企业上 AI 时，最先看到的是效率提升；安全团队看到的，却是更复杂的访问路径、更模糊的授权边界和更难控制的数据流向。如果管理层只看到前者，看不到后者，AI 项目推进得越快，潜在风险积累也越快。
从行业角度看，AI 时代 API 安全的核心变化，不在于攻击者突然有了全新的目标，而在于企业系统的连接方式发生了变化。AI Agent 让接口调用从“人点按钮”变成“模型替人执行任务”；MCP 等协议让模型和工具的连接更标准，也让新的资产类型出现；AI 生成代码让开发提速，也让安全测试必须更早、更自动化地介入。
因此，API 安全不再只是应用安全团队的局部工作，而会成为企业 AI 治理的一部分。
未来企业要回答的不是“要不要接入 AI”，而是接入之后，AI 能访问什么，不能访问什么；哪些数据可以被调用，哪些必须隔离；Agent 的行为如何监控，越权如何发现；AI 生成的新接口如何测试；出海业务面对不同地区法规，如何把合规要求变成可执行的技术规则。
AI 提高了企业调用系统和数据的能力，也同步提高了攻击者利用这些能力的可能性。
这正是 API 安全在 2026 年重新被放到台前的原因。
