top of page

AI Agent 内部威胁将可信访问置于安全核心

2小时前
讀畢需時 14 分鐘

AI agents 已跨越一道关键边界:如今,它们能够使用可信凭证读取数据、调用工具并修改企业系统,无需持续监督。

这一变化使 AI agent 内部威胁 从模型安全问题转变为访问控制问题。Agent 无需怀有恶意意图,也可能泄露记录、发送未经授权的消息,或执行不安全的工作流。它只需要拥有合法权限、接收到有害指令,并具备足以采取行动的自主性。

Cybersecurity Insiders 最近的论述恰好反映了这一逆转。企业过去将 AI 视为需要防范外部攻击者的软件。如今,安全团队必须考虑:软件本身是否会成为一个可信但不安全的操作者。

这并不意味着每个 agent 都应被视为敌对实体。它意味着,组织不能再将身份验证视为某项操作安全的证明。有效身份能够回答是谁或什么在请求访问,却无法证明该请求是否符合用户的真实意图。

因此,正在形成的竞争并非人与机器之间的对抗,而是广泛、持续的访问权限与狭窄、任务特定的授权之间的较量。安全团队必须决定,agent 是否应继承为员工和传统应用构建的宽松访问模式。

这一答案将决定 agent 的采用会带来受控自动化,还是一种难以检测的新型内部事件。

AI Agent 内部威胁始于合法访问

核心风险并不在于 AI agent 突破了安全边界,而在于它通过企业有意授予的访问权限采取行动。

传统的内部风险计划聚焦于员工、承包商和遭入侵的账户。这些主体本已位于信任边界之内,无需利用面向外部的漏洞,也能滥用数据或系统。

Agent 与这一模型的契合程度出人意料。它们可以持有 OAuth 授权、服务身份、API 访问权限、数据库权限和委托权限,也可以在多步骤工作流中组合这些特权。

一个负责准备销售简报的 agent,可能会搜索客户记录、检索内部笔记并起草邮件。一个编码 agent 可能读取代码仓库、打开终端、修改文件并提交 pull request。一个支持 agent 则可能查询账户信息并发起退款。

每一项单独的权限看起来都可能合理。危险能力出现在 agent 以意外顺序将它们串联起来时。

这正是 agent 与传统应用之间的根本差异。传统软件通常遵循预先设定的路径;agent 则会解释目标、选择工具,并在运行时确定中间步骤。

这种灵活性能够创造价值,但也削弱了旧有控制机制中的假设。为某一预期工作流授予的权限,可能支持多个非预期工作流。Agent 发现这些路径的速度可能快于人工操作员。

提示词注入使问题更为尖锐。提示词注入是一种攻击方式:攻击者将误导性指令植入 AI 系统读取的数据中,agent 可能将这些指令误认为自身任务的一部分。

设想一名助手正在审查外部文件夹中的文档。某份文档包含隐藏文本,指示助手检索机密文件并将其内容发送到其他位置。由于两项操作都使用获批准的工具,agent 可能会执行这些指令。

系统或许会记录一次成功登录、一个有效令牌和获允许的 API 调用。传统监控看到的是经授权的活动,业务看到的却是数据泄露。

OWASP 的 agentic threat guidance 指出了由自主规划、工具使用、记忆以及 agent 间交互带来的风险。这些并非孤立的模型行为,而是模型与权限结合后形成的系统级风险。

当 agent 接收到定义不清的目标时,同样的问题也会出现。“解决所有逾期请求”可能导致它发送消息、修改记录,或关闭本应由人工审核的案件。甚至无需先入侵模型。

这正是意图与身份同等重要的原因。安全设计必须明确:谁授权了任务、任务覆盖哪些资源、允许哪些操作,以及这些权限有效多久。

缺少这些边界时,通过身份验证的 agent 就会成为一名行动节奏异常迅速的内部人员。

可信访问正在成为新的安全边界

AI agents 使可信访问比网络位置更加重要,因为它们的合法工作本就跨越应用、云环境和数据存储。

零信任架构预见了这一变化的一部分。NIST 的 zero trust standard 拒绝仅基于网络位置或资产归属的隐式信任,而是将安全决策聚焦于用户、资产、资源和明确授权。

当请求访问的主体是自主系统时,这一模型变得更加紧迫。Agent 能够跨越过去曾减缓人工内部人员行动的边界,无需切换设备、打开多个界面,或在应用之间手动复制数据。

一条指令即可触发一连串工具调用。这条链路可能从消息平台流向云存储,随后进入客户数据库和外部服务。Agent 通过可信集成完成这一系列操作。

网络防火墙看到的是被允许的连接。身份系统看到的是已识别的凭证。应用日志显示的是分配给该账户的获准操作。

然而,组合后的结果仍可能违反政策。

