关闭聊天正文记录，密钥仍可能进入追踪系统；模型没有提出工具调用，客户端历史也可能触发动作。PydanticAI在10月20日披露的两项中危问题，把企业Agent常见的两层保护拆开了：日志脱敏不等于所有元数据都安全，模型前后的检查也不等于工具执行已经获得授权。2.58.0提供修复，但维护团队还要处理历史追踪和正在运行的工作流。

快速看点：MCP遥测问题同时涉及v1和v2维护分支；UI适配器问题有明确版本与配置前提；Temporal用户不能为了改活动名称，忽略正在执行的持久化任务。此次发布没有披露真实客户受损规模，也不能由漏洞公告推导所有部署都已被利用。

不记录正文，也要检查请求元数据

第一项问题出现在启用请求追踪的场景。提供商原生MCP配置中的服务器地址、授权令牌和自定义请求头值，可能进入OpenTelemetry请求轨迹，即使include_content已经设为false。另一条路径来自URL生成的标识符：若凭据放在特定路径片段里，标识符本身也可能带出敏感内容。

受影响范围分别是v1的1.4.0至1.107.8之前，以及v2的2.0.0b1至2.58.0之前，涉及pydantic-ai及slim包。两个维护分支的修复版本为1.107.8和2.58.0。直接传入自选标识符的普通MCPToolset不属于公告所列的相同路径，不能把所有MCP用法笼统判为有漏洞。

对实施团队而言，检查范围应覆盖模型请求、工具地址、跨度名称和导出后的追踪存储，而不只搜索聊天正文。可观测系统往往面向开发、支持与运维多个角色，一旦元数据包含凭据，日志访问权限就可能变成另一条数据访问通路。这里的判断是交付风险分析，不代表已经发生泄露事件。

模型愿不愿执行，不是最后一道授权

第二项问题影响2.27.0至2.57.0的Vercel AI和AG-UI适配器。应用提供非空服务端message_history、系统提示由服务端管理，并依赖模型请求环节约束工具时，客户端提交的历史可能绕过一次模型请求，让可用工具按客户端参数执行。公告给出了这些前提，并非任意聊天请求都能触发。

这一路径仍会验证参数结构；要求人工批准的工具不会因此直接执行。工具函数内的授权，以及before_tool_execute中的执行前保护也不受相同绕过路径影响。真正暴露的问题，是把安全决定只放在模型请求前后，而执行入口仍相信历史记录已经代表了模型和用户的授权。

因此，工具参数合法与操作有权执行必须分开。一个格式正确的订单号，不意味着当前用户可以修改该订单；模型曾经同意某类操作，也不意味着所有恢复后的调用可以沿用批准。企业可以用这些问题复查边界，但不应把一次依赖升级误当作业务权限模型已经补齐。

先修版本，还要安排在途任务

2.58.0修正了UI历史处理顺序，使相关过滤先于尾部工具调用检查。遥测问题还要求限制历史追踪访问，并轮换已经暴露在其中的凭据。升级能阻止后续特定路径继续带出数据，却不会自动清除此前导出的副本；需要保留什么审计证据、谁能处置，应由组织的事件流程决定。

Temporal场景更需要规划顺序。v2的URL式MCP活动名称涉及持久化执行兼容，补丁没有直接改掉既有名称。公告建议在在途工作流完成之后，为MCP设置明确的id；贸然改名可能使恢复过程无法匹配旧活动。这里不是建议延迟所有安全处置，而是不要把不兼容的名称变更直接推入旧流程。

版本说明同时列出DBOS规划事件回放等兼容注意事项。生产升级宜区分新任务与恢复任务，验证暂停后继续执行、工具审批、追踪导出和费用统计，而不是只跑一次最简单的聊天请求。发布标签标题中的10月19日，也应与GitHub实际发布及安全公告的10月20日分开记录。

小编判断：让日志与执行各守一条边界

这次更新值得关注的不是中危标签本身，而是两个容易被忽略的默认假设：没有正文就没有敏感信息，经过模型就等于经过授权。Agent链路越长、恢复方式越多，这些假设越可能失效。追踪系统应默认减少敏感元数据，工具系统则应在最终执行入口重新核验身份、对象与批准状态。

对已有部署，优先识别版本和真实启用路径，再决定升级、追踪访问收紧与凭据处置顺序；对新项目，把拒绝执行和恢复测试写进验收清单。可观测性应帮助定位失败，而不是复制新的秘密；持久化执行应帮助恢复工作，而不是扩大一次旧批准的有效范围。