Workday走向无头化，向外部AI代理开放其人力资源和财务数据
内容提要
Workday推出无头可信代理平台，开放MCP服务器、实时数据SQL访问和共享运行时，允许开发者用Claude Code等工具构建HR与财务代理，但代理须遵循用户权限、审批和审计。Workday强调外部数据湖无法复制其治理规则，并演示了绕过管控的风险。
延伸解读
无头化如何继承权限与审计
Workday的无头可信代理平台将代理直接绑定到用户账户，代理只能访问该用户有权查看的数据，并遵循相同的审批和审计流程。MCP服务器提供275个读取工具和54个写入或删除工具，实时数据查询也按用户权限过滤结果。这意味着企业无需为代理单独重建一套安全模型，降低了权限漂移的风险。
数据湖代理的风险演示
Workday在简报中演示了通过自定义MCP服务器连接数据湖副本的代理，它返回了用户无权查看的职位申请，并在无审批情况下调动了错误员工，甚至查询到CTO薪资。这凸显了外部数据湖无法复制Workday治理规则的问题，一旦规则漂移，代理可能执行未经授权的操作。
与Salesforce等厂商的路径差异
Salesforce、ServiceNow和微软都已允许外部代理接入系统，但代理身份管理方式不同。Salesforce计划让代理使用自己的凭证和权限，而Workday的代理可拥有最多两个系统账户，分别用于代表用户和后台工作。Workday强调代理始终在用户权限下运行，不设侧门。
无头化的适用边界
Workday高管指出，直接基于MCP服务器构建代理仅适用于不需要HR或财务领域逻辑的少量场景。对于大多数用例，Workday推荐Claude将请求交给其代理编排器Sana，再由Sana调用Workday自有领域代理，确保运行时始终在中间管控。这提示开发者需根据业务复杂度选择集成方式。
Q&A
Workday 的“无头化”具体指什么？
Workday 将其 Trusted Agent Platform 变为“无头化”，即开放其 MCP 服务器、对实时 Workday 数据的 SQL 访问以及共享运行时，允许开发者在 Claude Code、Cursor 等工具中构建自己的 HR 和财务代理，但这些代理必须遵循与用户相同的权限、审批和审计规则。
开发者如何接入 Workday 的代理生态？
主要入口是 Agent-Ready Tools，即 Workday 的 MCP 服务器，随 Workday Extend AI 提供。用户使用自己的 Workday 凭证登录，代理只能访问该用户账户有权访问的内容。此外还有 Live Data Query 允许直接对 Workday 数据运行 SQL 查询。
Workday 的代理运行时（Agent Harness）有什么作用？
Agent Harness 是共享运行时，Workday 自身及客户和合作伙伴构建的代理都在其上运行。它向每个代理传递用户身份、组织位置和访问权限，限制代理能做什么，并根据成本和性能选择处理每个任务的模型。
为什么 Workday 认为外部数据湖不适合构建代理？
Workday 认为外部数据湖绕过了访问控制，且无法复制其治理规则。CTO 表示：“你可以导出数据，但无法导出治理数据的规则”，在数据湖中重建这些规则意味着维护 Workday 安全模型的第二份副本，一旦漂移就会全部出错。
Workday 演示了绕过管控的代理会带来什么风险？
演示中，一个连接到自定义 MCP 服务器的代理返回了用户无权查看的职位申请，并在未经批准的情况下将错误员工调换团队。当指向 Snowflake 中的 Workday 数据副本时，同一代理还泄露了 CTO 的薪资。Monroy 指出：“当它失败时，不只是错误答案，而是无人批准的錯誤行动。”
Workday 的代理身份管理与其他厂商有何不同？
Workday 的代理可以拥有最多两个自己的系统账户，称为 Agent System Users (ASUs)，一个代表用户行事，一个用于“环境”工作，每个都有自己的 OAuth 2.0 客户端。而 Salesforce 等厂商正准备让代理使用自己的凭证和权限注册，而非在用户身份下行事。
