100个AI Agent安全评估结果显示：企业在加速采用前必须重新审视控制边界

100个AI Agent安全评估结果显示：企业在加速采用前必须重新审视控制边界

过去一年，企业对AI Agent的投入显著升温，但安全研究正在提醒市场：越强大的Agent，往往伴随越大的攻击面。据SecurityWeek引用Adversa AI的研究，后者对100个AI Agent进行了安全评估，并基于“AI Risk Quadrant”从三项维度进行比较：被攻破的脆弱性、潜在破坏影响、以及防御控制强度。结果并不乐观——在被测试的100个Agent中，只有11个被归类为“capable well-defended（既有能力又具较强防护）”。

这项研究的重要性不在于某一款产品“是否安全”，而在于它揭示了一个更广泛的企业现实：Agentic AI正在把传统软件风险、身份风险、数据风险和自动化执行风险叠加到同一个控制面上。对于CISO、IT负责人和安全架构师来说，这意味着AI Agent不应仅被视为生产力功能，而应被纳入高信任系统和高风险自动化系统来管理。

核心结论：能力与防护正在发生“倒挂”

Adversa AI在分析中提出了一个关键概念：power-protection inversion（能力与防护倒挂）。简单说，越能完成复杂任务、越接近业务核心流程的Agent，通常也越需要更高权限、更广数据访问和更多外部动作能力；而这些能力恰恰扩大了其被滥用或被劫持后的破坏面。

研究将问题归结为AI Agent的“致命三元组（lethal trifecta）”：

1. 访问私有数据的能力 2. 接触不可信内容的能力 3. 执行出站动作的能力

三者同时存在时，Agent更容易被提示注入、上下文污染、权限滥用或动作劫持所利用。按照该研究的表述，98%的测试对象都具备这一结构。这并不意味着这些系统一定会被攻破，但意味着企业在部署时必须默认它们处于高风险自动化边界，而不是普通应用边界。

哪类Agent风险更高？电脑型与编码型最值得警惕

研究指出，风险最突出的两类是computer agents（电脑型Agent）和coding agents（编码型Agent）。

1）电脑型Agent：一旦失控，后果不止是“一个应用被误操作”

电脑型Agent通常具备操作桌面环境、浏览器、系统界面甚至完整操作系统的能力。它们的设计初衷是替用户做事，但为了完成任务，往往需要较宽的系统级权限。

这带来两个企业级问题：

• 攻击者可获得更大的终端控制面：如果该Agent被诱导执行恶意步骤，风险可能从单一应用扩展到整台终端。
• 用户可见性不足：研究指出，人类往往只能看到“任务输入”和“结果输出”，却看不到Agent在中间到底访问了什么、调用了哪些资源、修改了哪些系统状态。

对企业而言，这类Agent如果接入办公环境、财务流程、HR流程或IT运维台，风险不只是“误点错操作”，而是把终端权限、数据访问和自动执行合并为一个可被劫持的路径。

2）编码型Agent：更直接进入软件供应链

编码Agent的风险更加贴近企业软件开发与部署链条。Adversa的分析强调，这类Agent并不只是生成代码建议，它们可能会接触shell、依赖项、令牌、配置文件和部署管道。

这意味着，一旦编码Agent被滥用，潜在后果不只是生成不安全代码，而是：

• 访问开发密钥或令牌
• 修改构建与测试流程
• 引入高风险依赖
• 影响预发布或生产环境配置
• 在代码审查之前就接触敏感资产

对采用DevOps、平台工程或内部低代码/“vibe coding”模式的组织来说，这类Agent的影响范围尤其大，因为它们把风险嵌入到了软件供应链内部。企业不能只审查最终代码差异，还必须审查Agent执行过什么动作、接触过什么秘密、经过了哪些外部连接。

企业影响：这不是“模型安全”单点问题，而是业务控制问题

从企业视角看，AI Agent安全问题至少会影响四个层面。

1）运营风险

