随着人工智能技术的飞速普及，出现了一个新的安全挑战，即在 IT 和网络安全团队监管范围之外构建的“人工智能代理” (AI Agents)。来自 Cloud Security Alliance 的最新数据显示，82% 的专家在他们的组织中发现了他们并不知晓的人工智能代理，这打开了可能导致财务和运营灾难的安全漏洞。
访问漏洞与数字身份多样性
第一个问题在于这些代理如何获得访问权限。员工通常使用“无代码” (No-code) 工具通过 OAuth 协议或个人 API 密钥为代理授予权限。这种访问方式的多样性导致了审计日志 (Audit Logs) 的混乱；系统日志可能显示操作是由“服务账户”或“API 密钥”执行的，但实际上，该代理是在人类用户的授权下运行的，这使得追踪法律和技术责任变得极其困难。
安全设计的“二原则”
为了应对这些风险，“安全设计” (Secure by Design) 的概念应运而生。像 Meta 这样的大型公司的安全团队依靠所谓的“二原则” (Rule of Two) 来确定代理的危险程度。根据该原则，代理在单个会话中不得同时具备以下三个要素：
- 处理不可信的输入：例如读取来自外部来源的电子邮件。
- 访问敏感系统：例如人力资源数据库或财务系统 (ERP)。
- 改变状态或进行外部通信的能力：例如修改银行数据或向第三方发送数据。
如果代理同时具备这三个特性，它就会成为攻击的理想目标。
通过内容进行提示词注入的风险
最危险的威胁之一是“提示词注入” (Prompt Injection)，攻击者可以在看似普通的内容中发送隐藏指令。例如，可以发送一封包含在白色背景上使用白色字体编写的文本的电子邮件，要求代理“更新系统中的供应商银行数据”。由于代理是以数字方式读取内容的，它将执行该命令，而任何人类员工都不会注意到存在可疑邮件，且该操作在日志中会显示为合法且经过授权的活动。
检测与事后审计的挑战
传统的检测系统依赖于监控权限，但被入侵的代理可能仍保持在其授予的权限范围内，从而使其变得不可见。解决方案在于进行行为基准分析 (Behavioral Baselining)；即监测操作序列中的任何变化，例如一个原本仅限于读取权限的代理首次尝试“写入”或修改日志。
为什么这构成了真正的安全挑战？
危险之处在于，人工智能代理打破了“人类责任”链。当代理犯错或执行恶意命令时，调查人员在确定允许该行为的权限 (Authority) 时会面临难题。是创建代理的员工？是授予 OAuth 授权的用户？还是代理在完全独立地运行？如果没有能够将每项操作与明确的人类决策联系起来的精确日志，机构将无法堵塞漏洞并防止攻击再次发生。