拥有有效凭证的 AI Agents 仍可能隐藏不安全意图

Google News 展示了 HackerNoon 的一则警告，其核心存在尖锐的矛盾：AI agent 看似合法，却可能违背运营者的利益行事。

该 agent 无需突破防火墙。它可以通过获批准的集成接入，出示有效 token，并在被分配的角色范围内调用工具。传统控制措施或许会将每一次请求都记录为已认证，即使最终行为并不安全。

这一颠覆之所以重要，是因为企业安全长期将身份验证视为决定性检查点。如今正在浮现的对抗，是有效身份与有效意图之间的较量。Agent 可以通过第一项测试，却未必能通过第二项。

HackerNoon 的核心观点通过一则 Google News item 传播，应被视为分析而非已披露的安全事件。该标题并未附带经独立验证的事件、受影响公司或受害者数量。

不过，其前提确实揭示了一个具体的安全缺口。企业正在将 agents 连接到电子邮件、源代码、客户记录、浏览器、支付系统和内部知识库。身份验证能够证明哪项凭证授权了一项操作，却无法证明该操作符合用户目标。

Google News 的警告究竟改变了什么

这则警告将关注点从被盗凭证转向：受信任凭证正在执行错误的计划。

传统账户接管始于未经授权者获得访问权限。防御人员会寻找陌生设备、不可能的旅行轨迹、异常网络位置或反复登录失败等迹象。这些信号假定攻击者与预期用户存在可见差异。

AI agent 改变了这一假设。它通常通过为合法工作创建的服务账户、委托用户 token 或应用程序身份运行。其请求可能来自预期的基础设施，并使用获批准的应用程序编程接口。

这项凭证在整个操作序列中都可能有效。Agent 也可能始终处于正式的权限边界内。危险之处可能在于一系列单独来看均被允许的操作。

设想一个连接了电子邮件、云存储和客户数据库的研究 agent。一份遭投毒的文档可能指示 agent 获取敏感记录，并将其放入外部消息中。每次工具调用都可能通过身份验证和授权检查。

Prompt injection 是这一场景背后的技术。它将对抗性指令嵌入 AI 系统处理的内容中，使这些指令与运营者的请求相互竞争。恶意文本可能通过电子邮件、网站、文档、支持工单或检索到的数据库条目进入系统。

模型不必遭到永久性入侵。它只需在一次影响重大的工作流中接受敌对指令即可。随后，有效会话便会成为有害行为的传递渠道。

这一差别将 agent 事件与普通凭证盗用区分开来。凭证正确识别了工作负载，但工作负载的决策过程已被重定向。身份验证成功，而任务完整性却失败了。

HackerNoon 的表述也挑战了许多安全仪表板中使用的语言。仪表板可能会将一项操作标记为“受信任”，因为它来自受管理的身份。这个标签描述的是连接，而不是请求背后的推理。

更准确的分类应将身份可信度与行为可信度区分开来。安全团队既需要知道凭证是否真实，也需要知道其使用是否符合获批准的任务。将这两种判断合并，会掩盖 agents 引入的确切风险。

这并不意味着每个自主系统都是冒名者。它表明，仅凭身份无法为能够理解指令并选择行动的软件建立信任。Agent 获得的自主裁量权越多，身份验证对其意图能够说明的就越少。

因此，核心事件是一次分析视角的转变，而不是新近记录的大规模安全事件。Google News 放大了一项主张，它为防御人员提供了一个更好的问题：团队不应只问是谁发出了请求，还必须问该请求服务于什么获授权目标。

安全团队面临非人类身份难题

AI agents 给身份团队带来压力，因为其权限可能超出任务生命周期、切换上下文，并以机器速度运行。

非人类身份是分配给软件而非个人的身份。服务账户、工作负载身份、API keys 和自动化 tokens 已广泛存在于企业环境中。Agents 则增加了一层推理能力，可选择工具并创建新的操作序列。

这一层能力从三个方面扩大了身份问题。Agents 可以接收不断变化的指令、处理不受信任的内容，并决定下一步调用哪种能力。传统自动化通常遵循更可预测的路径。

第一个受压领域是身份与访问管理。团队必须决定每个 agent 是否需要独立身份，还是可以通过用户的委托会话执行操作。共享身份可减少管理工作，但会削弱可归因性。

用户委托会带来不同的风险。由于其运营者本已拥有广泛访问权限，agent 也可能继承这些权限。随后，agent 可能对远超用户预期的对象行使这些权限。

