synexasMATRIX
预约演示
行业分析

助手读过一份文档
谁还能读到它的执行记录?

保险客户文档或制造业供应商文件中的文字,会不会也出现在 AI 助手的执行记录中?微软 10 月 19 日发布的 Browser Automation 公告提出了一个具体的审查问题:敏感记录内容流向哪里,谁能读取,旧副本如何处理。数据路由、访问保护和删除,需要分别提供证据。

生成式插图:桌上放着打开的文件夹、叠放的空白文档和档案夹,旁边蓝色布面上有一把钥匙。
生成式编辑插图:空白文件和钥匙借指文档副本与读取权限,并非真实执行日志、客户文件或保护效果的证据。
一览

先追踪内容去向
再核查读取权限

评估范围

微软文档说明,Foundry 执行记录可能包含提示词、回答、指令和工具调用内容等敏感信息。这些是需要检查的潜在副本,并不证明每份文档都会被记录。

可比证据

文档所述的 9 月 30 日路由变更针对新采集的属性值。临时退出机制可能保留此前的路由方式。

审查责任归属

专用表仍须明确设置为受保护。需要核查获准访问的身份、自定义角色例外,以及权限生效的资源范围。

验收决定

分别测试应当允许和应当拒绝的读取行为。旧记录、保留期限、训练用途和删除情况,须有实际环境的证据才能下结论。

核查要点

一则新公告
一条早已存在的数据边界

微软于 2026 年 10 月 19 日宣布,Foundry 的 Browser Automation 工具正式可用。对应 RSS 条目的发布时间确认了这一日期,条目全文也包含敏感执行记录警示。公告说明,记录可能含有提示词、模型回答、系统指令,以及工具调用的参数或结果,并引导开发者阅读仍标为预览的保护流程。本文分析的是这条较窄的数据处理边界,不讨论所有相关浏览器组件是否都已正式可用。微软的敏感记录指南明确指出,标为预览的功能不提供服务级别协议,且不建议用于生产工作负载;部分能力可能受限或不受支持。新公告并未取消这些限定。

实际需要区分的是:获准读取原始文档,不等于获准读取助手工作期间记录下来的内容。微软将输入消息、输出消息、系统指令、工具定义、工具调用参数、工具调用结果和评估解释列为敏感属性。应当询问,在拟采用的流程里,哪些属性可能包含文档文字,实际追踪配置又会采集哪些内容。金融或保险机构的采购方可以问,工具结果中是否会出现客户文档摘录;制造企业则可以针对供应商规格文件或图纸文字提出同样的问题。这些是评估问题,不是已观察到的部署或实际案例。

核查要点

改变存储去向
不等于自动完成保护

根据微软文档,2026 年 9 月 30 日之前,Application Insights 会把这七类属性同时发送至 AppGenAIContent,以及原有的 AppDependencies、AppTraces 和 AppEvents 表。从该日起,新采集的属性值不再流入这些原有表;属性键仍保留,其值改为指向 AppGenAIContent 的简短引用。提前启用这一行为使用的是 protectGenAISensitiveData 功能标志。不过,在更新自定义查询及相关内容期间,optOutProtectGenAISensitiveData 标志可以暂时维持原路由。微软说明,这项退出机制将于 2027 年 9 月 30 日终止;提前注销该标志可更早恢复专用表路由。不要仅凭日期判断当前状态,应索取实际订阅配置和近期记录。随后还要单独检查保护级别:把内容发送至 AppGenAIContent,与将该表设为 Protected,是两件不同的事。

核查要点

明确谁能读取
核查权限覆盖范围

微软的受保护表指南说明,表被设为 Protected 后采用默认拒绝的访问模式。内置 Privileged Monitoring Data Reader 角色可以读取其分配范围内的所有受保护表,因此范围本身很重要。对于通过 Foundry 和 Application Insights 查看敏感内容,Foundry 指南要求在关联的 Application Insights 资源上分配角色;直接面向 Log Analytics 工作区的查询,则需要工作区上的相应角色分配。不能把这个内置角色理解为唯一的访问路径。指南明确保留了具备相关 Azure Monitor DataActions 的自定义角色例外;受保护表文档还介绍了如何用表名和保护级别的 ABAC 条件限定自定义授权。应请管理员核实实际生效的角色分配和条件,而不只是核对角色名称。同一份指南还介绍了 DataActionsOnly 模式,它会移除某些控制平面角色带来的隐式日志读取路径。应确认实际工作区是否采用该模式,不能假定已经启用。

核查要点

检查新记录
核清旧副本

使用经过授权、不含敏感信息的测试输入,并在测试前写明预期可见范围。微软的验证说明区分了两种身份:只有 Log Analytics Reader、没有特权或符合条件的自定义访问权的用户,以及具备适当授权的用户。在文档所述的受保护表检查中,前者的查询执行成功,但不返回任何行;后者则能返回数据。因此,查询成功本身并不证明获准用户能够看到内容。同时,还要检查普通的非敏感执行信息是否仍按预期可见。对 2026 年 9 月 30 日之前采集的记录,应另行核查:微软说明,这些记录仍留在原有表中,并可像此前一样查询。新的路由目标不会追溯迁移或删除旧记录。应指定负责人查找相关旧记录,并询问组织使用的导出文件、报告或其他目的地是否还存在额外副本,只记录实际发现。凡是验收要求依赖删除,就应先取得针对实际环境的保留和删除证据,包括历史副本如何处理。本文引用的页面并未证明这些内容已经删除。

执行记录副本:按顺序核查证据

  1. 确认采集内容
  2. 检查路由
  3. 审查读取身份
  4. 测试可见范围
  5. 查找旧副本
  6. 依据证据决定

确认哪些提示词、回答或工具调用字段可能包含文档文字,不假定每份文档都会被记录。

核查采集日期和实际功能标志,包括临时退出新路由的配置。

核实 Protected 状态、实际生效的特权或符合条件的自定义授权,以及覆盖的资源范围。

使用获准的非敏感测试内容,比较允许与拒绝读取的身份;查询成功也可能不返回任何行。

迁移前的记录仍可在原有表中查询。保留期限、额外副本和删除情况需要单独取证。

记录已验证行为和未解决要求。预览和生产使用方面的限定依然适用。

相连的文档、范围、读取身份和证据图形,表示采购方的审查顺序,不是自动保护流水线。微软文档提供了路由与访问检查方法,但并未证实历史副本已删除。任何节点都不代表实测结果或控制已通过。
来源

阅读厂商依据
保留原有适用边界

本文是对微软公告和配置文档的分析,不是独立测试、事故报告或漏洞利用证据。RSS 条目的发布时间,与订阅源频道更新时间、9 月 30 日迁移事件日期是不同概念。这些来源不能确认某个租户的配置、保留期限、训练用途,也不能证明历史内容已完成删除。文档中的访问验证方法,同样不能证明所有生产流程都适用。评审拟采用的方案时,必须同时保留预览、无 SLA 和生产使用方面的限定。验收记录应区分已验证的路由、已验证的读取行为,以及尚未解决的历史副本问题;没有答案,不能记作控制已通过。

让 AI 真正帮上忙,
从您的实际工作开始。

请描述团队反复处理的任务,不要提供机密文件。我们会演示 Matrix 如何处理相似工作。

预约演示
下载

安全说明

请提供收件信息。