AI 安全性并没有坏掉，我们只是在保护错误的东西

网络安全行业在面对新兴技术时有一个模式，即我们立即开始在其周围筑墙。我们曾经这样对待云计算、容器，现在我们又在这样对待 AI，但这次，我们建造的墙位于完全错误的位置。

今天走进任何企业安全审查，你都会听到相同的优先事项：保护 AI 模型、保护训练数据、验证输出、部署 AI 驱动的副驾驶。供应商正在争相出售专注于模型级控制的“AI 安全”工具，例如防护栏、提示注入防御和模型监控平台。

但攻击者正在使用您的 AI 集成作为进入其他所有内容的高速公路。

没有人关注的真正攻击面

我们在企业环境中观察到的一种模式告诉了我们一个令人担忧的故事，即安全团队在保护他们的 AI 开发环境上投入了大量资金：模型访问控制、数据治理框架、MLOps 安全工具。这给了我们一种错误的信心，即他们的 AI 是“锁定”的。

但是，当你映射实际的攻击面时，你会看到 AI 聊天机器人通常持有数十个 SaaS 平台的 OAuth 令牌、具有过度云权限的 API 密钥以及可以创建从简单提示注入到生产基础设施的直接路径的身份信任关系。模型本身可能是安全的，但它们所处的生态系统通常是完全开放的，这不是一个边缘案例。

企业现在使用的平均 SaaS 应用程序数量为 130+，AI 集成跨越身份提供者、云基础设施、数据库和业务关键系统。每个集成都是一个潜在的攻击路径，每个 API 连接都是攻击者正在积极探测的信任边界。

问题不在于我们的 AI 安全工具是坏的，而在于我们正在保护个别组件，而攻击者正在利用它们之间的连接。

为什么基于模型的安全性错失了重点

当前的 AI 安全方法基于对现代攻击方式的基本误解。我们将 AI视为一个需要保护的独立资产，就像我们可能保护数据库或 Web 应用程序一样。但是，生产环境中的 AI 并不孤立地存在。它是身份、权限、API 和数据流复杂图中的一个节点。

考虑一个典型的企业 AI 部署。你有一个具有 Google Workspace 访问权限的 AI 代理。它通过 API 连接到 Salesforce (CRM ) 。它与 Slack 集成以进行通知。它从 AWS S3 存储桶中提取数据。它通过 Okta 或 Azure AD 进行身份验证。它在 ServiceNow 中触发工作流程。

传统的 AI 安全性关注模型本身：其安全态势、提示验证、输出安全性。但是，攻击者关注的是集成：他们可以通过泄露的服务帐户、API 操纵和利用的集成访问哪些内容。

攻击不会从 AI 模型开始或结束。模型只是入口点。

攻击路径不尊重产品边界

这是大多数组织陷入困境的地方。他们部署了提供单个域可见性的安全工具。一个工具监控云权限，另一个跟踪 SaaS 配置，第三个管理身份治理，第四个处理漏洞管理。

每个工具都向你展示了拼图中的一部分。没有一个工具向你展示这些部分如何连接起来。

根据 Gartner 的说法，组织现在使用的平均安全工具数量为 45+。尽管做出了巨大的投资，攻击者仍然能够跨这些域链接起配置错误，因为没有单个工具可以看到完整的攻击路径。

攻击者不需要在您的 AI 模型中找到关键漏洞。他们只需要找到一条链。也许是一个附加到您的 AI 服务的配置错误的 IAM 角色，该角色具有对 S3 存储桶的权限，该存储桶包含对具有生产环境管理员访问权限的 SaaS 应用程序的凭据。

每个单独的配置错误可能在您的安全工具中评为“中等”或“低”。但是，当它们链接在一起时？那就是一个关键的漏洞。并且，如果您以孤立的方式查看每个安全域，这将是完全不可见的。

暴露管理的迫切需要

这就是为什么对话需要从“AI 安全”转变为 AI 集成环境的持续威胁暴露管理。

仅仅询问我们的 AI 模型是否安全是不够的。安全团队需要了解如果他们损害了 AI 服务帐户，攻击者实际上可以访问什么。他们需要对云、SaaS 和身份系统中的配置错误如何链接在一起以获得可见性。他们需要了解 AI 集成如何实时改变他们的攻击面。并且，他们需要根据实际的攻击能力而不是仅仅根据严重性评分来优先考虑风险。

大多数安全计划仍然根据孤立的风险进行优先排序，使用 CVSS 评分和完全忽略漏洞在特定环境中是否实际可利用的合规性检查清单。

这种差距在 AI 系统中更加明显，因为它们不断变化。新的集成每周添加，权限演变，API 连接转变。您上个月的攻击面与今天的攻击面不同，但您的安全评估可能仍然相同。

什么是真正的攻击路径感知安全

在生产环境中保护 AI 需要一种根本不同的方法，它归结为四个关键的思维转变。

首先，您需要在安全域中具有统一的可见性。停止要求每个安全工具在其自己的孤立区中运行。您的云安全、身份治理、SaaS 管理和漏洞扫描工具都持有攻击路径拼图的碎片。它们需要实时共享数据，以便您可以看到配置错误如何链接在一起。

第二，接受持续的攻击路径模拟。不要等待渗透测试或红队演习来发现可利用的路径。持续测试攻击者如何通过您的环境移动，关注实际的可利用性而不是依赖理论的严重性评分。

第三，根据上下文进行优先排序。配置错误的 S3 存储桶仅仅因为它是公共的而不是关键的。它是关键的，因为它是公共的，包含凭据，并且这些凭据具有特权访问权限，并且可以从互联网暴露的资产访问。上下文比任何单个评分更重要。

第四，转向预防性补救。通过您的事故响应团队调查警报时，您已经失去了宝贵的响应时间。现代防御需要在事件发生之前关闭可利用的路径的能力，而不是在事件发生后。

我们无法忽视的警告

随着 AI 融入企业堆栈的每一层，攻击面正在以比安全团队能够手动推理的速度扩大。我们正在以比保护它们更快的速度添加 AI 集成。

如果您以孤立的方式保护 AI，保护模型同时忽略其运行的生态系统，您已经落后了。攻击者不思考工具，他们思考路径。他们不利用单个漏洞，他们将配置错误链接在一起，遍及您的整个环境。

将成功保护 AI 的企业不会是拥有最多 AI 安全工具的企业。他们将是那些理解 AI 安全与整个攻击面的暴露管理密不可分的企业。

模型安全性是基本要求。重要的是了解如果攻击者损害 AI 集成，他们可以访问什么。直到安全团队能够实时、连续地、跨整个环境回答这个问题，他们才没有保护 AI。他们只是希望自己建造的墙位于正确的位置。