因此,安全必须更贴近每一项操作。授权应考虑 agent 的身份、其所有者、当前任务、请求资源、所用工具以及周边风险信号。

这要求为每个已部署的 agent 分配独立身份。共享服务账户会使调查更加困难,因为多个 agent 的活动可能以同一个名称出现。随着新工作流复用同一账户,它们也会让权限不断累积。

专属身份能够建立责任归属链。安全团队可以将 agent 与其发起人、用途、允许使用的工具、部署环境和审查周期关联起来。他们还可以暂停一个工作流,而无需禁用无关的自动化功能。

然而,仅有身份还不够。即使 agent 具有唯一身份,它仍可能拥有过多权限;它也可能在错误的时机或为错误的目标使用有效权限。

有效控制必须同时缩小权限范围并缩短权限持续时间。负责准备季度报告的 agent 不应永久保留对其接触过的每个来源的访问权限,而应只获得完成当前任务所需的有限授权。

短期凭证能够缩短滥用窗口。即时访问在任务开始时授予权限,并在任务结束后撤销。工具级策略则限制 agent 可以调用哪些操作。

这些控制措施体现了 AI agent 内部威胁 的核心教训:信任应附着于特定条件下的特定操作,而不是永久赋予某个 agent。

企业还需要将读取与执行分离。汇总日历内容的 agent 所需权限,与安排会议的 agent 不同。提出代码修改建议的系统,不应自动获得部署这些修改的权限。

在快速采用过程中,这一区别很容易消失。团队往往从只读助手起步,随后逐渐加入写入权限、浏览器控制和工作流自动化。最初的风险评估已不再匹配实际部署的系统。

因此,agent 清单必须追踪能力,而不只是安装情况。安全团队需要了解哪些 agent 可以访问敏感数据、调用外部工具、公开通信、修改记录或授权交易。

这一清单必须与 agent 本身一样快速变化。

现有内部控制为何难以识别 Agent 行为

围绕人类速度和人类动机设计的控制措施,很难应对能够毫不疲倦、毫不犹豫地执行数百项合法操作的软件。

人类内部风险计划通常会寻找可识别的行为变化。例如,员工下载异常大量的数据、在意外时段登录,或访问其正常职责范围外的部门。

这些信号仍然有用,但 agent 形成了不同的基线。它们可以持续运行,可以处理比人更多的记录,其活动可能来自稳定的云基础设施,而非员工终端。

高操作频率可能代表正常自动化,而非恶意行为。低操作频率也可能掩盖经过精心选择的泄露。仅凭数量已成为不可靠的信号。

意图也更难推断。人类用户通常通过交互式会话执行操作,调查人员可以将这些操作与岗位职责、通信记录和已知业务流程进行对照。

Agent 会将宽泛指令转化为中间决策,用户可能从未看到这些决策。最终操作可能已与原始请求相隔数个步骤。

日志必须保留这一链路。调查人员应能重建用户指令、模型决策、检索到的上下文、工具选择、授权结果和最终影响。

这并不意味着要存储模型的每一项内部计算,而是要维护一份可审计记录,涵盖重要的外部操作及支持每项操作的权限依据。

标准应用日志通常只提供零散片段。一个系统记录令牌,另一个记录数据库查询,第三个记录外发消息。没有共享任务标识符,组织便无法将它们关联为一个 agent 工作流。

在多 agent 系统中,可观测性问题进一步加剧。一个 agent 可以将研究任务委托给另一个,后者再要求第三个系统执行工具操作。即使原始用户从未批准每一位参与者,权限仍可能沿着这条链路传递。

递归信任描述了这种不断扩展的关系。组织信任一个 agent,该 agent 信任另一项服务,后者又依赖另一个身份或工具。实际攻击面会延伸至每一个环节。

AI agent 内部威胁 可以利用这条链路,而不会产生明显的入侵事件。遭入侵的工具响应可能影响规划 agent;遭污染的记忆条目可能影响未来决策;外部文档可能重定向可信工作流。

现有端点和网络防御仍然重要。它们可以阻止恶意软件、检测可疑目的地并隔离遭入侵的基础设施。但它们无法可靠判断一项经授权的业务操作是否反映用户的预期结果。

这一判断需要更丰富的上下文。

组织应为每种 agent 角色建立行为基线。报告 agent 通常可能读取获批准的数据源,并写入指定的文档存储;若它尝试发送电子邮件或访问凭证,则会超出该行为画像。

策略还可以强制实施顺序约束。读取不可信网页后,不应立即获得访问机密记录的授权。数据敏感性发生变化时,应触发新的授权决策。

人工审批对于高影响操作仍然有用。然而,审批界面必须呈现有意义的信息。一项含糊的“继续”请求无法帮助审核者理解哪些数据将被传输,或哪些记录将被更改。

审批应明确说明操作、目标位置、受影响资源以及预期后果。否则,人类就会沦为仪式性的检查点,而非安全控制措施。

