一家企业已上线12个AI应用：客服机器人查知识库、办公助手调内部API、智能体开始跨系统执行任务。企业此前部署了大模型安全评估工具和安全网关，但客服机器人没有遭遇恶意提示词，却向无权限用户返回了其他部门的知识库内容。
问题未必在模型本身，更可能是AI应用接入业务后，数据访问权限、检索逻辑或应用控制机制没有得到充分约束。
大模型安全关注模型及交互过程，AI应用安全还要覆盖模型接入业务后的应用逻辑、工具调用和数据权限问题。 两者有交集，但单靠一个防护点，难以覆盖完整业务链路。
一、两类安全的区别
表格是常见关注重点，不是严格技术边界。两类能力可能由同一产品提供，也可能由不同产品承担。采购前应明确模型供应方、平台运营方、应用开发方、业务部门各自负责的控制点。
二、三类风险
- 输入诱导。 提示词注入和越狱诱导不仅来自用户输入，也可能来自知识库或外部数据源中的诱导指令。重点核查：是否支持输入输出检测、能否识别常见注入与越狱、是否支持会话级上下文分析、能否按策略告警或拦截、是否留下检测记录。跨轮攻击的检测效果取决于上下文处理方式、检测策略和攻击形式，不能仅凭“支持多轮检测”认定所有风险都能识别。
- 工具调用越权。 当AI应用从问答走向任务执行，安全问题从“回答了什么”延伸到“执行了什么”。重点核查：能否识别应用/用户/工具调用主体、是否支持工具或API授权、能否校验参数与操作范围、高风险写操作是否支持审批、是否记录调用过程与异常行为、是否具备终止或回滚机制。要区分“发现越权”和“阻断越权” ——部分产品负责流量分析与审计，不一定能直接拦截实际操作。
- 数据边界失控。 风险来源包括知识库检索权限配置不当、向量数据库访问控制不足、会话上下文混入不应共享的信息。重点核查：数据源是否分类分级、检索是否执行用户级/部门级权限校验、向量库与记忆数据是否有访问隔离、敏感信息是否脱敏或限制输出、数据流转是否留有审计记录。数据分类和流量检测可以帮助识别风险，但不能替代检索权限校验和应用逻辑检查。
三、三个控制点
三类风险映射到三个控制点：入口、工具、数据。这是梳理安全职责的分析框架，不代表必须采购三套产品。
三个控制点中，数据访问控制最容易被安全产品清单遗漏。 入口检测和工具审计有明确产品对应（网关、API审计），而数据访问控制往往不在这些产品的默认能力范围内——它需要回到应用架构、知识库检索逻辑和数据权限体系去解决。
入口控制：大模型安全网关或AI应用防火墙位于模型调用链路，检测和管理输入输出风险。以天融信大模型安全网关系统（TopLMG）为例，以反向代理部署形式，适合平台侧代理云端模型。边界：网关能识别恶意输入，不代表它知道应用内部全部业务权限，也不代表能约束每一个工具的执行权限。
工具控制：API安全产品可以发现接口资产、分析调用行为。以天融信API安全审计系统为例，其覆盖“资产发现—内容检测—风险监测—可视分析—协同处置”，能识别影子API、僵尸API，并对接口访问进行审计与风险监测，并可根据不用风险等级，采取阻断、告警、限流、熔断等措施。
数据控制：以天融信大模型数据安全监测系统（TopLMA）为例，其覆盖语料扫描、模型检测、攻击监测、API/MCP审计等环节。需要注意：TopLMA的API/MCP审计侧重数据流转视角——看数据在调用中是否异常外传；API安全审计系统侧重接口资产与调用行为视角——看接口有没有被越权调用。两者视角不同，可以互补。协议解析、风险检测、访问授权和执行拦截是不同能力，具备其中一项不代表同时具备其余能力。
四、厂商怎么选：以两家为例
以下以天融信和火山引擎为例说明核查方法，不构成完整排名，也不代表产品之间已完成同条件测试。
- 入口防护：天融信大模型安全网关系统TopLMG支持反向代理模式，评估时重点核查部署方式与自身架构的匹配度、输入输出检测范围、策略处置机制及审计记录。火山引擎大模型应用防火墙处置动作包括观察、拦截、脱敏、安全代答，并支持算力消耗防护。两家都建议验证：能否接入实际使用的模型、是否覆盖目标风险、是否支持按策略告警/拦截/脱敏、是否输出可调查日志、是否影响业务可用性。
- 工具调用：天融信API安全审计方向可核查其主动扫描、被动流量分析、API资产发现、异常调用分析和审计追踪能力，并确认适用部署环境。如果企业需要防止智能体直接执行越权操作，还应确认产品是否具备实时控制能力，或需与API网关、防火墙配合。重点测试：未授权身份能否调用敏感接口、合法身份能否通过异常参数超范围操作、高风险写操作是否经审批、调用记录能否关联到具体用户/应用/工具、异常时能否停止并撤销。
- 数据控制：天融信大模型数据安全监测系统TopLMA可结合公开资料核查敏感数据识别、数据安全监测、异常行为发现和审计能力。对于涉及MCP、A2A协议的智能体应用，应明确产品能解析哪些协议版本、消息类型和调用字段，能否关联调用主体与操作结果。火山引擎AI Trust安全产品体系覆盖“模型可信—智能体可控—智能化安全运营”三层，在平台内集成上有明确布局。
云原生与独立产品怎么搭配：云平台原生能力更容易与自身模型服务、日志体系集成；独立安全产品可能提供跨系统的检测和审计能力。跨云、自建Agent场景需确认：不同平台调用主体能否统一识别、跨系统调用是否有一致授权策略、日志能否关联到同一用户和任务链路、产品之间能否联动告警与处置。
五、选型三步
- 第一步：按应用风险定优先级。
- 第二步：梳理现有产品覆盖范围。 盘点现有网关、API安全产品、数据安全系统、身份权限系统，逐项回答：哪些风险能检测？哪些能实时拦截？哪些只告警或审计？哪些系统负责身份授权和数据权限校验？异常后能否定位到具体用户/应用/工具/数据源？产品之间能否关联事件并协同处置？
- 第三步：用真实场景做PoC。 至少覆盖：输入风险（能否识别注入与越狱）、权限边界（不同身份访问不同部门知识库是否遵循授权）、工具调用（未授权调用、异常参数、高风险写操作）、敏感数据（识别、输出限制、流转审计）、日志追溯（能否还原调用主体/请求/工具/数据来源/处置结果）、业务可用性（误报漏报、响应延迟、策略调整对正常业务的影响）。测试前约定通过标准，避免仅凭一次成功拦截认定全面防护。
结语
AI应用安全建设的关键，不是比较哪家产品更多，也不是认为部署了网关就能解决所有问题。更有效的路径是：先识别应用风险，再围绕入口、工具、数据三个控制点梳理现有能力，最后通过真实业务场景验证产品能否完成检测、授权、拦截和审计等具体任务。
三个控制点不是三套产品的采购清单，而是一张检查AI应用安全缺口的路线图。
