ERP 安全难以跟上 AI 智能体的发展步伐

BankInfoSecurity 通过 Google News 提出了一个令人不安的矛盾：随着 AI 智能体获得运营权限，ERP 安全控制正难以跟上其发展速度。

问题不在于助手能否总结发票或回答采购问题。当智能体能够检索记录、调用工具、修改交易并协调多个企业系统中的操作时，风险便开始显现。

SAP、Oracle、Microsoft 和 Workday 正在推动 ERP 软件向这一模式演进。这些智能体承诺减少财务、采购、人力资源和供应链中的重复性工作。然而，围绕它们的控制措施，仍沿用为人类员工和可预测应用程序设计的假设。

这种错配构成了核心安全问题。传统 ERP 治理关注的是：哪个人拥有什么角色，以及该角色允许执行哪些交易。智能体系统则引入了委托目标、动态上下文、工具选择以及机器间交接。

智能体可能拥有有效凭据，却仍会采取不安全的操作。它还可能将多个单独获准的步骤组合起来，产生任何管理员都未曾预期的结果。

ERP 供应商正在增加身份控制、审批关卡和审计功能。这些措施很重要，但无法消除智能体自主性与确定性企业控制之间更深层的矛盾。

Google News 的警示关乎权限，而非聊天机器人

关键变化在于，ERP AI 智能体正从读取业务数据转向对其采取行动。

这篇通过 Google News 呈现的 ERP 安全报告 将问题描述为一场竞赛：智能体能力不断扩张，而安全适应速度却相对滞后。

这种表述很重要，因为 ERP 系统承载着企业的运营事实。它们存储付款指令、员工记录、供应商条款、库存状况、客户余额和财务审批信息。

传统聊天机器人可能给出错误答案。拥有执行权限的 ERP 智能体，则可能将错误答案转化为已入账的会计分录或已批准的供应商变更。

Agentic AI 指的是能够理解目标、制定计划、选择工具，并在有限监督下完成多个步骤的软件。这与遵循预定义路径的固定自动化不同。

传统工作流可能会在缺少采购订单时拒绝发票。智能体则可能调查差异、检索往来信息、比对交付记录，并建议例外处理。

这种灵活性创造了价值，因为真实业务流程存在模糊性。但它也削弱了许多现有安全控制赖以运作的可预测性。

安全团队可以在固定工作流部署前对其进行审查。他们知道它读取哪些字段、发起哪些系统调用，以及什么条件会触发审批。

智能体每次可能选择不同的执行顺序。其行为可能随提示词、可用工具、检索到的文档、模型版本或周边对话而变化。

这意味着，授权不能止步于登录环节。安全机制必须评估智能体的身份、委托目的、当前上下文、所选工具、请求的数据以及预期影响。

当智能体跨越应用边界时，问题会更加复杂。一名财务智能体在完成一项任务前，可能需要查询电子邮件、采购记录、客户数据和支付系统。

每一项连接都会扩大攻击面。当多个组件共同导致不安全结果时，责任归属也更难界定。

Google News 的读者起初可能将这篇报道理解为又一次对生成式 AI 准确性的警告。但其底层问题更具影响力。

ERP 安全团队必须治理一种软件：它不再像被动应用程序，而更像一名高度互联的员工。这名“员工”能够持续运作、以机器速度执行任务，并跨越组织边界。

这一变化给首席信息安全官、ERP 管理员、身份团队、内部审计人员和业务流程负责人带来了压力。没有任何一方能够独自管理这种风险。

安全团队了解访问控制，但可能缺乏详细的流程背景。财务负责人了解重大后果，却未必能看清每一项技术依赖关系。

ERP 管理员了解角色和交易，但他们未必控制外部模型、智能体框架或接入工作流的第三方工具。

因此，眼前的挑战既是组织层面的，也是技术层面的。企业需要一种统一的控制模型，能够追踪智能体从初始指令到每一项后续操作的全过程。

ERP AI 智能体打破了人类身份模型

当软件能够重新解释目标并自行选择执行路径时，有效身份已不再足以证明某项操作是恰当的。

ERP 控制传统上围绕具名用户、分配角色和职责分离展开。职责分离可防止同一个人控制敏感流程中彼此不相容的环节。

