AI 应用正在改变传统安全边界。一次请求不再只是“用户访问接口”，它可能触发智能体调用数据库、执行工具、生成代码，甚至继续访问其他服务。Cloudflare 提出的自适应安全框架，核心思路是把风险发现、智能体治理、运行时保护和 AI 驱动的响应连接起来，让防御策略在持续反馈中更新，而不是依赖一组长期不变的静态规则。
为什么只保护入口已经不够
传统 Web 安全通常围绕入口流量展开：识别恶意 IP、拦截注入、限制请求频率。这些机制仍然重要，但 AI 智能体带来了新的执行链：
用户请求
-> 模型理解意图
-> 智能体选择工具
-> 工具访问数据库或外部 API
-> 模型整理结果并返回
攻击可能发生在任何一环。提示词注入可以诱导智能体选择高权限工具；被污染的外部内容可能改变模型行为；看似正常的单次请求，也可能在连续工具调用后造成数据泄露。
因此，自适应防护需要同时回答三个问题：
- 代码有什么风险：依赖、配置、密钥和权限是否暴露了攻击面。
- 流量正在做什么：请求来自谁，访问了什么资源，行为是否偏离基线。
- 运行时准备执行什么动作：智能体选择了哪个工具，参数是什么，影响范围有多大。
只有将这些上下文汇合起来，系统才能区分“用户查询订单”和“智能体批量导出客户资料”之间的风险差异。
四个环节必须形成反馈回路
这套框架可以理解为一个持续运转的闭环，而不是四个相互隔离的安全产品。
1. 风险发现
风险发现覆盖代码、依赖、配置和对外暴露面。发现结果不应停留在扫描报告里，而应进入运行时策略。例如，某个接口刚被识别为包含敏感数据，它随后收到的访问请求就应接受更严格的身份检查和速率限制。
2. 智能体治理
智能体治理关注的不是模型“说了什么”，而是它“能够做什么”。治理策略至少应描述：
- 哪个智能体可以调用哪些工具；
- 哪些操作必须获得人工批准；
- 可读取的数据类别和租户范围；
- 单次任务允许的调用次数、成本和执行时间；
- 每次工具调用如何记录和追踪。
智能体身份也不应与终端用户身份混在一起。一次操作最好同时保留用户、智能体、模型版本和工具身份，便于审计责任链。
3. 运行时保护
运行时是做出最终决定的位置。防护层可以结合身份、请求内容、资源敏感度、历史行为和威胁情报，返回允许、拒绝或要求人工确认。
关键点是把控制放在工具调用之前，而不是等模型输出结果后再检查。对于转账、删除资源、执行代码等不可逆操作，事后检测通常已经太晚。
4. AI 驱动的响应
AI 可以帮助聚合同类告警、解释异常调用链并提出策略调整建议，但不意味着所有响应都应自动执行。封禁账号、修改生产策略或隔离关键服务等高影响动作，仍需确定性的边界、审批和回滚机制。
有效闭环应类似：
发现风险 -> 更新上下文 -> 运行时决策 -> 记录结果
^ |
+------- 情报分析与策略优化 <-------+
可以这样实践：在工具调用前增加授权网关
下面是一个简化、厂商中立的示例，用来展示智能体如何在调用工具前请求策略决策。它不是 Cloudflare 产品 API，而是可以改造成内部授权服务的最小项目。
先创建 policy.json：
{
"blocked_tools": ["shell.exec"],
"sensitive_resources": ["customer_pii", "payment_records"],
"risk_threshold": 70
}
再创建 app.py：
import json
from http.server import BaseHTTPRequestHandler, HTTPServer
with open('policy.json', encoding='utf-8') as f:
POLICY = json.load(f)
def authorize(event):
tool = event.get('tool', '')
resource = event.get('resource', '')
risk_score = int(event.get('risk_score', 0))
if tool in POLICY['blocked_tools']:
return {'decision': 'deny', 'reason': 'tool is blocked'}
if resource in POLICY['sensitive_resources']:
return {'decision': 'review', 'reason': 'sensitive resource'}
if risk_score >= POLICY['risk_threshold']:
return {'decision': 'review', 'reason': 'risk threshold exceeded'}
return {'decision': 'allow', 'reason': 'policy checks passed'}
class Handler(BaseHTTPRequestHandler):
def do_POST(self):
if self.path != '/authorize':
self.send_error(404)
return
length = int(self.headers.get('Content-Length', '0'))
try:
event = json.loads(self.rfile.read(length))
result = authorize(event)
body = json.dumps(result).encode()
self.send_response(200)
self.send_header('Content-Type', 'application/json')
self.send_header('Content-Length', str(len(body)))
self.end_headers()
self.wfile.write(body)
except (ValueError, TypeError, json.JSONDecodeError) as exc:
self.send_error(400, str(exc))
HTTPServer(('127.0.0.1', 8080), Handler).serve_forever()
启动服务并发送一次授权请求：
python3 app.py
在另一个终端执行：
curl -s http://127.0.0.1:8080/authorize \
-H 'Content-Type: application/json' \
-d '{
"user": "alice",
"agent": "support-agent",
"tool": "database.read",
"resource": "customer_pii",
"risk_score": 42
}'
由于请求涉及敏感资源，结果应为：
{"decision": "review", "reason": "sensitive resource"}
接入真实系统时，需要做几项关键改造：风险分数必须由可信的安全组件计算，不能接受客户端自报；用户和智能体身份应通过签名令牌传入；策略版本、输入摘要和决策结果应写入不可篡改的审计记录；授权服务不可用时，则应根据操作风险选择拒绝、降级或只读模式。
落地时避免把“自适应”变成“不可预测”
持续学习并不等于让模型直接修改生产防火墙。更稳妥的采用路径是：
- 先观察：记录智能体工具调用和决策建议，不立即阻断。
- 再约束高风险动作：优先保护代码执行、数据导出、权限修改和资金操作。
- 逐步自动化：只自动处置低影响、可回滚且置信度高的事件。
- 持续评估误报：将拒绝率、人工复核率、绕过案例和业务延迟纳入指标。
- 防止反馈污染：攻击者可能故意制造样本来影响基线或策略，因此训练和反馈数据也要验证来源。
自适应应用安全的价值，不在于增加另一个 AI 检测器，而在于让代码风险、网络流量、智能体动作和安全情报共享同一套上下文。真正可用的系统既要快速响应新攻击，也必须保持策略可解释、变更可审计、操作可回滚。