亿格云AIDR AI安全解决方案

先讲四个我们见过的场面 -- 都不是安全事件，而是每天都在发生的正常办公。

它们都不是「安全事件」，而是每天都在发生的正常办公 -- 风险恰恰藏在「正常」里面。

三个场景的共同点：员工都在用AI把工作做得更好 -- 没有恶意，也没有人审批，更没有留下可追溯的记录。

六类载体，全部在采购清单之外--不是管理不严，是入口太多、长得太快。

看不见的AI，就是一条看不见的数据出口 -- 第一步不是禁止，而是先把正在跑的AI全部照出来。

一次「帮我把报错修一下」，敏感数据可能已经从两个出口离开了企业。

下面是一家客户终端上的执行实录 -- 员工只说了一句话，剩下的全程由Agent自己做完。

难度不在「能不能发现」，而在「来不来得及」-- 真正的控制点，必须放在执行之前。

这三件事本质上是同一件事：企业的数据和凭据，经一条没人管的通道离开了企业 -- 而企业自己毫不知情。

终端上的AI已经管起来了，容器里的Agent却还在裸奔。

结论：容器不是「另一个环境」-- 它是AI跑得最快、却最晚被看见的地方。

AI把安全治理对象从「员工+文件」，扩展到了「Agent+行动」。

不推翻现有安全体系，也不为AI另起炉灶 -- 沿用管员工的成熟体系，把Agent纳入同一张网。

所有AI默认视为未授权；先看清现状、做出决策，再把批准的AI纳入企业治理体系。

治理动作覆盖六类载体：身份 · 凭据 · 零信任 · DLP · 运行时 · 供应链
关键差异：批准不等于放任 -- 收编是一套动作（纳管改造+移交治理），而不是一次勾选。

端、网、模型与执行环境统一纳管 -- 策略统一下发，审计与告警统一上报。

① 客户端/Sidecar在工具调用执行前完成解析与判定         ② AI网关全量中转模型流量，管控出口① 

③ 零信任网关对内网访问默认拒绝                                     ④ SWG网关还原外发流量执行NDLP，封闭出口②
所有控制点共享同一套身份与策略：一次配置，端、网、模型侧同时生效 -- 单点被绕过，仍有下一道。

Agent的数量会以人类员工数倍的速度增长 -- 治理不能是为每个工具打的补丁，而是与人共用的同一套平台。

一句话：DLP、零信任、SASE照常管好「人」的场景，策略直接复用；Agent带来的新场景，由AIDR接管。

这些问题最终收敛到同一件事：把「人+Agent」放进同一个治理平面，用同一套身份、策略与审计体系管理。

八类场景，每一页都是一个岗位视角：他今天在干嘛，AI每做一步，AIDR当场怎么判。

前四类按岗位、后四类按风险 -- 每页都是同一个人的真实工作视角。

接下来八页，每页都是一个人的真实工作视角
① 左侧「人物卡」=这个岗位今天在干嘛   →   ② 右侧「真实一幕」=他/AI每做一步

③ 右侧判定胶囊 = AIDR当场结论：√放行 .   !检查后放行 · x拦住

对绝大多数员工，方向不是禁止，而是用企业入口把账号和敏感内容收住。

靠什么守住：企业SSO收口账号 · 模型流量强制过企业网关 · 读取与外发做意图判定。

财务、法务、人力手里的数据一旦外发就不可逆 -- 这里口径是「不允许」，不是「审计」。

靠什么守住：数据分级驱动模型路由 · 端侧读取拦截 · 核心系统对Agent 默认拒绝。

研发是AI使用强度最高的部门  -- 目标不是禁止，而是按代码密级分清边界。

靠什么守住：项目路径 - 密级映射 · 动态脱敏 · 输出漏洞与后门审计 · 外发行为拦截。

自动化运维最易出不可逆事故 -- 闸门必须放在执行之前。

