以前做权限系统，我一直觉得“身份”这件事很清楚。

人用账号登录，服务拿 API Key，机器用证书通信。只要账号体系、Token、权限表和审计日志设计清楚，身份这件事基本就算闭环了。

直到最近看企业把 AI Agent 接进财务、合同、审批这些真实业务系统，我才发现这个抽象有点不够用了。

因为 Agent 既不是传统意义上的人，也不是一个普通后台服务。

它可以理解任务、调用工具、读取数据、生成报告，甚至协助推进业务流程。它进入企业系统时，到底算谁？

这里说的“身份证”，不是给 Agent 随便建一个账号，而是让 Agent 在企业系统里拥有一个可识别、可验证、可追责的数字身份：它是谁、属于谁、谁负责、能在哪个业务场景运行、当前是否有效。

这也是很多企业不敢让 Agent 真正进入生产系统的第一个问题：系统不知道“谁在操作”。

一个典型场景：财务付款 Agent 为什么迟迟不能上线

假设一家企业准备上线一个财务 Agent。

它的目标并不激进，不是直接替人付款，而是帮助财务同学完成付款前的资料核对。

比如用户输入一句：

“帮我核对 A 供应商 5 月待付款资料。”

Agent 接下来会读取 A 供应商的发票，匹配采购订单，查询合同付款条款，检查金额、税号、付款主体是否一致。如果发现发票金额和合同条款不一致，它会整理差异说明，生成付款建议，并在审批系统里创建一份付款申请草稿，等待财务人员确认。

从业务价值看，这个 Agent 很有吸引力。

Demo 阶段，大家看到的是：它能帮财务同学少做大量重复核对，把原来半小时的工作压缩到几分钟。

但到了上线评审，安全、IT、财务负责人看到的是另一件事：一个可以读发票、查合同、碰审批系统的自动化执行者，正在进入高敏感业务流程。

于是他们会连续追问：

• 这个 Agent 是谁创建的？
• 它属于哪个部门？
• 谁负责维护它？
• 它调用财务系统时，用的是谁的权限？
• 它能不能导出付款明细？能不能修改供应商账户？
• 如果它生成了错误付款建议，事后能不能追溯到具体 Agent？

这时候问题就变了。

企业不是不知道 Agent 有价值，而是不确定它是否可控。

尤其当 Agent 开始接触合同、发票、付款信息这类敏感数据时，企业需要的不是“相信 AI 会判断”，而是一套能回答责任、边界和追溯的机制。

其中第一步，就是要先回答：这个 Agent 到底是谁？

Agent 不能一直躲在共享账号后面

很多团队做 Agent 集成时，一开始会选择最简单的方式：

• 复用某个员工账号；
• 使用一个统一服务账号；
• 给 Agent 配一组 API Key；
• 把多个系统权限混在一个 Token 里。

短期看，这样做最省事，Demo 也最容易跑通。

但问题是，系统看到的只是“某个账号发起了一次请求”，并不知道背后真正执行任务的是哪个 Agent。

一旦出问题，企业很难回答：

• 是哪个 Agent 发起了这次操作？
• 它当时处于什么业务场景？
• 它是否还在有效期内？
• 它的责任人是谁？
• 它为什么拥有这项能力？
• 后续是否应该继续允许它访问财务数据？

如果这些问题回答不上来，Agent 就很难进入生产系统。

它不是一个真正可管理的数字员工，而更像一个藏在服务账号后面的自动化脚本。

给 Bot 建个账号，为什么还不够

有人可能会说：那给每个 Agent 建一个账号不就行了吗？

这只能解决一小部分问题。

账号解决的是“能不能登录”。

但企业真正需要的，是一个可管理、可验证、可追责的 Agent 身份。

如果继续用“身份证”这个比喻，它至少要包含三类信息。

第一类是“这是谁”。

这张身份证上要写清楚 Agent ID、名称、用途、所属组织、责任人、创建时间、当前状态。企业要能把一个 Agent 当成独立对象管理起来，而不是只在日志里看到一串 Token。

