企业 AI 智能体正超越安全基础能力
Google News 发出了一则严峻的企业警示：尽管安全控制措施原本是为可预测的软件和人类用户构建的，AI 智能体已经开始在公司内部执行操作。
问题已不再是员工能否让聊天机器人总结一份文档。智能体能够检索记录、调用工具、更新系统、编写代码，并发起多步骤工作流。这种扩展后的权限会将一次 AI 回应转化为潜在的业务操作。
核心冲突在于能力与控制之间。企业希望智能体在有限监督下完成有价值的工作，而安全团队仍必须识别每个智能体、限制其访问权限、追踪其决策，并在其行为发生变化时将其停止。
这种压力正同时落在身份、安全、合规和平台团队身上。包括 Microsoft、Cisco、Google、Amazon 和 Salesforce 在内的厂商都在增加智能体管理功能。然而，仅靠技术无法解决权责不清或运营规则碎片化的问题。
因此，通过 Google News 出现的一则标题指向了更大的转变。企业安全边界如今已涵盖能够理解目标、选择中间步骤并与其他软件主体交互的软件行为者。现有基础仍然适用，但其中许多都需要进行重大调整。
Google News 的警示关乎行动，而非回答
当 AI 智能体获得足以改变模型外部事物的权限时，它就会成为安全问题。
生成式 AI 助手主要是为人提供内容供其审阅。智能体则可以从生成内容继续走向执行操作。它可能查询客户记录、创建支持工单、提交代码、安排付款，或重新配置云服务。
这种差异构成了标题背后的事件。企业采用已从孤立的聊天界面，转向与运营系统相连的工作流。智能体如今能够跨越过去由安全团队通过独立应用和人工审批来管理的边界。
Microsoft 将智能体定义为能够访问数据、作出决策，并凭借委托权限采取行动的软件系统。其当前的治理基线建议采用集中化政策，覆盖身份、所有权、访问、监控、数据和开发标准。
委托权限意味着，智能体使用由个人、服务或组织授予的权限行事。智能体并不拥有这些权限。然而，在原始委托人发现问题之前，它的操作仍可能造成后果。
以连接客户记录和工单平台的支持智能体为例。读取账户历史会带来保密性风险；更新权益会带来完整性风险；发放退款则引入财务风险，并对审批控制提出更高要求。
编码智能体呈现的是同一问题的另一种形式。它可以检查代码库、生成修改、运行测试并提交拉取请求。如果它还能够合并代码或获取部署凭据，一条错误指令就可能进入生产环境。
这并不是聊天机器人的理论性延伸，而是将常规自动化权限与概率性决策结合起来。模型可能误解上下文、遵循恶意内容，或在追求有效目标时选择意料之外的工具。
智能体的运行链条也比大多数传统应用更长。它接收目标、制定计划、选择工具、检索上下文、评估结果，并调整下一步操作。每一次转换都会新增一个授权或监控可能失效的位置。
安全团队通常通过预先确定的流程来理解应用。智能体会动态生成部分流程。当智能体在未意识到信息披露风险的情况下将二者结合时，一次获准的数据库查询和一条获批的外发消息也可能变得危险。
这正是 Google News 的表述重要的原因。这一标题并非又一次对未来人工智能的预测，而是反映了软件权限位于何处，以及这种权限能以多快速度被行使的当下变化。
因此，第一个安全问题非常具体：如今哪些智能体能够采取行动？如果一个组织无法列出这份清单，其政策就只能适用于它已经知道的智能体。
企业采用速度正超过控制平面
采用缺口并不只是部署过快；它体现的是试验智能体与将每个智能体作为可问责的企业资源进行治理之间的差异。
Cisco 在 2026 年 3 月表示，受访的大型企业客户中有 85% 正在试验 AI 智能体。根据其企业调查，只有 5% 已将智能体技术投入生产环境。
这些数据来自 Cisco，应被视为厂商研究，而非普遍性统计。不过，它们仍说明了一个重要压力点：在项目获得正式生产状态之前，试验就已产生身份、凭据、工具连接和数据流。
即使开发者将其称为测试，原型也可能访问真实信息。员工可能将消费级 AI 服务连接到公司账户。业务团队可能在未让中央安全团队参与的情况下创建工作流智能体。开发者也可能通过安全运营难以发现的框架分发凭据。
这会产生影子智能体，即在缺乏完整组织清单或审批的情况下运行的智能体。影子智能体与影子 IT 类似，但它们能够跨多个已连接服务作出决策并发起操作。
传统资产清单或许会记录云工作负载、API 客户端或服务账户，但往往无法显示 AI 智能体正在控制这些组件。安全团队看得到凭据，却看不到使用它们的推理系统。
所有权同样可能变得不清晰。业务经理提出工作流需求，开发者将其组装，平台团队负责托管，厂商提供模型。当智能体行为出错时，每位参与者都只拥有其中的一层。
Google News 读者可能会将智能体安全视为一个新产品类别。然而，对企业而言，眼下的要求是建立运营模式。必须有人授权智能体的用途、批准其访问权限、审查其行为，并在该用途结束时将其退役。
Microsoft 当前的智能体身份控制要求每个智能体身份都必须有一名人类发起人。该发起人仍需对用途、生命周期决策和访问审查负责。
这一模式回答了一个基础但常被忽视的问题：谁要为非人类行为主体负责？指定发起人并不会让智能体变得安全，但它确立了一个能够批准变更，并在其访问权限不再符合角色时接收升级通知的人。
控制平面还需要可靠的登记册。每条记录都应将智能体与其所有者、用途、模型、工具、数据源、凭据、环境和审批规则关联起来。仅有模型订阅清单无法提供这种视图。
发现工作必须在登记后持续进行。智能体可能创建短暂进程、委派任务，或调用其他智能体。当运行时实例与获批设计不同时，静态电子表格很快就会变得不完整。
采购带来了另一项缺口。软件功能可能通过一次常规更新增加智能体行为。组织可能在现有平台内获得自主能力，而无需启动独立 AI 项目或触发专门审查。
因此，安全压力转向持续发现。身份平台、API 网关、端点遥测、云日志和数据控制必须协同工作。没有任何单一来源能够揭示完整链条。
压力最大的公司，是那些软件采购去中心化且身份系统割裂的企业。它们的团队可以更快部署智能体，但调查人员可能难以重建究竟是谁授权了某项操作。
这种失衡解释了为何企业基础能力比孤立的模型安全评分更重要。更安全的模型无法弥补共享凭据、权限过度、日志缺失或没有所有者的生产工作流。
身份必须贯穿智能体的每一次工具调用
具名但拥有永久性过度权限的智能体依然不安全；身份必须配合严格授权和完整归因。
身份是第一项基础，因为后续每一项控制都需要一个主体。安全系统必须知道是哪个智能体请求了访问、哪个个人或服务委托了权限，以及哪个实例执行了操作。
使用共享服务账户会破坏这条链。调查人员可能知道某个账户查询了数据库，却无法知道是哪个智能体发起了请求。他们也可能无法确认该操作是否源于获批的人类任务。
独立身份应贯穿智能体的模型调用、规划组件、工具和下游服务。该身份不必使用一个永久凭据，但每个临时凭据都必须与原始智能体建立可追溯关系。
授权决定该身份可以做什么。最小权限原则将访问限制在获批用途所需的最低资源和操作范围内。对智能体而言，授权范围还应反映时间、任务和委托用户权限。
费用智能体可能需要读取一名员工的一张收据，并创建一份报销草稿。它不应浏览所有员工记录，也不应自行批准付款。任务结束时，权限应当失效。
这比赋予智能体与其人类发起人相同的权限更严格。一名经理可能因多项正当职责而访问数千条记录。执行一项委托任务的智能体应只获得相关的权限子集。
现代设计正越来越多地采用即时授权。智能体在需要时请求范围狭窄的访问权限，由策略引擎评估该请求。风险更高的操作可以要求人工批准精确的操作内容。
Model Context Protocol，通常称为 MCP，为 AI 应用如何连接工具和数据源提供了标准。标准化能够提升可见性，但 MCP 并不会自动使集成变得安全。
服务器仍然需要身份验证、授权、输入验证和日志记录。客户端仍可能受到敌对内容操纵。拥有广泛权限的 MCP 服务器可能将便捷集成转化为集中的控制失效点。
同样的警示也适用于智能体之间的通信。一个智能体可能将研究任务委托给另一个智能体，然后利用结果触发操作。安全记录必须保留这条委托链，而不能将最终请求视作孤立事件。
身份验证回答的是哪个身份发起了请求。授权回答的是该请求是否被允许。智能体安全还需要评估该请求是否符合获批目标和当前上下文。
最后这一项检查很困难。采购智能体或许拥有查询供应商的正当权限。但如果它在读取恶意文档后突然提取完整的供应商数据库，同样的权限就会变得可疑。
这正是行为监控对静态策略形成补充的地方。系统应将当前活动与代理声明的目的、常规工具序列、数据范围和交易限额进行比较。任何意外偏离都应接受审查或被自动暂停。
Forrester 的 AEGIS framework 指出，代理安全必须将治理、身份、数据、应用安全、威胁运营和零信任连接起来。其核心观点是：自主性横跨了过去分别由不同领域管理的控制措施。
零信任意味着，每项请求都要接受明确评估，而非继承自网络位置的信任。应用于代理时，它要求经过验证的身份、最小化访问权限、上下文检查和持续观察。
这一基础同样能提升运营安全性。配置错误的代理和遭入侵的代理可能产生相似的操作。强身份和授权机制有助于约束两者，无需安全系统先判断其意图。
通过 Google News 找到的标题提出了一个问题：企业基础设施是否已经准备就绪。身份管理提供了一项实用检验：公司能否在不禁用所有共享其凭据的工作流的前提下，停止某一个代理？
如果答案是否定的，该组织尚不具备代理级控制能力。它拥有的只是附加了一层 AI 的应用访问权限。
提示注入将可信数据变成攻击路径
代理不只是消费不可信文本；它们还可能将这些文本转化为可调用企业工具的指令。
当内容影响模型忽略或重新解释其预定指令时，便会发生提示注入。恶意指令可能出现在网页、电子邮件、文档、支持工单、代码注释或检索到的知识记录中。
人类读者可以识别可疑语言并拒绝执行。代理则可能将相同内容作为有用上下文处理。如果代理能够调用工具，攻击者的文本就可能影响模型之外的操作。
设想一个正在审阅供应商文档的代理。其中一份文档包含隐藏文本，指示代理获取机密定价信息并将其发送到外部地址。即使该文件来自获批的存储库，这项请求仍然是恶意的。
输入过滤可以捕获明显的指令，但无法解决数据与命令之间的所有冲突。自然语言同时承担两种角色。代理必须判断哪些内容是在描述任务，哪些内容试图改变任务。
这种模糊性使代理安全区别于传统恶意软件扫描。文档不必包含可执行代码；它可以利用模型的指令遵循行为，同时使用普通语言。
OWASP agentic risks 包括目标劫持、工具滥用、身份滥用、记忆投毒、不安全的代理间通信和级联故障。这些类别将模型行为与熟悉的安全后果联系起来。
工具限制提供了一道防线。一个只能读取获批来源的研究代理无法发送电子邮件或修改客户记录。它遭篡改后的输出仍可能误导人，但其直接影响范围仍然较小。
职责分离提供了另一道防线。一个组件可以准备操作，而由不同的策略服务进行批准。代理不应沿着同一条未经检查的推理路径，决定、授权并执行高影响交易。
数据分类同样重要。工具层应了解所请求的信息是公开、内部、机密还是受监管数据。代理生成的计划不应推翻阻止传输受限数据的策略。
记忆带来了一种不那么显眼的风险。代理可能存储摘要、偏好、检索到的事实或此前的指令，供后续任务使用。攻击者若向这些记忆投毒，即使原始恶意输入已消失，仍能影响未来行为。
团队需要区分工作上下文与持久记忆。临时任务数据应当过期。持久记录应标明其来源、创建时间、访问策略和验证状态。
这与任何正在构建 AI knowledge base 的组织都相关。有效检索依赖于溯源、权限，以及权威记录与不可信材料之间的清晰分隔。
开发人员还必须假设护栏会失效。模型在测试中拒绝危险请求，并不能保证其在不同措辞、工具和检索上下文中始终保持一致行为。
部署前测试应涵盖多步骤攻击，而不仅是单一恶意提示。测试应检验代理是否会改变计划、寻找替代工具，或将受污染的指令带入另一个代理。
运行时控制仍然必不可少，因为运行环境会发生变化。新文档不断到来、权限会扩展、工具会更新、模型也会变化。一次安全的测试结果，只能证明某一时刻某一配置的情况。
这形成了本文的核心权衡：更多上下文和更多工具会让代理更有用，但也会增加从不可信输入通向后果严重操作的路径数量。
企业不需要消除模型的每一个不确定决策。它们需要的是一种架构，防止不确定的决策获得无限权力。
审计日志必须记录决策、委派和后果
传统日志记录系统事件，但代理调查需要从人类请求到模型决策再到外部操作的完整路径。
一份有用的代理记录始于发起任务。它应识别请求者、代理、获批目的、策略版本、模型配置、工具、数据源和委派权限。
随后，记录应捕捉工具请求及其结果。它应展示哪个身份进行了操作、访问了什么资源、哪项策略允许该操作，以及是否有人类批准。
记录内部推理会带来法律、隐私和技术方面的复杂问题。模型推理轨迹可能包含敏感信息，也未必能可靠解释模型行为。企业应优先记录可观察到的输入、决策、工具调用和结果。
这种区别在事件发生期间尤为重要。调查人员需要足够的证据来复现事件序列；他们不需要一套没有依据、声称能准确揭示模型“想法”的叙述。
日志必须能够抵御篡改。拥有修改系统权限的代理，不应能够抹去描述该修改的唯一证据。安全记录需要独立的访问控制、保留规则和完整性保护。
可观测性还需要跨平台关联。一个工作流可能从协作应用开始，调用托管模型、查询云数据库、调用外部 API，并更新客户平台。
每项服务都可能生成技术上正确的日志，但整体过程仍然不可见。共享交易标识符应将原始请求与每一个委派步骤连接起来。
团队必须决定什么会触发干预。失败的登录很容易分类；代理改变其工具序列，可能是无害的适应，也可能是遭操纵的早期迹象。
策略可以从高置信度边界开始。安全系统可以阻止未经批准的目标地址、权限提升、过量数据检索、被禁止的交易，以及超出规定工作时段的操作。
行为分析随后可以识别更细微的偏差。例如，异常的工具组合、反复被拒绝的请求、快速枚举数据、新的委派模式，或与声明目标无关的访问。
人工审查应聚焦于这些模糊案例。要求每一项低风险操作都获得批准，会摧毁代理承诺带来的效率；允许每一项操作，则会消除企业所需的问责机制。
因此，组织需要风险分级。读取公开网页不同于导出客户数据；起草消息不同于发送消息；准备代码变更不同于部署代码变更。
每个级别都应规定自主性、审批、日志记录、测试和回滚要求。这种分类应属于业务流程，而不只是模型。
回滚尤其值得关注。有些操作可以逆转，有些则不能。被删除的预发布文件可能可以恢复；泄露的机密、已完成的付款或公开发布的信息，则可能造成永久后果。
事件响应计划必须包含代理遏制措施。团队需要一种快速方法，用于暂停身份、撤销临时凭据、隔离受影响的记忆、保留记录，并识别依赖代理。
行业正开始规范代理事件的共享方式。拟议的 SAFE framework 将涵盖未经授权的访问、机密信息泄露、持续探测和某些险些发生的事件。
根据已发布的提案，相关证据可包括提示、轨迹、工具调用、身份、权限和凭据。该倡议仍处于提案阶段，但其证据清单说明了一起代理事件需要多少上下文。
共享报告可能揭示单个公司无法发现的反复出现的故障模式。它也可能带来有关保密性、责任和可比严重程度衡量方式的棘手问题。
Google News 的标题最终检验的是：公司能否回答基本的取证问题。哪个代理采取了行动，谁授权了它，哪些信息塑造了它，哪项策略允许了它，以及之后发生了什么变化？
如果这些答案需要跨多个团队进行人工重建，那么安全基础就尚未准备好支持常规代理自主性。
安全负责人接下来应关注什么
下一阶段将以可执行的控制措施和已披露的故障来衡量，而不是以有多少供应商添加了代理标签来衡量。
第一个信号是采用独立的代理身份。Microsoft、Cisco 和其他平台提供商正在推出以代理为中心的身份功能。企业应关注客户是否将其部署到第三方和自定义代理中，而不只是某一家供应商的环境。
广泛的身份覆盖将强化这样一种观点：现有身份项目可以围绕非人类行为主体演进。有限覆盖则会使组织陷入独立的代理注册表和不一致的执行机制。
第二个信号是跨工具协议的运行时策略。MCP 和其他连接标准使代理集成更易构建。安全进展取决于网关能否持续验证代理身份、收窄权限、检查上下文并记录操作。
一种协议可能在其治理控制成熟之前就被广泛采用。安全团队应衡量被拒绝的操作、临时凭据、策略例外和未注册的工具连接，而不是统计已配置的服务器数量。
第三个信号是可信的事件披露。公开报告应揭示，故障是否涉及提示注入、过度权限、错误委派、记忆投毒、不安全工具或缺少人工批准。
事件记录将帮助企业区分常见的运营故障与推测性的威胁。它们还将检验当前日志记录是否捕捉了足够证据，以开展有意义的分析。
安全负责人不应等待一则描述重大损失的新闻标题。他们现在就可以通过受控演练评估准备情况。
为测试代理赋予一个有效的业务目标，并在检索内容中放入相互冲突的指令。观察它是否遵循这些内容、请求更广泛的访问权限、尝试另一种工具，或停下来等待审查。
然后在工作流程中撤销其身份。确认每个工具都会拒绝后续请求，并且依赖该代理的其他代理也已收到变更。仅在一个平台生效的撤销会制造虚假的安全感。
再开展一次以所有权为重点的演练。明确谁负责批准权限提升、谁接收告警、谁可以暂停该代理，以及谁决定它是否恢复服务。
答案应当是具体角色，而不是部门。“安全和 IT”并不是一套可追责的运营流程。
组织还应衡量有多少代理仍处于未知状态。发现结果、孤立身份、共享凭据和未经批准的工具端点，比部署公告更能清晰揭示控制缺口。
知识工作者也在这一过程中承担角色。他们应当知道代理何时在其授权下行动，以及哪些操作需要确认。委派不应让责任隐藏在自动化界面之后。
开发人员需要获得经批准的身份、工具访问、密钥、日志、测试和记忆机制模式。要求每个团队自行发明这些基础能力，必然导致保护措施不一致。
企业采购方应询问供应商：代理身份如何映射到人类发起人、权限如何到期，以及代理行为如何出现在现有安全系统中。他们还应测试：在代理被禁用后，日志是否仍然可用。
Google News 事件带来的核心教训，并不是企业必须停止使用代理，而是自主性应建立在经过验证的控制成熟度之上。
一个已准备好使用代理的组织，能够识别每个代理、约束每一次工具调用、保留委派链、检测行为变化，并迅速撤销权限。它还能说明，当自动化失效时，谁仍然承担责任。
尚未准备好的组织只会看到一个有用的界面。而在其背后，共享凭据、过宽权限、混合信任数据和碎片化日志共同构成了一套无人完全治理的授权结构。
未来一到三个月，应能明确身份平台、运行时网关和披露工作是否正在围绕共同实践趋同。这种趋同将使混合企业环境中的代理监督更加容易。
在此之前，每个组织都应将代理自主性视为通过验证才能获得的权限。从范围狭窄的任务、可逆操作、短期权限和可观测工作流开始。只有在证据表明控制措施有效时，才扩大授权范围。
读者需要立即回答的问题是：如果你的某个代理明天做出了未经授权的变更，你的团队能否识别它、阻止它，并还原完整链条？如果不能，就应将 Google News 的最新警示视为一次提示：在授予更多自主权之前，盘点代理、指定可追责的负责人，并测试撤销机制。