如果Agent被错误授权或被提示注入利用，可能直接执行错误动作，例如发送错误邮件、访问不该访问的系统、修改工单状态、触发自动化流程，甚至在集成环境中误调用外部API。对于依赖自动化的企业，这类事件会放大为流程中断、人工回滚和业务延迟。

2）财务风险

高权限Agent可能造成资源误用、云成本激增、许可证滥用，或者在代码与部署场景中引入修复成本。若Agent参与客户服务、销售流程或交易处理，错误动作还可能转化为直接收入损失。

3）合规与审计风险

当AI Agent接触个人数据、财务数据、受监管数据或跨境数据时，企业需要回答：

• 谁授权了Agent？
• 它访问了哪些数据？
• 它的每一步动作是否可审计？
• 是否符合最小权限、数据最小化和留痕要求？

如果企业无法提供清晰日志，AI Agent就会成为审计盲区。对金融、医疗、公共部门和关键基础设施相关组织而言，这一点尤其敏感。

4）品牌与信任风险

用户并不关心Agent“理论上多智能”，而在意它是否会泄露信息、错误操作或做出难以解释的决定。一次可见的失败就可能削弱客户、合作伙伴和内部员工对自动化系统的信任。对于正在推动AI转型的企业，这种信任损失往往会拖慢后续部署。

这反映的是行业趋势，而不是孤立现象

这项研究最值得关注的地方在于：它并不是在描述某一次漏洞事件，而是在揭示一个结构性趋势——AI能力的增长速度，正在超过传统安全控制对自动化系统的适配速度。

Adversa的结论也提示了一个市场现象：很多厂商更强调“能力”和“效率”，而对可验证防护的公开说明不足。对于企业采购方而言，这意味着评估AI Agent时，不能只问“能做什么”，还要问：

• 它是否需要访问私有数据？
• 它是否会接触不可信内容？
• 它是否能发起出站动作？
• 它是否支持可验证的权限边界、审计日志和动作审批？
• 它是否能在失败时安全降级？

换句话说，AI Agent安全正在从“模型层问题”转向“业务控制与运行时治理问题”。

企业应对建议：把Agent当成高权限自动化系统来治理

企业层面

• 建立AI Agent使用分级制度，按数据敏感度、动作权限和业务影响分类
• 对面向外部内容、内部系统和自动执行能力进行单独风险评估
• 设定“哪些任务可以自动完成，哪些必须人工确认”的红线

身份与访问控制

• 强制采用最小权限原则
• 对Agent使用独立身份而非共享人类账户
• 对高风险动作引入MFA、条件访问和步骤级审批
• 将关键动作与不可逆操作纳入额外验证

技术控制

• 使用SIEM集中记录Agent行为与系统交互
• 使用EDR/XDR监测终端与跨域行为异常
• 对出站流量、API调用和数据外传实施限制
• 对Agent执行路径保留可审计日志，而不只是结果日志
• 在开发场景中监控shell、依赖、令牌和CI/CD交互

管理与治理

• 将AI Agent纳入Incident Response预案
• 评估第三方Agent、插件、MCP服务器和外部工具链的风险
• 建立Third-party Risk Management流程
• 对“黑箱式自动化”设定上线门槛和退出机制
• 定期复核Agent权限，而不是默认长期有效

SecurityPost Insight

Adversa AI对100个AI Agent的测试提醒企业：AI Agent的安全问题不是未来式，而是正在扩大的现实风险。真正的挑战并不只是模型会不会“说错话”，而是它在拥有数据访问、内容接触和出站动作能力后，是否会把一次错误变成一次可执行的安全事件。对于企业来说，最危险的不是使用AI，而是在缺乏边界、审计和权限隔离的情况下部署AI Agent。

未来值得关注的趋势有三点：第一，Agent将继续进入办公、开发、客服和运维流程；第二，针对Agent的提示注入、权限滥用和供应链攻击会更系统化；第三，企业会逐步从“模型评测”转向“运行时治理”和“可验证防护”。对CISO而言，接下来的重点不是是否采用Agent，而是如何在采用Agent的同时，确保身份、出站、审计和不可逆动作仍然可控。