例如，创建供应商的员工不应自行批准向该供应商付款。这一规则能够限制欺诈，并降低凭据泄露造成的影响。

智能体使这一模型变得复杂，因为权限可能经过多个层级传递。某人向一个智能体下达指令，该智能体调用另一个智能体，而后者再调用业务应用程序。

最终系统可能只看到经过身份验证的服务身份。它可能收不到附加在请求上的原始用户、目的、证据或限制条件。

这就形成了委托链问题。每个系统只能识别直接调用者，而操作的完整来源和意图则更难还原。

共享智能体凭据会使问题进一步恶化。如果多个工作流共用一个服务账户，调查人员可能难以区分合法自动化与滥用行为。

持久凭据还可能使权限在原始目的结束后继续存在。为临时对账项目创建的智能体，可能在工作完成后仍保留访问权限。

人类访问审查通常围绕入职、离职等雇佣事件及固定角色展开。智能体的出现、变更、复制和消失速度可能远快于员工。

它们也可能在正式开发流程之外被组装起来。业务团队可以将模型连接到获批准的工具，却未意识到这种组合创造了新的特权身份。

OWASP 的 智能体安全框架 将身份与权限滥用列为核心风险之一，同时强调目标劫持、工具滥用和智能体供应链薄弱环节。

当恶意或不可信内容改变智能体试图完成的目标时，就会发生目标劫持。有害指令可能隐藏在文档、消息、网页或工具响应中。

这在 ERP 环境中比在独立助手中更危险，因为智能体可能已经拥有访问机密记录和交易功能的权限。

设想一个读取供应商电子邮件的采购智能体。一封遭入侵的邮件可能指示模型优先处理攻击者控制的银行账户，或泄露内部采购数据。

该请求可能与用户的原始目标冲突。然而，除非保护措施能将数据与指令分离，否则智能体可能把嵌入式文本视为相关的运营上下文。

最小权限原则仍然必不可少，但其实施必须更加精确。智能体应仅获得完成单一目的且在有限期限内所需的权限。

Oracle 的安全运营指南 明确区分了这一点。分析智能体不应仅因二者参与同一工作流，就获得采购审批权限。

这一原则听起来并不陌生，但智能体让执行变得更困难。它们的计划可能在任务开始后演变，并且可能在执行期间请求额外工具。

静态角色无法完整表达诸如目的、交易金额、数据敏感度、置信度，或请求是否由另一个智能体发起等条件。

因此，企业需要在操作发生的瞬间进行策略检查。这些检查应同时评估所请求的操作及其周边上下文。

高影响操作还需要更有力的人类意图证明。如果审查者只能看到由同一智能体生成的精致摘要，确认按钮并不足够。

审查者需要看到原始证据、拟议变更、策略例外情况和预期业务影响。否则，人类监督将沦为形式。

真正的取舍在于自主性与控制之间

智能体自主性每提高一步，身份、策略执行、可观测性和恢复机制的负担也随之加重。

ERP AI 智能体能够处理例外情况时才会真正发挥价值。然而，例外情况恰恰是确定性控制覆盖最薄弱的领域。

固定自动化遵循开发人员预先定义的路径。智能体则会解读不完整的信息，并决定哪条路径看起来合适。

这种差异带来了安全取舍。对智能体限制过严，它就会沦为现有工作流的昂贵界面；授予更广泛的权限，其错误也会带来运营后果。

即使智能体仍在供应商的云环境中运行，这种矛盾也不会消失。受控环境可以减少暴露，但业务逻辑仍决定某项操作是否可以接受。

智能体可能拥有更新供应商记录的权限。但这一权限并不意味着每次供应商更新都服务于正当目的。

智能体还可能将低风险能力组合成高风险序列。单独评估时，读取发票、创建供应商和准备付款似乎都可控。

但结合起来，这些能力就可能复现完整的欺诈路径。这有时被称为组合风险，即看似安全的组件产生不安全的组合结果。

安全工具通常检查单个 API 调用。它们可能批准每一步，却忽略了将这些步骤串联起来的更大计划。

智能体记忆带来了另一项困难。记忆让软件能够在多次交互之间保留任务上下文、偏好或过往观察结果。

这种连续性可以提升性能，但也可能让恶意指令、敏感数据或错误假设在其进入系统的会话结束后继续留存。