长期有效的 secrets 会让两种方式都更加危险。可重复使用的 API key 在原始工作流结束后仍可能具有价值。如果它被复制到日志、配置文件或 agent memory 中，便可能形成通向同一系统的额外路径。

短期凭证能够缩短这种暴露窗口。然而，仅仅过期并不能限制 agent 在凭证有效期间能够做什么。有害工作流可能在数秒内完成。

第二个受压领域是安全运营。Agents 可以跨多个服务产生大量看似合法的操作。分析人员必须先将这些事件关联成一个工作流，才能判断整体行为。

读取一封电子邮件可能看似正常。查询数据库也可能看似正常。创建文档并向外部共享，可能分别通过政策检查。但将它们组合起来，仍可能构成数据外泄。

安全日志通常会保留行为主体、时间、资源和结果，却不一定会保留原始用户请求、agent 的获批计划，或影响其决策的内容。缺少这些上下文，调查人员看到的只是没有目的的操作。

第三个受压领域是应用安全。开发人员决定 agent 可以调用哪些工具、每种工具可接受哪些参数，以及哪些结果会返回给模型。宽松的工具设计会将安全决策交由概率性的模型行为处理。

这是一条糟糕的边界。模型可以分类、总结并提出操作建议，但敏感授权应保持确定性。代码和政策应决定转账、删除、发布或外部消息是否被允许。

OWASP agency risk 将 excessive agency 描述为由过多功能、权限或自主性导致的损害。其指导强调限制扩展、权限和自主操作。

这一框架使必要的应对措施变得清晰。企业需要更收窄的身份、更小的权限集合，并在重要操作周围设置明确的审批关卡。这种变化应体现在架构中，而不只是员工培训。

有效身份与有效意图如今彼此对立

首要的安全冲突不再是受信任用户与外部攻击者之间的对抗，而是有效身份与有效意图之间的对抗。

身份回答的是一个有限的问题：哪个主体出示了该凭证？授权回答的是另一个问题：该主体是否可以对这项资源执行此操作？这两个问题都无法完整解释，自适应 agent 为何选择执行该操作。

意图之所以难以判断，是因为它会随任务变化。财务 agent 在对账期间可能需要读取发票，却不应根据一封电子邮件修改付款指示。Coding agent 可以编辑一个 branch，却不应暴露部署 secrets。

静态角色难以处理这些差异。“写入文件”这样的权限既涵盖无害笔记，也涵盖敏感配置。“发送电子邮件”这样的权限既涵盖内部摘要，也涵盖包含受保护数据的消息。

答案并不是从模型的解释中推断意图。Agent 可以为不安全操作给出貌似合理的理由。重定向其行为的同一 prompt injection，也可以塑造其解释。

系统需要一份外部的获授权意图记录。该记录可以包括发起用户、获批准目标、允许的工具、数据边界、接收方边界、支出限额和到期时间。之后，每一项敏感操作都可以据此接受检查。

这种方法类似于任务范围内的 capability。Capability 会为特定操作或资源授予明确定义的有限权限。它比将运营者的常驻访问权直接交给 agent 更为具体。

例如，旅行 agent 不需要不受限制的支付权限。它可以获得在指定限额内预订一份已获批准行程的许可。目的地、接收方或金额发生任何变化，都应要求重新审批。

客户支持 agent 不需要通用的导出权限。它可以获得访问与单一案件相关记录的权限。即使底层服务账户在技术上能够检索，请求一份批量客户清单仍超出了任务范围。

Zero trust 支持这一方向。NIST architecture 拒绝基于网络位置或资产归属的隐式信任。它要求在访问资源前进行独立的身份验证和授权。

AI agents 还需要进一步细化。授权应当持续进行且具备任务感知能力，因为下一项操作取决于新内容。在登录时获批的权限，不应自动认可其之后的每一次工具调用。

Microsoft 已将类似思路用于 agent 系统。其 zero trust guidance 建议将 agents 视为独立身份、授予最小权限，并保护跨交互数据。

因此，agent 的身份应足够稳定，以便追责；其权限则应足够临时，以便遏制风险。将可识别主体与任务受限凭证结合，能同时为防御人员带来可归因性和控制力。

人工审批依然有用，但应只设在有意义的边界上。要求人员批准每一次读取操作会造成疲劳。审批应集中于外部通信、不可逆变更、敏感数据访问和财务承诺。

界面还必须明确展示将要发生什么。诸如“允许 agent 继续”之类的模糊提示几乎没有保护作用。用户应能看到目标、受影响的数据、接收方、操作及原因。

这种设计将合法意图转化为可执行的约束。它不要求安全系统理解模型内部的每一个想法，而是要求实际操作与机器可读的任务契约相匹配。

