AI Agent 如何保护 API 和工具调用安全？

为什么 Agent 让传统 API 安全模型失效

传统 Web/API 防护建立在三个隐含假设上：调用者是人类操作 UI、权限在登录时一次性确定、请求之间彼此独立。Agent 三条都不满足：

1. 自主循环：一次用户指令可能触发几十次工具嵌套调用，请求之间有因果链，单点规则看不出异常。
2. 凭据常驻：为实现自动化，Agent 通常长期持有 API Key 或 Token，一旦上下文或被注入内容泄露，凭据有效期内的损失难以收束。
3. 间接提示注入：攻击载荷不一定来自用户输入，也可能藏在 Agent 读取的网页、文档、邮件或工具返回值里——等你发现异常时，动作已经执行。

落地框架：五层防护

第一层：工具清单与最小权限。 先显式登记 Agent 能调用哪些工具、每个工具能读写哪些数据、是否涉及资金或不可逆动作。没有登记的工具一律不可见，宁可减少能力也不要「默认全开」。

第二层：每次调用的双向 Schema 校验。 入参必须符合契约（防注入式参数篡改），返回值也必须符合契约。Cloudflare API Shield 的 Schema validation 与 mTLS 可以把「不是我登记过的调用形式」挡在边缘，用来兜住工具调用接口的边界。这里的重点是：不要只校验入参，工具返回的数据同样要当成不可信输入再做一次校验与清洗，因为那正是间接注入进入上下文的通道。

第三层：按工具维度限流与配额。 不同工具风险差异极大：查天气可以每天几千次，转账接口可能每天只允许几次且必须人工确认。Cloudflare Rate Limiting rules 可按路径、JWT 声明或正文字段计数，把「工具名/危险等级」作为计数维度，避免 Agent 在一个循环里把昂贵或高危工具打爆。

第四层：全链路可回放审计。 记录每次工具调用的完整上下文：用户指令、模型推理出的调用意图、入参、返回值、以及当时是否已通过人工确认。审计不是为了事后追责，而是为了在出事前能回放并定位漏洞链。

第五层：LLM 侧观测与成本控制。 Cloudflare AI Gateway 可以对通向模型厂商的请求做统一日志、限流、缓存和成本观测，把「Agent 调了多少模型、花了多少钱、命中率多少」变成可治理指标，而不是黑盒账单。

工具权限矩阵建议

工具类型	数据范围	是否需要人工确认	默认配额
只读查询（搜索、取数）	限定索引/租户	否	每会话数千次
内部只读（CRM/工单读取）	按租户隔离	否，但记录	每会话数百次
外部写操作（发邮件、发消息）	白名单收件域	是	每会话个位数
资金/订单变更	单次金额上限	是且二次确认	每日极少次
基础设施操作（改配置、部署）	仅预发环境	是	默认禁用生产

边界与不适用情况

• 网络层产品（WAF、限流、API Shield）不能替你做业务授权决策。它们能确认调用形式合法、来源可信、频率正常，但「这次转账是否应该发生」属于应用层必须保留的判断。
• 完全无人值守的高危场景请谨慎：即使做了全链路测试，LLM 的非确定性意味着「偶尔会做出计划外的调用」。涉及资金和用户不可逆数据时，人在回路不是可选项。
• 多 Agent 协作会放大权限蔓延：子 Agent 继承了父 Agent 的凭据，跨 Agent 调用链可能造成越权组合。应为每个 Agent 单独签发凭据，而不是共享一把万能 Key。

常见问题

有了 Schema 校验还需要限制工具数量吗？ 需要。Schema 校验保证「调用形式正确」，但无法判断「是否应该开放这个能力」。过度丰富的工具集会让模型在遇到歧义时更容易选错，安全和稳定性都更差。

间接提示注入怎么防？ 三层组合：对工具返回值做契约校验与清洗（去掉指令类内容）、在拼上下文前对外部内容做隔离标注、以及高危动作必须人工确认。指望单次过滤彻底解决是不现实的。

Agent 的 API Key 怎么管？ 一个 Agent 一把 Key，权限收敛到它的工具清单；Key 绑定来源（mTLS 或 IP 段）；结合 AI Gateway 的用量日志做异常行为告警，密钥轮换自动化。

mTLS 对 Agent 有意义吗？ 有。它在传输层把「调用来源」绑定到证书而不是可复制的字符串，是解决凭据泄露和伪造来源的基础设施手段，值得和 Schema 校验一起部署。