一场无人防备的AI安全危机正在形成

       在采访中，场无成Curity的人防CTO Jacob Ideskog探讨了智能体给企业带来的风险 ，随着这些智能体逐渐融入企业系统，安全滥用、危机数据泄露和未经授权访问的正形可能性也在增加。

Ideskog警告称，场无成行业正在“梦游”般地陷入安全危机
，人防这与早期API和云计算的安全采用过程如出一辙 ，同时他还概述了公司为抵御这些行为驱动的危机威胁必须采取的措施 。

你曾警告称，正形智能体会让行业“梦游”般地陷入安全危机 ，源码库场无成你这么说的人防意思是什么?你看到了哪些迹象表明我们已经在走这条路了?

智能体和其他非人类身份正在迅速激增，在某些企业中
，安全它们的危机数量已经超过人类用户 ，比例超过80比1。正形许多智能体被部署后，可长期广泛访问系统和数据，但并未像人类账户那样实施安全控制、治理或监控
，这为滥用行为创造了绝佳机会，无论是通过提示注入、凭证泄露 ，还是云计算利用它们生成的不安全代码。

我们已经看到了早期预警信号
 ，安全研究人员已证明 ，可以诱使AI助手执行未经授权的命令、访问敏感文件或引入供应链漏洞，而这一切都不会触发典型的安全警报，虽然这些测试是在受控条件下进行的 ，但这些技术并不复杂 ，恶意行为者将其用于实际攻击只是时间问题
。

你如何比较智能体安全的高防服务器现状与早期API安全或云配置错误的情况?我们是否在重蹈覆辙?

是的 ，我们确实在重蹈覆辙
，当前的智能体安全状况与21世纪10年代非常相似，当时企业急于采用云计算和API，却未充分理解其安全影响。

在早期API时代，开发人员常常在没有适当身份验证
、输入验证或速率限制的情况下暴露端点。攻击者发现可预测的模式和配置错误后，模板下载许多系统遭到滥用或破坏。向云计算的转变也带来了类似的成长烦恼
，如存储桶配置错误、角色权限过大以及可见性不足。

同样的模式正出现在智能体中 ，其功能令人印象深刻 ，采用它的业务压力也在增大 ，但如何保障其安全性的理解却滞后了，许多团队还没有针对AI的威胁模型，他们没有考虑如何操纵输入、服务器租用AI系统如何在会话间泄露上下文 ，或者权限过大的智能体如何在生产环境中采取意外行动。

我们还看到一些与早期时代相似的操作失误 ，有些企业在没有采取适当保护措施的情况下，直接将智能体与内部工具和数据源集成，还有一些企业跳过监控或日志记录，将这些系统视为仅仅是前端聊天机器人。在某些情况下 ，对于什么构成可接受或不安全的输出没有明确定义，这留下了太多的出错空间。香港云服务器

现在的关键区别在于 ，对于AI来说，攻击面包括行为、语言和上下文 ，现有控制措施无法轻易锁定这些方面
，因此需要采取不同的方法，这可能包括提示加固 、输入和输出过滤 ，以及持续监控系统随时间变化的行为，如果没有专门构建的工具和思维方式的转变，这种程度的复杂性很难管理。

不过好消息是
，我们有经验可循，API和云安全的经验教训仍然适用，最小权限、默认安全、可审计性和分层防御等原则同样重要 ，我们只是需要在新背景下应用它们，这里的风险更多在于影响、误解和意外行动
，而非代码层面的漏洞。

你能否分享一个公开或匿名的真实事件，其中不安全的智能体或机器人导致或促成了安全漏洞或运营问题?

最近的一个例子涉及Cursor IDE，这是一款由AI驱动的编码工具 ，研究人员证明，通过输入恶意提示，他们可以诱骗其内置的AI助手在开发人员的本地机器上执行系统命令。在这种情况下 
，攻击者可以窃取环境变量 、API密钥和身份验证令牌 ，将敏感文件泄露到外部服务器，并可能安装后门或更改配置 。

另一个例子来自GitHub Copilot，它使用OpenAI模型来推荐代码片段。早期，开发人员注意到Copilot有时会生成不安全的代码
，如硬编码凭证 、过时的加密或缺少输入验证，这并未直接导致安全漏洞
，但它表明
，如果不仔细审查，AI生成的代码可能会悄悄地将漏洞引入软件供应链。

这些事件表明 ，智能体并非被动工具，而是系统中的积极参与者
。如果企业不实施适当的防护措施
 ，如限定权限 、提示加固、行为监控和严格的输出过滤
，智能体可能成为重大的安全风险。

在典型的企业环境中
，智能体的攻击面是什么样的?攻击者最有可能针对哪些薄弱点?

在典型的企业环境中
，智能体的攻击面既广泛又高度动态 。与传统应用程序不同，智能体通过自然语言进行交互，这开辟了新的操纵途径。这种混合性质，既是软件系统，又是语言界面 ，带来了全新的安全挑战。