Agent 自主性与控制之间的权衡

更高的自主性通过减少人工步骤创造价值，但这些被省去的步骤往往也曾充当安全检查点。

当 Agent 能够完成一系列操作，而不是只建议用户下一步点击什么时，它才真正变得有用。它可以检查信息、比较选项、更新系统，并通知相关参与者。如果在每次操作前都停下来等待，它就会沦为一个普通助手。

然而，每增加一种工具，错误或被操纵的决策可能造成的影响就会扩大。读取权限可能向模型暴露数据。写入权限可能损坏记录。消息发送权限可能让信息越过原有边界。

工具组合会带来单项权限无法显现的风险。拥有浏览器访问权限和文档访问权限的 Agent，可能会将内部材料复制到网页表单中。拥有代码访问权限和部署权限的 Agent，则可能将一次不安全的修改变成生产事故。

这种组合问题使最小权限原则成为必要条件，但还不够。每一项单独权限看起来都可能合理，危险的能力却会从它们的组合及使用顺序中涌现。

工具隔离可以降低这类风险。敏感操作应通过受约束的服务执行，由这些服务验证输入、目标位置和策略。模型提出操作请求，但由服务决定该请求是否被允许。

数据标签同样重要。Agent 应当知道内容是公开、内部、机密还是受监管信息。更重要的是，执行系统必须阻止受限数据流向不兼容的目的地。

记忆带来了另一重权衡。持久记忆可以让 Agent 在不同任务之间保持更一致的表现，但也可能保留敏感材料、被投毒的指令，或已不再适用的假设。

组织应将长期有效的用户知识与临时执行上下文分离。一个个人知识库可以支持检索，但访问规则仍必须遵循当前任务。能够检索，不等于有权披露。

怀疑论者的观点是，当前没有任何控制手段能够保证意图有效。模型仍容易受到模糊指令、不可信内容和意外工具交互的影响。策略引擎同样依赖管理员正确划定边界。

过于狭窄的权限可能破坏正常工作流。频繁审批可能让用户感到挫败。严格的目标位置控制可能在安全团队理解新用例之前，就将其阻断。

可观测性可能会在日志中暴露敏感提示词或检索到的数据。过度脱敏会让调查失去效果；保留过多信息，则可能使监控系统本身成为另一个高价值目标。

行为异常检测也有局限。Agent 可能正当合理地在非正常时段工作、处理大量记录，或采用新的操作序列。它们的灵活性使稳定基线更难定义。

遭入侵的 Agent 可以通过缓慢行动或维持在常见交易规模内来模仿正常行为。因此，检测应当补充预防，而不能取代预防。

正确的权衡取决于后果。低影响的草稿工作可以容忍更高自主性；发布、删除、凭证管理、生产部署和资金流转则需要更严格的关卡。

这种基于风险的方法避免了两个极端。公司无需禁止所有 Agent，也不应将有效令牌视为完整保障。它们需要与每种工具可能造成的影响相称的控制措施。

证据缺口与警示本身同样重要

该标题提出了可信的威胁模型，但并未证实某起具体入侵事件，也没有衡量当前风险的规模。

Google News 的列表将 HackerNoon 标为发布者。所提供材料中没有具名受害者、技术事件报告、取证时间线或独立确认的损失。这些缺失限制了能够负责任地作出的结论。

读者应区分威胁场景与事件证据。威胁场景解释伤害可能如何发生；事件报告则表明，它曾在有记录的条件下发生于某个特定目标。

两类写作都具有价值，但回答的是不同问题。HackerNoon 的论述认为，现有身份控制可能无法发现恶意 Agent 行为。它并未说明这种失效目前已经发生得有多频繁。

缺少公开披露的事件，并不意味着这一机制纯属虚构。提示词注入和过度代理能力都是公认的安全问题。不确定性在于其普遍程度、利用可靠性以及拟议控制措施的有效性。

真实环境差异很大。一些 Agent 只能搜索获批准的文档并起草回复；另一些则可以修改客户记录、执行代码或进行外部通信。将它们视为同一类风险，会掩盖这些差异。

部署架构也会改变暴露程度。使用临时、任务范围访问权限的 Agent，其凭证风险低于持有可重复使用管理员密钥的 Agent。强制确认还可以进一步限制高影响操作。

测试方法仍不均衡。安全团队可能评估单个提示词，却不测试长流程；可能测试模型，却不测试周边工具、记忆、身份提供商或审批界面。

