是谁授权了这个智能体?弥合智能体式财务中的服务账户归属缺口

一位审计师调出一条在周日凌晨 2 点 14 分把 230 万美元从一个成本中心转移到另一个成本中心的日记账分录。用户字段显示的是 svc_finance_automation。他们问了一个显而易见的问题:这是谁授权的?会议室陷入沉默，因为没有人能回答。这条分录是由一个 AI 智能体在一个共享服务账户下发布的，而这个账户还被另外 14 个自动化流程共用。没有任何线索能追溯回一个人、一次请求或一次审批。智能体完成了它的工作，但控制措施还是失效了。

这如今是涉及 AI 的最常见的财务审计发现，而且原因非常朴素、结构性。智能体被接入 ERP 的方式，和十五年前批处理任务被接入的方式一模一样:通过一个拥有宽泛常设权限的通用技术账户。当这个账户运行的是一段固定的夜间脚本时，这样做还可以容忍。但现在这个账户已经变成了一个推理系统，代表着任何一个碰巧提出请求的分析师做出依赖上下文的决策，这就不能再容忍了。

为什么服务账户这套模式在智能体面前会失效

服务账户存在的意义，是让软件能够在不需要人工输入密码的情况下完成身份验证，这没问题。问题在于这个账户代表着什么。一个批处理任务代表的是它自己:它每晚做同样的事，它的行为就是它的身份。而一个智能体代表的是调用它的那个人，这一点每分钟都在变化。当 FP&A 的分析师要求智能体重新分类一批应计项目时，这个动作属于她的判断,只是通过智能体的执行来完成。如果把这两者都塌缩进 svc_finance_automation 这一个账户，你就抹去了控制层面唯一重要的两个事实:是哪个人的意图触发了这项工作，以及是哪个非人类身份执行了它。

SOX 从来不关心一项控制是由人还是由流程运行的，它关心的是个体问责:任何影响财务报表的动作都必须能够追溯到一个有相应授权的责任方。共享服务账户在这一点上一开始就不合格。当十个智能体和三个定时任务都戴着同一张工牌时，你无法执行职责分离。你无法在不影响其他智能体的情况下撤销某一个智能体的访问权限。你也无法重建意图，而这恰恰是审计师真正会问的问题。

身份管理供应商在 2026 年一直在指出，如今大多数企业中非人类身份的数量已经超过人类，比例从 40 比 1 到 80 比 1 不等。财务领域中这个子群体规模不大，但影响范围极大，因为这些正是被允许触碰总账的身份。把它们当作一群面目模糊的服务账户来治理，正是凌晨 2 点 14 分那条没人能解释的分录出现的原因。

你必须分开保留的两种身份

弥合这个缺口意味着要在每一次智能体动作中记录两件截然不同的事，并拒绝让它们混为一谈:

• 非人类身份。 智能体本身需要拥有自己的一等身份，而不是借用别人的。独立的凭证、限定范围的权限、一个记录在案的所有者、一个生命周期。当智能体被下线时，它的访问权限也随之终止。当它出问题时，你能精确撤销这一个身份的权限，不多不少。
• 人类主体。 是那个经过身份验证、通过其会话、请求或常设委托启动这项工作的人。这就是能回答“这是谁授权的”这个问题的归属，也是共享服务账户会摧毁的那部分。

安全团队把这称为双重归属:把每一个特权动作同时绑定到执行它的机器身份和触发它的人类身份上。智能体是以自身身份行动，但代表一个具名的人。两部分都要每次被记录，且不可篡改。如果一个智能体在没有任何人参与链条的情况下行动，比如一次定时运行或一个自主循环，这一点也必须被明确地记录下来，并追溯到批准这种自主性的政策和所有者，而不是被悄悄归入某个通用账户。

这个区分之所以重要，是因为这两种身份回答的是不同的问题。非人类身份回答的是被允许做什么、实际运行了什么。人类主体回答的是谁应该负责。一次审计两者都需要，而一个单一的用户字段两者都装不下。

身份是必要的，但不是充分的

在这里，我要承认身份工作的局限，因为很多治理项目也正是在这里过早止步的。知道谁授权了一个智能体，并不能告诉你它产出的数字是否正确。你完全可能在一个悄悄出错的数字上拥有无懈可击的双重归属，比如一个自信地报告了一个在 LLM 内部自行计算出的利润率、编造了一次核对、或者取用了一个过期余额的智能体。归属让错误变得可追溯，但它不能阻止错误发生。

所以归属只是信任体系的一层，而不是全部。另一个伴随的问题，即你能否为这个数字本身辩护,正是我们在记录决策而不只是记录动作的审计轨迹中所探讨的:记录推理过程和输入，而不只是数据库写入操作。而智能体在无人监督时究竟被允许做到什么程度这个问题，则是四层自主性框架所讨论的主题。身份告诉你是谁，决策日志告诉你为什么，自主层级告诉你能走多远。这三者你都需要，这也正是我们正在构建的智能体式 AI 信任层的意义所在。

落地实践是什么样子

一种可行的模式，来自身份治理团队目前实际弥合这些审计发现的方式:

1. 为每个财务智能体建立独立身份,纳入一个中央清单，并映射到一个业务负责人和一个风险等级。智能体绝不能使用共享的 svc_* 账户，任何时候都不行。
2. 权限按任务范围限定,而不是按平台限定。一个读取应收账款以起草催收摘要的智能体，不需要总账的写入权限。常设的宽泛授权正是凌晨 2 点 14 分那种情况的成因。
3. 在每个动作上同时打上两种身份的标记,即智能体和人类主体，加上令牌范围、时间戳，以及触发它的请求。让日志不可篡改。
4. 把执行绑定到一个确定性的层，而不是模型本身。 这是大多数身份管理项目会遗漏的部分，因为这是一个财务问题，而不是安全问题。当智能体需要一个数字时，它应该从一个与账本对得上的已核对模型中检索，并让任何计算都经过一个确定性引擎运行，这样你精心归属的这个动作，也是一个你能够从实质上进行辩护的动作。

最后这一点正是 Rexfin 存在的意义。我们坐在你的 AI 和你的会计系统之间，包括 QuickBooks、Xero、NetSuite、Sage、SAP、Oracle、你的数据仓库，或是上传的报表，并构建出一个与账本对得上的单一已核对财务模型。智能体从中检索数字，并把计算交给一个确定性引擎处理，而不是在模型内部计算。所以当审计师问是谁授权了这条分录时，你有记录在案的人和智能体;当他们问这个数字是否正确时，你能把它追溯到源头。归属与正确性，都在同一个动作上得到保障。

结论

服务账户归属缺口不是一个你可以留到以后再修补的边缘情况。它是一个决定自主财务是否能够存在于受 SOX 管控环境中的根本性问题。一个审计师无法归属的智能体，就是一个审计师会告诉你必须关闭的智能体。每一个动作都对应两种身份，即运行它的机器和授权它的人，这是底线，而不是上限。先把这个底线建好。

如果你正在努力为你的财务智能体建立可归属、可辩护的数字支撑,预约演示,我们会向你展示能让这一切站得住脚的已核对模型和确定性执行层。