第二类是“怎么证明它是真的”。

系统不能只相信一个字符串凭证，而要能验证当前发起请求的，确实是这个 Agent，而不是某个冒用它身份的脚本，或者某个泄露出去的 Token。

第三类是“这张身份证还是否有效”。

Agent 可能会变更责任人、调整业务场景、更新证书，也可能被暂停、恢复或停用。企业需要知道它的身份状态和生命周期，而不是只在创建时登记一次。

也就是说，Agent 身份不只是“登录凭证”，而是企业治理体系里的一个独立主体。

只有先确认“谁在操作”，后面才能继续讨论“它能操作什么”“是否越界”“出了问题由谁负责”。

如果要产品化，这张身份证应该怎么设计

我们在做 VeriAgent 时，把 Agent 数字身份拆成了几个更具体的问题。

第一个问题：怎么证明这个 Agent 是谁？

这里可以用 X.509 数字证书和 mTLS 双向认证。Agent 调用企业系统时，系统可以校验证书是否由可信 CA 签发、是否在有效期内、是否被吊销。Agent 侧也可以校验服务端身份，降低请求被冒用或劫持的风险。

第二个问题：怎么证明关键内容没有被改过？

这里可以用 Ed25519 数字签名保护关键身份信息、请求摘要和调用信息。它解决的不是“AI 会不会判断错”，而是“关键数据和操作证据是否还能被信任”。

第三个问题：怎么证明事情发生在某个时间点？

这里可以用可信时间戳证明关键认证、签名、调用和审计事件发生的时间，避免事后补写或篡改时间线。

第四个问题：关键证据以后还能不能查？

这里可以对关键认证材料、签名结果和审计证据做备案存证，为后续合规审查和责任追溯提供证据基础。

这些听起来像安全基础设施，但放在 Agent 场景里，本质是在解决同一件事：

证明这个 Agent 确实是它自己，并且企业知道它属于谁、谁负责、现在还能不能继续工作。

回到财务 Agent

如果这个财务 Agent 要读取发票、查询合同、生成付款申请草稿，企业首先要知道：

它是“财务付款核对 Agent”，归属于财务共享中心，由某个业务负责人维护，只允许在付款核对场景下运行，并且当前身份状态有效。

系统侧还可以通过证书、双向认证、签名、时间戳和存证记录，证明这个 Agent 的身份、通信过程和关键操作证据都可验证。

这样，Agent 就不再只是“一段代码 + 一个系统账号”。

它开始变成一个企业可以识别、可以管理、可以追责的数字主体。

为什么这是 Agent 进入生产系统的第一步

企业不是不想用 Agent。

很多时候，业务团队甚至比安全团队更希望 Agent 尽快上线，因为它确实能减少重复劳动、提升流程效率。

但一旦 Agent 开始进入关键业务系统，企业首先要解决的不是模型能力问题，而是治理主体问题：

• 谁在操作？
• 属于谁？
• 谁负责？
• 是否有效？
• 出问题能不能追溯到主体？

如果没有独立身份，后面的权限、工具调用、审计都没有明确主体。

所以这里说的“身份证”，不是一个普通账号，而是 Agent 在企业系统里的数字身份。

企业级 Agent 可信落地的第一步，就是先让 Agent 拥有这样的数字身份。先让系统知道“谁在操作”，再讨论它能调用什么工具、能做到哪一步、出了问题如何复盘。

想听听大家的看法

我们当前也在 VeriAgent 里优先从 Agent 数字身份切入：为 Agent 建立独立身份，绑定组织、责任人、业务场景和证书状态，让企业能识别、验证和管理 Agent。

如果你们已经把 Agent 接进内部系统，现在是给它独立身份，还是先让它复用员工账号、服务账号或 API Key？这个问题在上线评审时会不会被安全团队卡住？

• VeriAgent 官网：https://www.veriagent.ai/