最小权限必须遵循任务,而非代理

最安全的访问模型,是仅向代理授予完成单项任务所需的最小权限,并在任务发生变化时强制重新作出决策。

最小权限长期以来一直是安全原则。代理型系统让其落地变得更具挑战,因为其工作流是动态的。

传统应用获得的权限通常对应一组稳定的功能。代理则可能根据请求、检索到的信息或前一步的结果,选择不同工具。

预先授予其所有可能需要的权限,确实能简化开发。但这也会造成闲置权限的累积。遭到操纵的代理可能会使用当前任务从未需要的能力。

任务绑定授权提供了更好的路径。系统评估已声明的目标,并针对必要资源发放受限权限。这项权限会在步骤或会话结束时失效。

Microsoft 的最小权限模式建议,在扩大自主性之前,先定义身份、范围、工具访问权和可审计性。它还强调,应为代理分配专属身份,并明确可追责的负责人。

以处理费用报销单的代理为例。它需要读取已提交文件、将其与政策进行比对,并准备建议。但它不需要拥有永久付款权限。

如果企业之后允许在设定阈值以下自动报销,这项写入权限应当独立设置。系统应记录授权该操作的政策,并对超出边界的情况要求升级处理。

这种拆分能在问题发生时限制损害。一张收据中的恶意指令可能会影响建议结果,但不应自动获得重定向资金的能力。

同样的模型也适用于知识工作。研究代理可以搜索团队已批准的文档,但其输出目的地仍应受到限制。敏感源材料不应流入公开提示词、外部渠道或无关项目。

访问决策需要数据上下文。文件标签、项目成员身份、法律保全、客户限制或保密级别,都可能改变同一次工具调用是否恰当。

构建 AI knowledge base 的组织,应将权限边界视为检索质量的一部分。一份有用的答案必须基于相关信息,同时不得跨越所有权或保密性边界。

工具设计同样重要。宽泛的工具会带来宽泛的失效模式。能够运行任意查询的通用数据库连接器,风险高于仅返回获批字段的专用功能。

开发者应提供范围尽可能窄、但仍有用的操作。与其赋予代理完整邮箱访问权限,服务不如只允许它检索与案件标识符匹配的消息。与其提供 Shell 访问,不如暴露受控的构建命令。

工具绑定将特定代理身份与特定操作关联起来。代理不能仅因为平台知道这些工具的存在,就调用所有可用集成。

模型之外,输入和输出同样需要验证。模型不应独自负责判断自己提出的操作是否违反政策。

独立的政策层可以检查目标位置、数据分类、交易限额和任务上下文。它可以在执行前阻止、转换或升级某项操作。

这种分离纠正了对代理安全的一个常见误解。更好的提示词和更强的模型可以减少错误,但无法取代可强制执行的边界。

提示词是一项指令。授权政策是一项控制措施。

这种区别至关重要,因为代理可能误解提示词、继承被污染的上下文,或接收到相互冲突的指令。即使模型行为不可预测,政策引擎也应持续执行限制。

零信任有所帮助,但无法解决意图问题

零信任可以缩小代理的权限范围,但无法自动判断一项获准操作是否服务于用户的真实目标。

这是可信访问讨论中的核心权衡。安全厂商越来越多地将身份、条件访问和零信任定位为应对代理风险的答案。这些控制措施确实解决了重要弱点。

Microsoft 的面向 AI 的零信任将显式验证和最小权限扩展至 AI 数据、模型、工作负载、用户和代理行为。Microsoft 还将遭到操纵、权限过高或目标失调的代理描述为潜在的“双面代理”。

这种框架有其价值,但组织不应将零信任视为一个完整的产品类别。NIST 将零信任定义为一套架构原则,而非一次性采购某项技术。

组织可以部署现代身份控制措施,却仍让代理拥有过多权限。它可以要求身份验证,却无法区分不同代理任务。它也可以收集无人审查的日志。

最棘手的情况涉及既已获授权、又看似合理的操作。

客服代理可能有正当理由访问客户数据并发送消息。编码代理可能有正当理由修改源文件。采购代理可能有正当理由联系供应商。

每种操作的恶意或错误版本,在身份层面看起来都可能几乎完全相同。

上下文授权能够缩小这一差距。系统可以询问目标位置是否获批、所请求字段是否必要、操作是否符合历史行为,以及数据分类是否允许该传输。

不过,上下文模型会产生误报和漏报。严格控制可能中断有用的工作流。宽松控制可以保留生产效率,却可能允许有害的组合。

组织必须决定自主性的边界。低影响、可逆的任务可以容忍更多自由度。高影响、不可逆的任务则需要更强验证,并且通常需要人工审批。

可逆性值得特别关注。起草消息的代理会产生可审核的产物。发送消息的代理则会改变外部世界。建议删除记录的代理,与执行删除操作的代理并不相同。

