同一栋楼的两侧，一侧是加厚的金库门，另一侧是每天刷卡进出的员工通道

一、三层资产在四种属性上本来就不一样

一家网络安全初创公司（公开报道为 Cathedral）在一家头部模型公司的外部安全研究测试计划框架下开展工作。据公开报道引述的研究方报告草稿，研究人员运行 AI 智能体不到 12 小时就找到了进入该公司内部数据与消息系统的路径，而先前直接针对自研代码的进攻没有达到同样的效果；这个时长来自当事研究方的草稿表述，属于报道口径，不是本篇的判断依据。被测试方回应称，研究人员访问的是范围有限的销售、人力资源与 IT 系统，接触内容是部分客户与合作伙伴的商务联系信息以及一些基础用户账户记录，并明确客户发给模型的消息、模型返回的回复、公司 AI 系统背后的代码与模型权重均未被访问。这句是转述，不作为本篇任何结论的支撑。

抛开表述差异，这件事把一张表摊开了：资产至少分三层，而三层的属性从来不一样。

  • 自研核心与模型资产。主体身份是企业自己持有的账号与密钥，访问入口通常是专网加跳板，日志密度最高，每一次敏感操作都有集中审计，责任团队是安全与平台工程。
  • 客户数据面。主体身份受合同与合规条款约束，入口应该有网关与租户隔离，日志要做成可交付的证据，责任团队里除了工程还有法务。
  • 行政与办公类 SaaS。主体身份往往是业务部门自己买的订阅、由 IT 代管账号，入口是公网可达的服务地址加企业目录联合登录，日志大部分在供应商那一侧，租户能看到的字段少、粒度粗、留存期短，责任团队名义上是 IT，实际是“谁着急用谁说了算”。

为什么最硬的那层被重点防护、最松的那层人人天天登录，这是结构性的而不是疏忽。第一，预算与注意力跟着“资产价值”走，而防护强度本该跟着“可达性”走，核心层的使用者是要害工程师，登录频次低、路径单一，加几道认证不会被抱怨；行政平面被销售、人力、IT 每天反复登录，任何一道额外摩擦都会变成工单，最后被当作可用性问题推回去。第二，行政 SaaS 多由业务部门发起采购，安全团队既不在采购评审的名单里，也不在合同签署链上，等它进入资产清单时，往往已经是一家安全公司报告草稿里的那一句。第三，责任分散：核心层出事有人顶上，办公平面出事时没人认为自己是对口的责任团队。

二、“发现后就断了”要拆成三个可核对项

被测方称自身监控系统在对方提交报告之前就发现了部分相关活动，并在发现后关闭了研究人员的访问权限。这句话里有三个可核对项，缺任何一个，它都只是善意表述。

其一，检出时点落在哪个数据源。终端检测与响应、身份目录的异常登录、应用侧审计、网络出口四者给出的覆盖完全不同；只落在身份源的检出看不到用令牌直接调接口的行为，只落在出口的检出看不到在应用内部读了什么。其二，覆盖到哪几个系统。一次检出的标准追问是“当时被登录过的系统全列出来”，多数企业答不上，因为各 SaaS 的审计日志不进同一个索引，租户也拿不到统一视图。其三，断权断到了哪一段。这是最容易写成一件事、实际是四件事的地方。

断权段 断的是什么 最常见遗漏 执行方 要留的凭据
活跃会话 已登录的浏览器与客户端会话 只禁了新登录，旧会话还在 身份目录管理员 会话吊销记录与时间戳
长期令牌 个人访问令牌、离线访问令牌、刷新令牌 令牌按有效期自然到期，不吊销等于没断 身份目录与平台管理员 吊销清单与逐条回执
服务间凭据 应用对应用的服务账号、联合登录配置里的密钥 测试期间新建的服务凭据没人认领 应用负责人加安全侧复核 变更单与前后对照
第三方集成 同步任务、连接器、回调与出站推送 主账号断了，连接器仍在替它做事 各 SaaS 的管理员 集成清单与停用截图

四段里只断第一段最常见：人在界面上退出了、登录也被禁了，可同步任务还在跑、测试期间创建的服务令牌还有效。所以断权要写成“四段各自有执行人与凭据”，而不是一个动作一句结论。

三、停用第三方软件，先要有能被执行完的降级流程

被测试方称已停用受影响的第三方软件，直至相关供应商确认漏洞得到修复，并向联邦政府相关部门通报。这是一个正确方向的动作，它的难点全在连带：销售、人力、IT 这类系统一停，审批走不通、发薪走不通、订单录入走不通。没有预先写好的降级流程，这个动作在实际执行时一定会被一句“先用着”击穿，而且击穿发生得无声无息。

把这件事做成可执行，需要在每个行政 SaaS 进资产清单时就附三件东西。第一件是停用影响表，列出依赖它的业务流程、可容忍的中断时长、超期后改走什么手工流程、手工流程留下什么账务与合同后果。第二件是被演练过的降级路径，重点在“演练过”三个字，文档里写明的备用流程不算，只有真跑过一次、留下参与人与耗时记录的路径，在停用时才会真的被启用。第三件是与供应商确认过的停用与恢复接口，包括管理员权限归属、数据导出能力、恢复后由谁负责回填、回填的校验方式。