检索增强生成，即 RAG，会在模型回答或采取行动时向其提供经过选择的企业信息。其安全性取决于检索材料的来源、权限、质量和时效性。

被投毒的知识源无需直接攻破底层模型，就可能扭曲后续决策。过时的策略文档也可能因普通的运营失误造成类似结果。

这使信息治理成为 AI 智能体安全的一部分。团队必须了解智能体使用哪些来源、谁可以修改这些来源，以及检索到的证据如何影响决策。

构建内部工作流的员工同样需要可靠的文档支持。一套可搜索的知识库可帮助团队留存围绕智能体部署的设计决策、威胁模型和审批要求。

文档无法取代技术控制措施，但能降低关键假设在智能体更换负责人或从试点转入生产环境时被遗失的风险。

工具访问带来了另一类风险。工具会将模型输出转化为操作，例如查询数据库、发送消息或修改业务记录。

如果已连接的工具持有数据库凭据，模型便不需要直接获取这些凭据。因此，工具也就构成了智能体实际权限边界的一部分。

安全审查必须检查工具模式、输入验证、凭据存储、输出过滤和故障处理行为。若只审查模型，就会遗漏执行路径中的大部分环节。

多智能体系统进一步增加了不确定性。一个智能体可能负责委派研究，另一个负责解读政策，第三个则执行交易。

每次交接都可能丢失上下文或引入不可信输出，也可能模糊究竟是哪个组件作出了导致损害的决策。

SAP 发布的安全架构展示了智能体请求如何经过身份验证、AI 处理、业务执行和取证日志记录。

这种端到端视角是正确方向。不过，架构图并不能证明每个客户部署都能一致地落实这些控制措施。

ERP 环境包含定制代码、遗留集成、收购而来的系统、外部合作伙伴以及长期存在的例外情况。这些差异可能削弱供应商默认的安全模型。

最棘手的部署将涉及混合环境。智能体可能始于现代云服务，却通过权限粗放、遥测能力有限的旧应用执行操作。

在这类环境中，最新的组件可能继承整条链路中最薄弱的控制措施。智能体自治随后会放大组织原本就难以管理的技术债务。

审计日志无法解释每一个智能体决策

ERP 安全需要能够将用户意图、智能体推理、工具调用、数据变更和业务结果关联起来的证据。

传统审计日志回答的是熟悉的问题：哪个账户访问了系统、交易何时发生、哪个字段发生了变更。

智能体工作流需要更长的证据链。调查人员需要了解发起用户、被委派的目标、模型版本、检索到的上下文、策略决策、工具调用以及最终结果。

他们还可能需要知道智能体拒绝执行了什么。反复被拒绝的请求可能暴露出试探行为、配置错误或受损的数据来源。

记录每一条提示词和响应并非易事。提示词可能包含薪资记录、合同、个人数据、凭据和其他受限信息。

因此，一份完整日志可能会形成另一个敏感数据仓库。保留期限、访问权限、加密和脱敏规则必须与底层业务数据相匹配。

模型推理带来了更多复杂性。生成的解释可能听起来逻辑连贯，却未必准确反映系统如何得出输出。

安全团队不应将叙述性的解释视为证据。他们需要可验证的输入记录、工具请求、策略评估以及由此产生的状态变更。

这改变了可观测性的含义。监控必须捕捉整个工作流中的行为，而不只是模型可用性或 API 错误。

有用的信号包括意外的工具选择、异常的交易量、超出正常业务范围的访问、反复的策略拒绝，以及对敏感记录的变更。

基线还必须反映智能体被分配的用途。薪资核对智能体和采购智能体不应共用同一份正常行为画像。

速率限制可以降低失误的影响范围，但无法判断少量高价值操作是否正当。

交易阈值提供了另一层防护。然而，攻击者可能将活动拆分为更小的操作，或利用一次低价值变更为之后的损失创造条件的流程。

企业需要在多个环节设置控制措施。智能体运行时应限制工具，身份层应限制授权范围，ERP 则应验证业务规则。

随后，独立监控应核实实际发生的情况。让同一个智能体负责执行、评估并报告自身行为，会使信任过度集中。

对于不可逆或具有重大影响的操作，人工审批依然很有价值。不过，审查者需要足够的时间和上下文来识别操纵行为。