最常见且最严重的漏洞之一是提示注入，由于智能体遵循嵌入在文本中的指令
，攻击者可以精心设计输入 ，以覆盖内部命令 、暴露隐藏提示
，甚至改变智能体的预期行为。如果相关智能体与敏感数据或系统交互
，这可能会迅速升级为未经授权的访问或行动。

另一个主要风险是通过模型输出造成的数据泄露
，即使底层数据源得到妥善保护，智能体也可能在回应巧妙措辞的问题时无意中泄露机密信息。访问控制通常不适用于基于大语言模型(LLM)的系统，这意味着敏感信息可能通过间接查询或上下文操纵而泄露 。

对抗性输入 ，如故意格式错误、混淆或含糊不清的提示，也带来了日益增长的风险。攻击者可能利用这些输入绕过过滤器 
、诱使模型发表不安全声明或引发意外行为 。

更复杂的是，与企业工具的集成可能显著扩大攻击面 ，能够调用API、更新记录 、发送电子邮件或执行工作流的智能体必须受到严格权限控制和隔离，如果被恶意输入操纵 ，权限过大的智能体可能成为意外的攻击智能体，在这种情况下，边界和细粒度控制至关重要
。

训练数据暴露是另一个薄弱点，如果AI模型是在内部文档或聊天记录上进行训练或微调的 ，攻击者可能通过长期探测模型来提取这些数据的片段，这是一个被严重忽视的风险 。

最后，基础设施问题仍然存在，支持AI的端点、API、日志记录系统和中间件必须使用与其他关键系统相同的原则进行保护，输入验证不足 、日志记录不充分或缺乏速率限制可能使攻击者不仅利用智能体 ，还利用其运行环境。

AI系统尤其难以保障安全
，原因在于其漏洞的性质 
，许多漏洞并非基于代码
，而是基于行为，是模型如何解释和响应语言的结果 ，安全团队必须考虑意图操纵、语义歧义和通过提示传递的社会工程学攻击 。

为了降低风险，企业需要采取分层防御 、提示加固、输出过滤、行为监控、红队演练 、访问控制和全面观察所有AI交互等措施 ，攻击面包括模型、其指令、它访问的数据以及它运行的系统，防御者必须像语言驱动的对手一样思考  ，才能保持领先 。

在生产环境中部署智能体之前，每个企业都必须实施哪些控制措施或实践?

部署智能体会引入一类新的威胁，必须以与其他任何关键系统相同的严格程度进行管理 ，在上线之前，必须保护AI环境免受广泛攻击向量的侵害
 ，包括提示注入 、对抗性操纵和通过输入泛滥或拒绝服务进行的滥用，这需要强大的身份和访问管理，包括对内部用户和集成系统的基于角色的控制 ，与AI交换的所有数据在传输和静止时都必须加密，暴露的端点应得到加固 、监控和速率限制。

AI模型本身必须被视为潜在的攻击面，由于生成式模型对提示方式非常敏感，企业必须在各种条件下测试和验证提示 ，以防止意外行为 。输入/输出过滤、结构化响应和受限生成等防护措施对于确保AI不会泄露敏感信息或生成不安全内容至关重要。对提示、模型配置或系统指令的任何修改都必须记录在案，并接受变更控制。

部署前的测试应包括专门针对AI用例的红队演练和对抗性演练 ，这包括模拟提示注入、通过语言输出进行数据泄露 、模型操纵和其他滥用场景。智能体的性能和行为不仅必须在正常负载下进行评估 ，还必须在压力条件和畸形输入下进行评估。对于连接到内部数据的智能体，必须实施强大的分段和访问控制，以确保AI不会超出其授权范围行事
。

一旦上线，持续监控就变得至关重要 。企业必须实施运行时可观察性，以检测异常行为 、意外输出或安全策略违规 ，这包括记录所有用户交互的详细信息 ，以便进行审计和取证 ，同时实时标记潜在的滥用行为 。在适用的情况下，应部署内容审核管道或响应验证层，以在不安输出到达最终用户之前进行抑制或审查 。当置信度较低或响应行为偏离预期时，应触发回退机制，如路由至人工操作员。

网络安全团队还应制定针对AI的特定事件响应计划，这还应涵盖AI特有的新兴故障模式，如模型幻觉、通过补全进行的数据泄露、提示注入引起的行为变化或系统提示的利用。检测规则、警报和剧本应适应这些新的风险类别。

最后，操作纪律至关重要，模型部署必须进行版本控制，提示必须可审计，AI交互的遥测数据应纳入持续的威胁建模。如果AI与执行操作(如执行代码或发送消息)的外部插件 、API或智能体集成 ，则这些集成必须进行沙盒隔离，并受严格的权限和审批工作流管理。