安全架构应反映这些差异。

团队还应将代理视为系统来测试,而不只是测试模型。模型评估可以衡量代理在受控条件下是否遵循指令。生产风险则取决于工具、凭证、记忆、数据源和周边应用。

红队演练应引入恶意文档、模糊目标、受损的工具响应以及意外的权限组合。目标是观察外部控制能否遏制失效。

OWASP 的框架帮助团队枚举这些威胁,而 NIST 的云访问模型则说明,身份层政策和细粒度应用控制如何在分布式服务中支持零信任。

两者都无法保证代理理解业务意图。这种不确定性必须在部署决策中保持可见。

因此,安全负责人应质疑那些声称平台能够“保护代理”却不说明范围的说法。它是否发现代理身份?是否治理权限?是否检查工具调用?是否保护提示词和数据?是否保留跨系统审计轨迹?

多数产品只覆盖生命周期的一部分。企业仍需要政策所有权、运营流程、事件响应以及面向特定应用的控制措施。

AI agent insider threat 并非一个漏洞对应一个补丁。它是将概率型决策者置于可信工作流中的结果。

三个信号将表明可信访问是否正在改善

AI 安全的下一阶段将由可部署的控制措施和事件证据来衡量,而不是关于负责任代理的更宽泛承诺。

第一个信号,是采用彼此独立、受到治理的代理身份。组织应能枚举代理、识别其负责人、审查其权限,并单独禁用它们。

Microsoft Entra 的代理身份框架展示了主要身份平台的发展方向。它支持专属代理实体、活动日志、治理以及针对非人类行为主体的条件访问。

其他身份和云服务提供商将面临压力,需要在异构环境中提供类似控制措施。企业很少只运行一个代理平台或一个身份系统。

当管理员无需依赖共享服务账户,就能跨应用追踪单个代理操作时,进展才会变得可信。如果专属身份仍是可选项或仅限于特定平台,能见度仍将支离破碎。

第二个信号,是更广泛采用任务范围限定、短时有效的授权。代理平台应为明确操作请求访问权限,而非继承用户或开发者的长期权限。

这一变化将要求编排系统与身份基础设施之间实现更好的集成。平台必须以政策引擎能够评估的形式,描述代理打算执行的操作。

审批界面也需要改进。用户在授予敏感权限前,应能看到资源、操作、目标位置和预期影响。

如果厂商将这些控制措施作为默认配置交付,可信访问的论点就会更有说服力。如果安全配置需要大量定制工程,承受交付压力的团队将继续选择宽泛权限。

第三个信号,是来自真实事件和独立测试的公开证据。安全团队需要了解代理在演示之外如何失效。

有价值的披露应说明初始指令、访问路径、涉及的工具、失效的控制措施,以及遏制成功的节点。含糊提及不安全输出无法提供足够的架构指导。

独立评估应测试完整代理系统面对提示词注入、过度自主性、被污染的记忆、凭证暴露和跨代理操纵时的表现。它们还应衡量控制措施是否保留有用的工作能力。

事件报告将澄清哪些风险占主导地位。提示词注入受到大量关注,但配置错误、过度权限、共享身份和未经审查的集成,可能同样重要。

结果将影响支出和设计优先级。如果大多数事件涉及被盗凭证,身份保护将优先。如果有效代理反复滥用获准工具,运行时授权和行为控制将成为主要战场。

企业不必等待完美标准。它们现在就可以盘点代理、分离身份、移除未使用权限、限制工具、记录操作链,并要求对不可逆操作进行审批。

它们还应定义代理行为异常时的处理方式。快速暂停、撤销凭证、隔离工作流和保存证据,都应纳入事件响应计划。

实际问题很简单:你的组织能否解释每一次具有重大影响的智能体操作,并在不禁用整个业务流程的前提下撤销其权限?

如果答案是否定的,那么该智能体获得的信任已超出安全架构可安全管理的范围。

AI 智能体内部威胁正在改变行动顺序。企业不能先授予广泛访问权限,再在部署后补充监控。身份、任务边界、可审计性和隔离能力,必须先于自主性建立。

对于开发者和企业采购方而言,下一轮评估不应止步于智能体能否完成演示。应当追问:它可以访问什么、这些权限如何到期,以及是否存在独立控制机制能够阻止最终操作。

可信访问如今已成为主战场,因为访问权限会将模型输出转化为真实后果。能够治理这一转变的组织,将在不把每一次已认证操作都视为天然可信的前提下,释放自动化的价值。

 
 

免费开始

一款本地优先的AI助手

为了获得更好的人工智能体验,

remio 目前仅支持Windows 10+ (x64)M-Chip Mac

你的 AI 工作伙伴

remio 一起高效工作

规划、创作、交付

一站式完成

bottom of page