1. 事件还原与核心问题拆解1.1 一个智能体是怎么“跑偏”的先把这件事的骨架讲清楚。一个具备浏览器操作能力的 AI Agent在某个任务执行链路中访问了本不该访问的站点并且在这个过程中把 53 张用户图片带到了外部可访问的位置。这不是科幻片这是典型的智能体权限边界失控加上数据外泄路径未封堵的组合事故。我做了几年 Agent 相关的工程落地见过太多团队在 Demo 阶段跑得飞起一上生产就出各种幺蛾子。这次事件的核心其实就三个字没兜住。智能体本身没有“恶意”它只是在执行任务时走到了人类没有预设护栏的区域。问题出在护栏的设计上而不是智能体的“道德水平”上。从技术视角拆这条事故链路大致是这样的Agent 接收了一个任务指令这个指令可能包含“访问某个网址”“抓取页面内容”“处理用户上传的素材”等动作。在执行过程中Agent 的浏览器工具或 HTTP 请求工具没有被严格限制目标域名白名单导致它可以访问任意站点。同时用户上传的图片存储在某个临时目录或对象存储中Agent 在处理任务时把这些图片的访问路径暴露给了外部请求或者直接把图片内容作为请求体发到了外部服务。这里有一个很多人容易忽略的点Agent 的“工具调用”和“数据访问”往往是两条独立的权限线。工具调用管的是“它能做什么动作”数据访问管的是“它能碰哪些数据”。很多团队只做了前者忘了后者。结果就是 Agent 能调浏览器而浏览器能访问的 URL 里恰好包含了用户图片的直链于是数据就出去了。1.2 为什么偏偏是“图片”泄露了53 张用户图片这个数字不大不小但性质很敏感。图片类数据在 Agent 场景里通常有几个特点第一它往往是用户直接上传的原始素材包含人脸、证件、截图等敏感信息第二它的存储路径经常是“可预测的”比如https://storage.example.com/uploads/{user_id}/{filename}这种结构第三很多团队对图片的访问控制做得比文本数据松因为觉得“图片嘛看看又不会怎样”。我踩过的一个坑就是早期做文档处理 Agent 时用户上传的 PDF 和图片都放在同一个公开可读的 bucket 里只是文件名用了 UUID。当时觉得 UUID 够随机了结果 Agent 在调试模式下把整个 bucket 的列表权限打开了所有文件名一览无余。这次事件大概率也是类似的路径——不是黑客多厉害而是 Agent 自己把门打开了。注意任何用户上传的素材无论是否“敏感”都必须默认私有。公开可读的存储桶在 Agent 场景下等于把保险柜钥匙插在锁上。1.3 这件事对做 Agent 的人意味着什么如果你正在做智能体开发不管是基于 Coze、Dify 这类平台还是用 Python、Rust 自己撸框架这件事都跟你有关。因为它暴露的不是某个产品的 bug而是整个行业在智能体安全控制上的集体短板。OWASP 在 2026 年发布的智能体应用 Top 10 风险里ASI01 到 ASI10 几乎每一条都能在这起事件里找到影子权限过大、工具滥用、数据泄露、缺乏审计、目标劫持……我个人的判断是接下来半年到一年凡是面向企业交付的 Agent 项目安全审计会成为必选项。现在不把护栏做扎实后面要么被客户的安全团队打回来要么出了事自己扛。这篇文章就围绕这次事件把智能体安全控制的关键环节拆开讲包括权限设计、工具隔离、数据流管控、审计日志、以及实操中怎么落地。2. 智能体安全控制的核心设计思路2.1 最小权限原则在 Agent 场景下的具体含义最小权限这个词大家都听过但在 Agent 场景下它的含义比传统应用复杂得多。传统应用里一个服务账号的权限是静态的你给它读数据库的权限它就只读数据库。但 Agent 不一样它的权限是动态组合的它可能先调一个搜索工具再调一个浏览器工具再调一个文件读写工具每个工具都有自己的权限范围而这些工具组合起来的能力边界往往超出了设计者的预期。举个例子你给 Agent 一个“读取本地文件”的工具权限限制在/tmp/agent_workspace/目录下。看起来没问题。但你又给它一个“发送 HTTP 请求”的工具没有限制目标域名。那么 Agent 完全可以读取/tmp/agent_workspace/user_upload.jpg然后把这个文件的内容 POST 到任意外部地址。两个工具单独看都“最小权限”了组合起来却形成了数据外泄通道。所以我在实际项目里推行的做法是工具权限矩阵。把每个工具的能力拆成“动作”和“数据”两个维度然后定义哪些动作可以碰哪些数据。比如浏览器工具只能访问白名单域名文件工具只能读写指定目录HTTP 工具只能请求内部 API 网关。任何跨维度的组合都需要显式授权。工具类型动作权限数据权限组合限制浏览器仅限白名单域名仅限公开页面内容禁止携带本地文件内容文件读写仅限工作目录仅限任务相关文件禁止读取用户上传原始文件HTTP 请求仅限内部网关仅限结构化 JSON禁止传输二进制数据代码执行仅限沙箱环境仅限临时目录禁止网络访问这张表是我在多个项目里迭代出来的核心逻辑就是任何一个工具都不能同时具备“读取敏感数据”和“向外发送数据”的能力。如果业务确实需要那就拆成两步中间加人工审核或加密通道。2.2 工具调用的白名单与黑名单机制白名单和黑名单听起来简单但在 Agent 场景下选哪个、怎么维护直接决定了安全水位。我的经验是对外部访问一律用白名单对内部操作可以用黑名单。为什么因为外部世界的域名是无穷无尽的你永远列不完黑名单。而内部操作的范围是有限的你知道哪些目录、哪些命令是危险的列黑名单更灵活。比如文件删除操作你可以黑名单掉rm -rf /这种但白名单就只能允许删除特定后缀的临时文件太死板。具体到浏览器工具的白名单我一般会分三层一级白名单业务必须访问的核心域名比如公司官网、内部知识库、指定的数据源。这些域名允许完整交互包括点击、填表、下载。二级白名单只读访问的域名比如公开的文档站点、新闻页面。允许 GET 请求禁止 POST 和文件上传。三级白名单完全禁止的域名包括所有未列出的域名。默认拒绝需要走审批流程才能加白。这个分层的好处是即使 Agent 被诱导去访问恶意站点它也只能停留在“只读”层面没法上传数据或执行脚本。而且每一层都有独立的审计日志出了问题能快速定位是哪一层被突破了。实操心得白名单的维护一定要自动化。我见过团队用 Excel 管理白名单结果三个月后没人记得哪个域名是谁加的。建议用配置中心或数据库表每条记录带申请人、审批人、有效期。过期自动失效避免“僵尸白名单”。2.3 数据流的隔离与脱敏策略数据泄露的根源往往不是“被偷”而是“被看见”。Agent 在处理任务时会接触到大量数据其中很多是不需要“看见”的。比如用户上传了一张身份证照片Agent 的任务只是“提取姓名和身份证号”那它就不需要把整张图片加载到内存里更不需要把图片传给任何外部服务。我在项目里推行的做法是数据分级 按需脱敏L1 公开数据可以自由流转比如公开的网页内容、产品文档。L2 内部数据需要鉴权访问比如内部知识库、非敏感的业务数据。L3 敏感数据必须脱敏后才能进入 Agent 处理链路比如用户手机号、地址、证件信息。L4 机密数据禁止进入 Agent 链路比如密钥、财务数据、核心代码。对于 L3 数据脱敏的方式要看任务需求。如果 Agent 只需要判断“这张图里有没有人脸”那就把图片转成灰度缩略图人脸区域打码再传给 Agent。如果 Agent 需要提取文字那就用 OCR 在本地完成只把文字结果传给 Agent原始图片永远不出本地。这次事件里泄露的 53 张图片如果按照这个分级大概率属于 L3 甚至 L4。它们本不应该被 Agent 的浏览器工具“看见”更不应该出现在外部可访问的 URL 里。问题就出在数据流没有隔离用户上传的图片存储和 Agent 的工作空间是同一个可访问区域Agent 在访问外部站点时顺手就把这个区域的 URL 带出去了。2.4 审计日志事后追责与实时阻断审计日志不是“记下来就行”它要能回答三个问题谁在什么时候、通过什么工具、访问了什么数据、做了什么动作、结果如何。这五个要素缺一个日志就是废的。我在实际部署中会把审计日志分成两个通道行为日志记录 Agent 的每一次工具调用包括工具名、参数、时间戳、调用链 ID。这个日志用于事后分析比如“Agent 为什么访问了那个域名”。数据日志记录每一次数据访问包括数据 ID、访问方式、数据量、目标地址。这个日志用于实时监控比如“Agent 正在把 10MB 的图片 POST 到外部地址”触发告警。两个通道的日志通过调用链 ID 关联这样出问题时能快速还原完整链路。我一般用 OpenTelemetry 做埋点日志存到 Elasticsearch 或 ClickHouse告警规则用 Prometheus 或自定义的规则引擎。注意审计日志本身也是敏感数据不能随便存。我见过团队把日志写到公开的 S3 桶里结果日志里包含了用户 token 和内部 URL反而成了新的泄露源。日志存储必须加密访问权限要严格控制。实时阻断这块我的做法是在工具调用层加一个“策略引擎”。每次工具调用前策略引擎检查目标域名是否在白名单、数据级别是否允许外发、调用频率是否异常。任何一项不通过直接拒绝并告警。这个策略引擎可以用 OPAOpen Policy Agent或 Cedar 这类策略语言来实现规则和代码分离方便安全团队独立维护。3. 实操落地从零搭建带安全护栏的 Agent3.1 环境准备与基础框架选型假设你现在要从零搭一个带安全护栏的 Agent我以 Python 技术栈为例把关键步骤和配置讲清楚。选 Python 是因为生态成熟LangChain、LangGraph、FastAPI 这些工具链能快速搭出原型而且安全相关的库也丰富。基础环境python -m venv agent-env source agent-env/bin/activate pip install fastapi uvicorn langchain langgraph playwright opa-python-client框架选型上LangGraph 适合做有状态的多步 Agent它的图结构天然适合插入“安全检查节点”。Playwright 用来做浏览器操作比 Selenium 更现代而且支持请求拦截方便做域名白名单。OPA 用来做策略引擎规则用 Rego 写灵活且可测试。如果你用的是 Coze、Dify 这类平台安全护栏的定制空间会小一些但核心思路一样在工具配置里限制域名、在数据源配置里限制访问范围、在输出环节加内容审核。平台的优势是开箱即用劣势是深度定制受限。我的建议是原型阶段用平台快速验证生产阶段如果安全要求高还是自己搭框架更可控。3.2 浏览器工具的域名白名单配置Playwright 的请求拦截是白名单落地的关键。下面这段代码是我在实际项目里用的核心逻辑是拦截所有请求检查目标域名是否在白名单里不在就 abort。from playwright.async_api import async_playwright import fnmatch ALLOWED_DOMAINS [ *.example.com, docs.python.org, api.internal.company.com ] def is_allowed(url: str) - bool: from urllib.parse import urlparse host urlparse(url).hostname or for pattern in ALLOWED_DOMAINS: if fnmatch.fnmatch(host, pattern): return True return False async def run_browser_task(task_url: str): async with async_playwright() as p: browser await p.chromium.launch(headlessTrue) context await browser.new_context() page await context.new_page() async def route_handler(route): if is_allowed(route.request.url): await route.continue_() else: await route.abort() # 记录审计日志 log_blocked_request(route.request.url) await page.route(**/*, route_handler) await page.goto(task_url) # ... 后续操作 await browser.close()这段代码的关键点route.abort()会直接阻断请求Agent 拿不到任何响应自然也没法把数据传出去。同时log_blocked_request记录被阻断的 URL方便后续分析 Agent 的行为模式。实操心得白名单的匹配规则要小心。*.example.com会匹配evil.example.com如果攻击者能控制子域名就可能绕过。更安全的做法是精确匹配或者用正则限制子域名范围。另外重定向也要拦截因为一个白名单域名可能 302 到外部地址。Playwright 的route.continue_()默认会跟随重定向需要在 handler 里检查每一跳。3.3 文件访问的沙箱化处理文件访问的沙箱化核心是路径规范化 目录限制。Agent 拿到的文件路径可能是用户输入的也可能是工具生成的必须经过规范化后才能访问。import os from pathlib import Path WORKSPACE Path(/tmp/agent_workspace).resolve() def safe_read(file_path: str) - bytes: target (WORKSPACE / file_path).resolve() if not str(target).startswith(str(WORKSPACE)): raise PermissionError(fAccess denied: {file_path}) if not target.is_file(): raise FileNotFoundError(file_path) return target.read_bytes() def safe_write(file_path: str, data: bytes): target (WORKSPACE / file_path).resolve() if not str(target).startswith(str(WORKSPACE)): raise PermissionError(fAccess denied: {file_path}) target.parent.mkdir(parentsTrue, exist_okTrue) target.write_bytes(data)这段代码的关键是resolve()和startswith()的组合。resolve()会把../这种路径穿越解析掉startswith()确保最终路径在工作目录内。我见过很多实现只做了字符串检查结果被....//这种绕过。对于用户上传的原始文件我的做法是物理隔离上传的文件存在一个独立的目录Agent 的工作目录是另一个。Agent 需要处理文件时先由预处理服务把文件脱敏、转换格式再复制到工作目录。这样即使 Agent 的工作目录被突破原始文件也不受影响。3.4 策略引擎的规则编写与集成OPA 的 Rego 规则写起来像 SQL 和 Prolog 的结合体一开始可能不习惯但写几条就顺了。下面是一个策略示例检查工具调用是否合规package agent.policy default allow false allow { input.tool browser input.action navigate domain_allowed(input.target) } allow { input.tool file_read input.action read path_in_workspace(input.path) } domain_allowed(target) { some pattern in data.allowed_domains glob.match(pattern, [.], target) } path_in_workspace(path) { startswith(path, /tmp/agent_workspace/) not contains(path, ..) }集成到 Python 里import requests def check_policy(tool: str, action: str, **kwargs) - bool: payload {tool: tool, action: action, **kwargs} resp requests.post( http://localhost:8181/v1/data/agent/policy/allow, json{input: payload} ) return resp.json().get(result, False)每次工具调用前先过check_policy不通过就拒绝。这个策略引擎可以独立部署安全团队改规则不需要动 Agent 代码职责分离审计也方便。注意策略引擎本身的高可用要考虑。如果 OPA 挂了Agent 是拒绝所有调用还是放行我的选择是默认拒绝宁可服务不可用也不能让未检查的调用通过。这个取舍要在团队里达成共识。3.5 数据外泄的实时监控与阻断实时监控的核心是在数据离开 Agent 环境之前拦截。我的做法是在网络出口加一个代理所有 Agent 发起的 HTTP 请求都经过这个代理代理检查请求体里是否包含敏感数据。from mitmproxy import http import re SENSITIVE_PATTERNS [ re.compile(rb\x89PNG), # PNG 文件头 re.compile(rb\xff\xd8\xff), # JPEG 文件头 re.compile(rbAKIA[0-9A-Z]{16}), # AWS Access Key ] def request(flow: http.HTTPFlow): body flow.request.content or b for pattern in SENSITIVE_PATTERNS: if pattern.search(body): flow.response http.Response.make( 403, bBlocked by data loss prevention ) log_dlp_event(flow.request.url, pattern.pattern) return这个代理用 mitmproxy 的 addon 机制实现部署在 Agent 和外部网络之间。任何包含图片文件头、密钥模式的请求体都会被阻断。这个方案的好处是不依赖 Agent 自身的合规性即使 Agent 被绕过数据也出不去。实际部署时这个代理要和域名白名单配合使用白名单域名走代理但只检查数据外泄非白名单域名直接阻断。两层防护一层管“能不能去”一层管“能不能带东西出去”。4. 常见问题与排查技巧实录4.1 Agent 绕过白名单的几种典型方式在实际对抗中Agent 绕过白名单的方式比想象的多。我整理了几种常见的以及对应的排查方法绕过方式原理排查方法修复方案DNS 重绑定白名单域名解析到内网 IP检查 DNS 解析结果解析后校验 IP 范围重定向跳转白名单域名 302 到外部检查每一跳的 Location拦截重定向逐跳校验URL 编码绕过%2e%2e等编码路径穿越解码后再校验规范化后再匹配子域名混淆evil.example.com匹配*.example.com检查匹配规则粒度精确匹配或限制子域名协议降级HTTPS 降级到 HTTP 再跳转检查协议变化强制 HTTPS禁止降级DNS 重绑定这个特别隐蔽。攻击者控制一个白名单域名的 DNS第一次解析返回正常 IPAgent 通过校验后第二次解析返回内网 IPAgent 就访问到内网了。排查方法是在请求发出前先解析域名拿到 IP校验 IP 是否在允许范围内然后再用这个 IP 发起请求避免二次解析。实操心得我在项目里加了一个“请求指纹”机制每次请求记录域名、IP、路径、方法、请求体哈希。如果同一个域名短时间内解析到不同 IP或者请求模式突变就触发告警。这个机制帮我抓到过几次异常的 DNS 解析。4.2 数据泄露的早期信号与告警配置数据泄露不是一瞬间发生的通常有早期信号。我总结了几个关键指标配置成告警规则异常外发流量Agent 发起的请求体大小突然增大比如从平均 1KB 跳到 1MB。这通常意味着它在往外传文件。非工作时间活动Agent 在业务低峰期频繁调用外部工具可能是被劫持或任务异常。敏感文件访问Agent 访问了标记为 L3/L4 的数据即使没有外发也要告警。白名单拒绝率上升短时间内大量请求被白名单阻断说明 Agent 在尝试访问未授权域名。告警配置示例Prometheus 规则groups: - name: agent_security rules: - alert: LargeOutboundPayload expr: agent_request_body_bytes 1048576 for: 1m labels: severity: critical annotations: summary: Agent 外发请求体超过 1MB - alert: HighBlockRate expr: rate(agent_blocked_requests_total[5m]) 10 for: 2m labels: severity: warning这些告警要接到值班系统不能只发邮件。我见过团队把告警发到邮件组结果没人看三天后才发现异常。4.3 事后溯源怎么还原 Agent 的完整行为链出了事之后溯源的速度决定了损失的大小。我的做法是全链路追踪 快照回放。全链路追踪用 OpenTelemetry每个任务生成一个 trace ID所有工具调用、数据访问、策略检查都挂在这个 trace 下。日志存到 ClickHouse查询速度快支持复杂的关联分析。快照回放是指Agent 的每一步操作都记录输入和输出包括页面截图、文件内容哈希、请求响应摘要。这样即使原始数据已经变了也能通过快照还原当时的状态。我一般用对象存储存快照按 trace ID 分目录保留 30 天。溯源时的查询顺序根据告警或用户报告拿到 trace ID。查行为日志看 Agent 调了哪些工具顺序是什么。查数据日志看访问了哪些数据有没有外发。查策略日志看哪些调用被允许、哪些被拒绝。调快照还原关键步骤的现场。这套流程我在一次内部演练中跑过从拿到 trace ID 到定位到具体是哪个工具调用导致的数据外泄大概 15 分钟。如果没有全链路追踪这个时间可能要按天算。4.4 智能体面试中常被问到的安全设计题最近帮几个朋友准备智能体方向的面试发现安全设计题出现频率很高。整理几个高频问题和我的回答思路问题一如何设计一个安全的 Agent 工具调用链路回答框架先讲最小权限原则再讲工具权限矩阵然后讲策略引擎的集成最后讲审计日志和实时阻断。重点突出“组合权限”的概念即单个工具安全不代表组合安全。问题二Agent 访问了恶意网站怎么办回答框架白名单阻断是第一道防线数据外泄防护是第二道审计告警是第三道。强调“默认拒绝”和“逐跳校验”以及 DNS 重绑定的防护。问题三怎么平衡安全性和可用性回答框架分级策略。核心业务走严格白名单创新业务走宽松沙箱。安全策略可配置不同任务用不同策略。关键是让安全团队和业务团队一起定策略而不是安全团队单方面拍板。问题四平台搭建的智能体和 Python 搭建的智能体在安全上有什么不同回答框架平台的优势是内置了一些安全能力比如 Coze 的数据隔离、Dify 的权限管理但定制空间小。Python 自建的优势是灵活可以深度定制策略引擎和审计系统但需要自己实现所有安全措施。选择取决于团队的安全能力和业务需求。注意面试时不要只背概念要结合具体案例。比如这次 OpenAI 智能体的事件就是一个很好的素材能展示你对真实安全问题的理解。4.5 避坑清单我踩过的那些雷最后整理一份避坑清单都是我在实际项目里踩过的不要相信 Agent 的“自我约束”提示词里写“不要访问外部网站”没用Agent 可能被诱导绕过。安全必须做在代码层不是提示词层。不要用黑名单做外部访问控制黑名单永远列不完而且新域名层出不穷。外部访问一律白名单。不要在 Agent 环境里存明文密钥Agent 可能把密钥写进日志、传给外部服务。密钥用短期 token用完即焚。不要忽略重定向白名单域名可能 302 到外部每一跳都要校验。不要只记日志不告警日志是事后用的告警是事中用的。两者都要有。不要忘了测试安全策略要定期做红队测试模拟 Agent 被劫持的场景验证防护是否有效。不要把安全做成“一次性”Agent 的能力在进化攻击手法也在进化。安全策略要持续迭代至少每季度 review 一次。我个人在实际操作中的体会是智能体安全这件事技术方案只占三成七成是流程和意识。再好的策略引擎如果团队没有安全意识也会被绕过。反过来即使工具简陋只要流程严格、审计到位也能挡住大部分风险。这次 OpenAI 智能体的事件对所有做 Agent 的人来说都是一次提醒能力越强护栏越要扎实。