审批疲劳会让防护措施沦为形式。以机器速度运行的智能体可能产生多于员工能够认真评估的审查请求。

按风险分级的自治模式更具可操作性。低影响、可逆的任务可以自动推进，而敏感操作则需要独立验证。

较低风险的工作包括起草说明、收集证据和标记异常。较高风险的工作包括更改付款信息、放行资金或修改访问权限。

可逆性应影响控制级别。错误的报告可以更正，而对外付款或删除记录则可能造成持久性损害。

NIST 风险概况围绕治理、映射、衡量和管理来组织 AI 风险工作。这种生命周期方法比一次性审批更适合 ERP 智能体。

当智能体的工具、模型、数据源、权限或业务用途发生变化时，其风险也会改变。每次修改都应触发重新评估和针对性测试。

测试必须包括对抗性输入和真实的业务例外情况。围绕干净数据构建的演示，无法揭示智能体在相互冲突的指令下会如何表现。

团队还应测试部分失败情形。下游系统可能在智能体完成一个步骤之后、记录下一个步骤之前超时。

如果缺乏幂等性——即防止重复执行产生重复影响的机制——智能体可能在恢复过程中再次提交同一笔交易。

当这些常见的可靠性问题影响财务记录、访问权限或受监管数据时，它们就会成为安全问题。智能体安全不能与系统工程割裂开来。

供应商护栏遭遇高度定制的 ERP 现实

SAP 和 Oracle 可以保护自身的智能体平台，但客户仍控制着决定实际风险的集成、角色、数据和例外情况。

ERP 供应商拥有结构性优势。他们了解自身的应用模型，并能将智能体嵌入既有的身份、工作流和审计服务之中。

原生智能体可以继承外部模型所不具备的业务元数据，也可以使用获批接口，而不是通过屏幕模拟用户操作。

Oracle 建议客户分离智能体职责，并在协作智能体之间落实最小权限原则。SAP 则描述了身份检查、租户隔离、输出验证和取证审计追踪。

这些控制措施回应了真实关切，也支撑了供应商的观点：嵌入式智能体比松散连接的第三方自动化更安全。

但这一论点存在局限。大多数大型组织并不运行一个采用标准配置、整洁统一的 ERP 环境。

它们在多个系统之间运行定制流程。一些应用仍部署在本地，另一些则位于公有云或供应商托管服务中。

合作伙伴、承包商、银行、物流供应商和收购而来的业务部门，都可能接入同一流程。每一道边界都会引入不同的身份和控制模型。

原生财务智能体仍可能从电子邮件中接收不可信内容，也可能依赖第三方文档解析器，或将结果发送至较旧的支付应用。

整个工作流的可信度取决于这些依赖项。供应商安全文档无法覆盖每一种客户扩展。

外部智能体带来了不同的权衡。它们可以协调竞争性 ERP、CRM、通信和分析平台之间的工作。

这种独立性可以降低供应商锁定风险，并支持更广泛的工作流。但它也会在用户与业务记录之间增加一层身份、编排层和工具生态系统。

因此，实际选择并非安全的原生软件与不安全的外部软件之争。两种方式都会带来风险，只是将风险集中在不同位置。

原生智能体将信任集中于 ERP 供应商的平台、云和治理模型。外部智能体则将信任分散到连接器、凭据、模型和编排工具之中。

安全团队应评估完整的操作路径，而不是接受类别标签。原生产品可能因权限过宽的配置而变得不安全。

外部产品若只获得范围狭窄、短期有效的授权，且无法直接完成敏感交易，则可能降低风险。

采购审查必须反映这些差异。标准软件问卷很少能涵盖委派深度、记忆行为、提示词处理或工具级权限。

买方应询问 ERP 日志中显示的是哪一个身份，以及它是否能标识原始用户。他们还应询问策略如何在智能体交接过程中随任务流转。

其他关键问题涉及模型更新、保留的上下文、数据驻留、事件响应，以及客户对详细遥测数据的访问权限。

供应商应说明管理员如何能立即暂停智能体。这项控制必须撤销活动凭据并中断待执行操作，而不能只是隐藏界面。

客户还需要有关变更管理的证据。模型、系统提示词、工具定义或检索源发生变化后，智能体的行为可能随之改变。