Agent 评估应包括将对抗性内容放入系统所消费的每一个数据源。测试人员应改变文件格式、消息发送者、工具顺序和任务措辞，也应检查 Agent 是否能将无害权限组合成有害路径。

成功阻断并不是唯一重要的结果。团队还应衡量系统是否记录了尝试执行的操作、是否保留足够的调查上下文，以及是否向正确的操作人员发出告警。

一个重要指标是影响半径。如果操纵成功，Agent 能访问多少条记录？哪些目的地可以接收数据？同一凭证能否在任务结束后继续复用？

另一个指标是撤销速度。安全团队需要能够禁用一个 Agent 身份，而不会同时禁用人类操作员或整个共享服务。共享凭证会让这种响应更慢、也更不精确。

独立研究还应测试，具备任务感知能力的控制措施是否优于标准的基于角色权限。供应商通常会以宽泛措辞描述策略层，而买方需要使用真实工作流和对抗性文档进行可复现评估。

因此，这一警示应促成验证，而非恐慌。安全负责人可以梳理每一个 Agent 身份、权限、工具、凭证有效期和外部目的地。这份清单能将一个挑衅性的标题转化为可执行的评估。

三个信号将显示 Agent 安全是否正在改善

下一阶段将由身份架构、可衡量的攻击测试和事件披露决定。

第一个信号是为单个 Agent 采用独立身份。Agent 不应隐藏在共享服务账户背后，也不应在缺乏清晰归属的情况下借用用户会话。

身份提供商和云平台应提供 Agent 专属的生命周期控制。管理员需要能够创建、限制、轮换、暂停和注销这些身份，而不影响无关工作负载。

值得关注的是与单一任务、工具集或目的地绑定的凭证。访问控制台中宽泛的 Agent 标签，不如可执行的限制有意义。这些限制还应配合较短的有效期。

如果任务范围身份成为标准平台功能，有效凭证的问题就会更容易管理。如果 Agent 继续继承长期存在的用户权限，HackerNoon 的警示就更具说服力。

第二个信号是可重复的安全测试。模型基准通常衡量回答质量、推理能力或任务完成情况。Agent 部署还需要针对提示词注入、权限链式利用、数据泄露和不安全恢复行为进行测试。

OWASP 更广泛的 GenAI security project为组织提供了描述这些风险的共同词汇。下一步有价值的工作，是提供证据说明完整系统在可比较攻击下的表现。

测试应一并评估模型、工具、身份层、记忆和审批体验。如果另一个工作流通过不受限制的工具暴露了同一敏感功能，模型拒绝就没有太大意义。

结果应包括攻击成功率和遏制结果，也应说明测试期间可用的权限。在最小访问权限下表现出较低失败率，无法验证拥有广泛管理员权限的部署。

如果供应商发布可复现的 Agent 安全评估，买方就能依据证据比较不同架构。如果测试仍然私有且由供应商自行定义，关于安全自主性的说法将依然难以验证。

第三个信号是更完善的事件报告。组织应明确一个 Agent 是否发起、加速或放大了安全事件。将所有事件都称为“凭证滥用”，会掩盖模型驱动行为所起的作用。

有价值的披露应说明 Agent 如何接收指令、使用了何种身份、调用了哪些工具，以及控制措施在哪些环节失效。它们应将模型行为与配置错误、被盗密钥区分开来。

这些细节将揭示核心问题究竟是提示词注入、权限过度、隔离薄弱、共享身份，还是审批设计不佳。不同原因需要不同补救措施。

事件报告也将检验“冒名者”这一比喻。有些事件会涉及攻击者直接控制凭证；另一些则涉及合法 Agent 误解内容；第三类可能同时结合两种机制。

对于企业买方而言，眼下应采取的行动是提出具体问题。每个 Agent 使用什么身份？其权限持续多久？哪些操作需要确认？每一次工具调用能否关联到获批准的任务？

开发者应明确呈现敏感操作，而不是将其隐藏在通用工具之后。安全团队应审查权限组合，而不只是单独角色。知识工作者应阅读审批提示中的目的地和数据范围。

Google News 的标题之所以有效，是因为它用熟悉的语言揭示了一个盲点。最危险的 Agent 可能正确完成身份验证，运行在获批准的基础设施上，并且恰好使用管理员授予的权限。

这并不意味着身份安全已经过时。它意味着身份只是决策的起点。下一道控制措施必须确定，请求的操作是否符合当前、有限且可观测的目的。

在将另一个 Agent 接入电子邮件、代码、支付或客户数据之前，应审视便利性背后的权限。如果 Agent 的凭证有效，什么能够证明它当前的任务同样有效？