CASB与DLP为何无法满足AI安全需要交互感知

资讯专家

随着员工将AI用于自动化、协调和优化复杂工作流，企业中出现了大量未经IT审批的个人账号和浏览器扩展，也就是“影子AI”。传统安全做法是先用CASB发现并管控AI应用，再叠加DLP规则跟踪使用。这套模型在SaaS治理中有效，但对AI并不够。

问题在于，AI风险并不像传统SaaS风险那样局限于某个应用、文件或字段。风险可以藏在一条prompt里，出现在模型生成的响应中，甚至因为恶意prompt导致自主代理（agent）执行越权操作。CASB回答的是“用户能否访问某个应用”，DLP检查的是已知敏感模式，但两者都缺少对AI对话中语义和累积上下文的理解。比如，用户可能分多次间接描述敏感信息，单看每条消息并没有问题，但组合起来足以让模型还原出供应商合同或故障报告内容。这类暴露不匹配任何DLP规则，却构成真实的业务风险。

安全团队因此陷入两难：收紧CASB访问控制，用户可能转向完全不可见的非受管应用；DLP放得太松，敏感数据又会从“门缝”流走。真正的检查点应该放在人与模型的交互过程中——看用户问了什么、模型回了什么、agent调用了哪些工具、检索或传输了什么数据，以及最终动作是否被允许。

几个典型例子可以说明区别：用AI写一篇公开发布的博客大纲是日常操作，但让它基于未发布产品写市场文案则可能泄露敏感信息；开发者用AI回答通用问题风险低，但问题中夹带专有逻辑、甚至关联真实客户问题就变成高风险；agent读取已授权的知识库没问题，但把受限内部文档转发到外部就明显违规；总结公开文档风险低，从片段拼凑出机密信息则不行。更严重的是prompt注入——当指令被精心嵌入检索内容中，模型无法可靠区分数据和指令，agent就可能把恶意内容当作操作指令执行。

因此，简单“默认拒绝”并不可行。员工有任务压力，强行封锁只会让使用行为进一步转入个人账号和未受管扩展，加深影子AI。更合理的方式是：将prompt注入和agent滥用视为当前日常风险；继续用CASB和DLP做应用发现、访问治理、已知敏感模式检测和合规报告；同时增加一个交互感知层，分析prompt语义、响应敏感性以及agent动作是否授权。最终目标不是把AI锁死，而是在敏感数据和代理行为可控的边界内，让员工能够放心采用和试验AI。

热心网友3

楼主的分析很到位，尤其是“分多次拼凑敏感信息”这一点，传统DLP确实抓不到这种累积上下文的风险。之前我们更多是拿CASB做app发现和访问控制，但AI场景下光管住“能不能用”远远不够，关键还是要理解人跟模型之间的对话意图和agent的后续动作。不然就像你说的，两头堵只会把使用行为推到更隐蔽的地方去。交互感知这层，感觉以后会逐渐变成必须的补位。

热心网友3

楼主的分析很到位。CASB和DLP确实是传统SaaS治理的利器，但AI对话这种“非结构化、上下文相关、动作可变”的风险模式，确实不是它们擅长拦截的。尤其提到“分多次拼凑敏感信息”和“prompt注入”这两点，基本上就是当前AI安全最头疼的实战场景。 我也觉得“交互感知”这个方向是对路的——不是简单盯住某个文件或某个应用，而是看整个交互链路：问的是什么、模型答了什么、agent又调了哪些工具。这样才有可能在“数据还没出去”之前或者“动作还没执行”之前拦截下来。 另外楼主说的“默认拒绝不可行”也很现实。业务压力摆在那，禁止只能催生更多影子AI，反而不受控。与其堵，不如在可控范围内放开，配合感知层做精细判断，既让员工用得上，也让安全团队心里有底。希望市场上早点出现真正能落地的交互感知方案。

热心网友3

说得很到位，尤其在“分多次间接描述敏感信息”这一点上，传统DLP确实很难识别。交互感知这个提法很有价值，毕竟AI安全的核心不再只是“数据是否被拿走”，而是“对话和动作的语义是否越界”。不过实际操作起来，语义分析和agent行为审计的误报率可能会是个挑战，楼主觉得这方面有什么好的落地切入点吗？