靠什么守住：Agent 独立身份最小授权 · 危险命令执行前拦截 · 凭据不落地、停用即吊销。

绕过管控的门槛已从「要懂技术」变成「会提问」--「不能做什么」要先说清。

靠什么守住：理解任务意图而非穷举特征 · 危险动作执行前阻断 · 会话终止与实例隔离。

联网是正常业务需要 -- 关键不是禁网，而是看清谁、因何、传了什么、发去哪。

靠什么守住：TLS还原后做NDLP内容识别 · 域名分类与访问控制 · 结合任务与意图判定。

Agent装不了客户端、Pod又短命 - 安全能力必须随Sidecar 跟着工作负载走。

靠什么守住：Sidecar 随Pod注入 · 模型 / 内网 / 互联网三链路统一管控 · 证据随Pod回传。

第三方组件会继承Agent全部权限 -- 既是效率放大器，也是最易被忽视的越权入口。

靠什么守住：统一入口+AI-BOM清单 · 来源与签名校验 · 版本变化自动重新评估。

落地建议：先按岗位选场景，再按场景取能力 -- 不必一次全开，可以按风险高低分批上线。

某科技公司（脱敏）的AI安全建设实践 -- 从风险最典型的研发场景切入，再复制到更多用户与环境。

背景 - AI 从工具变成生产设施；                       挑战 - 四类治理盲区
方案 - 终端+容器+网关+模型；                        成果 - 4000+用户一10万+规划

某科技公司：当AI开始「动手」，治理对象必须跟着变
AI的使用范围从知识问答延伸到AI Coding、研发辅助与Agent 自动化，运行环境也从办公终端扩展到K8s容器。

当前覆盖用户   4000+；                 下一阶段规划规模   10万+；                 运行环境：终端/虚拟化/容器  3类；                    重点治理场景 4类

治理视角：谁使用了什么AI，连接什么模型，读取什么数据，调用什么工具，执行什么动作，数据最终去了哪里。
建设原则：安全建设不是为了减少AI的使用，而是为AI的持续开放建立边界

以合规AI Coding通道为切入点，统一模型出口，并把安全控制延伸到Agent 的文件、命令、工具与网络行为。

治理边界随 AI 应用深度持续扩展
从「看见Al」 -「管住模型调用」-「管理Agent行动与权限」；治理范围从员工终端延伸到K8s中的Agent。
落地节奏：先低风险拿到可见性与审计价值，再逐步加管控强度 -- 避免上来强管控影响业务。

核心代码不能离开企业；普通代码也不该因为安全要求而失去使用公开大模型的机会。

三个阶段递进：先看见、再跑通、后规模化一-每一步都有可交付的验证物。

阶段成果·当前已覆盖4000+用户
· 持续掌握AI工具使用情况，建立集团AI资产视图；       · 建立AICoding合规通道，个人账号与未授权模型收敛；  · 模型请求统一经AI Gateway审计与策略执行

· 对Agent敏感数据外发实时审计与拦截                         · 治理范围从员工终端延伸到K8s中的Agent                   · 形成从应用、行为、数据到模型连接的完整链路

客户价值：让开放与控制不再对立 -- 研发不必在「完全开放」和「全部禁止」之间二选一。
下一步：把已经跑通的机制，复制到K8sAgent、更多终端类型与业务团队。

用客户自己的数据验证 「可见性一风险分布一处置效果」，再决定推广节奏。

PoC产出：AI 资产清单·风险分布·高风险事件样例·优先治理建议。

不是单点工具的拼凑，而是面对 AI新场景，在一个平台上构建的完整答案。

不是要在「完全开放」与「全部禁止」之间二选一 -- 而是在持续验证的可信边界内，让AI与Agent规模化进入生产。
部署形态：终端客户端（采集与端侧管控）+安全网关（流量侧检测管控）+统一控制台 | SaaS/私有化/混合部署。