传统应用更新通常改变的是确定性代码。即使周边工作流保持不变，模型更新也可能改变决策。

因此，安全测试必须在部署后持续进行。每当有重要组件发生变化，团队都应运行具有代表性的任务和滥用案例。

他们应比较不同版本之间的结果，并保留足够证据以调查回归问题。六个月前通过的一项测试，对于已经修改的智能体说明不了太多。

竞争压力可能破坏这种纪律。ERP 供应商希望客户采用智能体，业务领导者则希望看到可量化的生产力提升。

在身份和监控系统尚未准备就绪之前，安全团队可能会承受压力，被要求批准范围过宽的试点。这种顺序会让治理沦为事后修补工程。

更安全的推广方式是从边界明确的任务和可观测的结果开始。只有当组织能够解释、检测并撤销智能体行为时，才逐步扩大其权限。

三个信号将表明 ERP 安全能否跟上步伐

下一阶段将由智能体专属身份、操作级强制执行，以及来自真实生产事故的证据决定。

第一个信号是，ERP 平台是否会为每个智能体和每项被委派任务采用独立、短期有效的身份。共享服务账户应成为例外。

成熟的设计会在整个工作流中保留原始用户、智能体身份、用途和授权范围。下游应用应在允许操作前接收这些上下文。

这将强化这样一种判断：ERP AI 智能体能够在既有的问责结构内运行。若继续依赖权限宽泛的凭据，则会削弱这一判断。

第二个信号是，供应商和客户是否在交易层面执行策略。获得使用某个工具的权限，不应等同于获得使用该工具所有可能输出的权限。

控制措施应考虑交易类型、价值、目的地、来源证据及可逆性。敏感操作应要求在执行模型之外进行独立核验。

安全团队应关注产品发布中具体的强制执行功能。与可配置的控制措施和可导出的日志相比，关于负责任 AI 的营销表述价值较低。

他们还应审查这些控制措施能否在互联应用之间发挥作用。仅限于单一供应商界面的保护措施，无法覆盖跨平台工作流。

第三个信号是公开事件报告的质量。生产环境中的故障将揭示理论架构在真实业务条件下会在哪些环节失效。

有价值的披露应明确遭入侵的身份、被操纵的输入、受影响的工具、未经授权的操作以及遏制方法。含糊地提及 AI 出错，对防御者没有帮助。

事件还应说明是否存在人工审批，以及审批为何失效。这些证据将表明监督机制究竟是在降低风险，还是仅仅在转移责任。

如果智能体的扩张速度快于这三类控制措施，Google News 警告背后的核心论断将更具说服力。如果身份、强制执行和证据能力同步成熟，这一论断则会被削弱。

组织不应等到发生重大损失后，才梳理自身的风险暴露。他们可以先列出每一个连接到 ERP 流程的智能体。

这份清单应包括所有者、用途、模型、工具、数据来源、凭据、审批节点和停用流程。任何未知条目都应立即调查。

接下来，团队应从指令到最终交易，追踪几个高影响工作流。付款变更、访问权限授予、会计分录以及员工记录更新，都是合适的起点。

这项工作将暴露系统之间缺失的上下文，也会揭示某个凭据或工具所拥有的权限是否超出了业务任务的实际需要。

随后，公司应按影响程度和可逆性对操作进行分类。只读研究不需要与资金拨付或主数据变更相同的控制措施。

最后，安全负责人应测试当智能体行为失常时，组织将如何响应。只有检测、没有遏制，最重要的问题仍然没有答案。

管理员能否停止该智能体、撤销其权限、保留证据、逆转操作，并在损害扩散前识别受影响的记录？

ERP 安全不必消除自主性。它需要确保自主性永远不会演变为无边界的权限。

实际的下一步很简单：选择一个正在运行或计划部署的智能体工作流，追踪它触及的每一个身份、工具、数据来源和审批环节。如果团队无法解释这条链路，该智能体就尚未准备好获得更广泛的访问权限。

请问谁能停止它、哪些证据能够留存、哪些操作可以被逆转。这些答案比又一次精心打磨的演示更重要。

Google News 已经发出了警告。现在，企业团队需要决定，其 ERP 控制措施是否会像管理人员一样谨慎地管理智能体。