还有一条常被漏：谁有权宣布停用，谁有权宣布“例外先用着”。这两个权限必须分开，例外要写明有效期并到期复核，且复核人不是申请例外的人。最长可停用时长不是拍出来的数字，它由业务流程可容忍的中断长度倒推；定不出这个时长的系统，说明还没人真正设想过它不在。

四、智能体参与测试，授权半径要重写成三条可判约束

传统外部测试的授权是按允许的 IP 与时间段划范围的，一张范围清单加一个时间窗就够了。智能体参与的测试不适用这个假设：它会自己决定下一步碰什么，会把一个系统里拿到的权限材料带到另一个系统去用。授权文件里没写的东西，在这个语境下不等于被允许，而被默认允许。最小权限要落成三条可判约束。

其一，不做未声明的资产发现。测试对象以双方确认过的清单为准，命中清单外的对象就停下并上报，不能把“顺带看到”算作合理推进。其二，不跨系统串联权限材料。在某一个系统内部获得的东西，不得拿去进入另一个系统，哪怕两个系统各自都在授权范围内；这一条要写成可判定的规则，而不是行为倡议。其三，命中超出授权范围的动作即自动停止，并把动作序列落盘。停止条件要机器可判，不能靠人盯屏幕；落盘的内容至少包含每一步的输入、决策依据与实际发起的动作，供事后与被测方自己的日志对账。

被测方一侧的对应物同样要提前准备：授权范围声明在测试开始前锁定版本，写明这次覆盖哪几个域名、哪些租户、哪几类系统，不包括哪几类，双方各存一份。没有这个底本，事后关于范围的讨论就没有可收敛的锚。

五、影响面各执一词时，能收敛的只有四件东西与四栏披露

报告草稿列出的会议记录、员工薪酬与录用详情、内部即时消息，与被测方“范围有限的销售、人力与 IT 系统”的表述并不完全相同。本篇不判断两边谁对，只说这种对不上时，什么才算证据。测试方与被测方各自都必须留四件东西。

  • 动作时间窗，起止时刻与每段动作的时间戳。
  • 访问过的对象清单，系统、数据集合与记录标识的形式，不必包含明文内容。
  • 双方确认过的范围声明，也就是测试开始前锁定的那一版。
  • 停止条件与达成记录，什么时候触发、是否自动停止、由谁确认。

这四件东西凑齐，影响面讨论就从叙事之争变成对账。而最终给外的披露文本，建议按四栏逐行填：系统、字段类别、主体数量级、是否可逆。

栏目 要回答的问题 填不出来说明什么
系统 哪一个业务系统被访问 资产清单本身不全
字段类别 触及的是哪一类字段，而不是多少条记录 没有字段级数据地图
主体数量级 受影响的是哪一档规模 定损还没开始
是否可逆 被读取、被导出、被修改是三件事 处置动作没分层

为什么“未受影响”的列举方式最容易掩盖真正受影响那部分？因为它只覆盖声明者想到的系统，而读者会把它读成穷尽；这份清单越长，注意力越被那一大段安心话吸走，剩下的短的一栏反而得不到细节。逐行填的四栏表能把漏填逼出来：某个系统没写，就是缺口，而不是被一句总体结论盖过去。

六、同类软件的使用者能做的三件自查

涉事软件供应商名称与具体缺陷细节尚未公开，这不影响其他同样在用行政与销售类 SaaS 的企业动手。三件自查按顺序做。

第一件，按类别盘点在用的行政与销售 SaaS，覆盖合同、报销、招聘、知识库、工单、客户关系、日历与邮件归档等，每一家补齐三列：谁买的、账号归谁、审计日志在哪一侧。这一遍盘点通常会发现相当一部分系统连管理员都不是企业自己。第二件，订阅其安全通告通道，并把通知时限写进合同。合同里只写“会及时通知”没有约束力，要写明从供应商确认问题到租户收到通知的时限、通知送达的角色、未按时通知时的补救条款，以及供应商在修复进度上的更新频率。第三件，对办公平面单独做一次与核心系统脱钩的演练，设定是行政类系统全部不可用且暂不给恢复时间，看审批、发薪、订单录入三条线多久之内改走手工、由谁签字、事后怎么回填，并要求演练把断权四段的每一段执行凭据都留下来。

最后把三层重排成一张表，这张表就是自查的起点。

层级 典型入口 现有监控 断权手段 本批事件里的表现
自研核心与模型资产 专网、跳板、内部构建系统 集中审计，字段全 四段齐全且有执行人 被测方声明未被访问，属转述
客户数据面 网关、租户隔离的服务接口 面向交付的证据级日志 按租户吊销 被测方称触及部分商务联系信息
行政与办公类 SaaS 目录联合登录、公网可达 依赖供应商侧日志 常只断登录会话 报告草稿所称的进入路径所在

在洹拓的视角里，这件事还有一条对客交付的直接含义：我们给客户做的智能体系统，同样会登录在客户的办公类系统里，甲方给的范围与乙方能做到的落盘必须在合同附件里对齐，尤其是自动停止条件与动作序列的留存方式。守住核心层不等于守住了数据面，防护强度要按可达性重排，而“我们守住了什么”这句话，只有配上四段断权凭据与四栏披露才站得住。

#外部安全测试 #智能体渗透 #第三方办公软件 #资产分层 #影响面披露