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。