Appearance
术语表 · 网络安全
本文件聚合网络安全领域的高频术语精简卡片，便于快速查询。
防火墙（Firewall）
定义：部署在网络边界、按预设规则对进出流量进行放行 / 拒绝的访问控制设备或软件。本质是一道"流量闸口"，决策依据是包头字段（IP、端口、协议）或更高层语义（URL、HTTP 方法、Payload 特征）。
分类与演进：
| 类型 | 工作层 | 决策依据 | 典型场景 |
|---|---|---|---|
| 包过滤防火墙 | L3/L4 | 五元组（源/目的 IP、端口、协议） | 路由器 ACL、iptables 基础规则 |
| 状态检测防火墙 | L3/L4 + 会话 | 跟踪 TCP 连接状态，区分新建/已建立 | 主流企业边界防火墙 |
| 应用层防火墙 / WAF | L7 | HTTP 请求语义、SQL 注入/XSS 特征 | Web 站点防护、API 网关前置 |
| 下一代防火墙（NGFW） | L3~L7 融合 | 包过滤 + IPS + 应用识别 + 用户身份 | 企业出口、混合云边界 |
与相邻术语区分：
- WAF（Web Application Firewall）：防火墙的子类型，专攻 HTTP/HTTPS 应用层攻击，传统四层防火墙看不到 SQL 注入这类 Payload
- IDS / IPS：防火墙做"按规则放行 / 拒绝"，IDS 做"检测并告警"，IPS 做"检测并阻断"——三者关注点和动作不同
- API 网关：功能有重叠（限流、鉴权），但网关定位是"业务路由 + 治理"，防火墙定位是"安全边界控制"
常见误用 / 踩坑：
- 只配边界防火墙不做内网分段：边界一旦被突破，内网横向移动无遮拦——零信任架构下应做 East-West 流量同样的 ACL 控制
- WAF 当万能盾用：WAF 拦不住业务逻辑漏洞（越权、薅羊毛），它只识别已知攻击 Pattern，自定义业务风险要靠风控
- 靶场 / 测试环境无防火墙：渗透测试在靶场打通了，到真实站点被 WAF 全挡——见 贾维斯计划 中提到的 WAF 绕过问题
- 规则只增不减：防火墙规则集随业务累积到几千条还不审计，性能下降 + 规则冲突——应定期清理"幽灵规则"
本仓库相关文档：
IDS（Intrusion Detection System，入侵检测系统）
定义：通过采集流量 / 主机日志并匹配特征或异常模型，检测潜在攻击行为并产生告警的安全系统。核心动作是"看 + 报"，不阻断流量；阻断是 IPS 的职责。
分类：
| 维度 | 类型 | 数据源 | 典型场景 |
|---|---|---|---|
| 部署位置 | NIDS（网络型） | 网络流量镜像 | 核心交换机旁路、出口流量监控 |
| HIDS（主机型） | 系统日志、进程、文件完整性 | 服务器加固、合规审计（PCI-DSS） | |
| 检测方法 | 特征检测（Signature） | 已知攻击 Pattern | 已披露 CVE 利用、恶意域名 |
| 异常检测（Anomaly） | 流量基线 / 行为模型 | 0-day、内部威胁、APT 横向移动 |
与相邻术语区分：
- IPS（Intrusion Prevention System）：IDS 的"主动版"——检测到攻击直接阻断（drop 包 / reset 连接），代价是误报会误伤正常业务，所以"严苛环境上 IPS、宽松环境上 IDS"
- 防火墙：防火墙做"按规则放行 / 拒绝"（决策前置），IDS 做"检测异常并告警"（决策后置），通常串联部署：防火墙挡明显恶意流量，IDS 检测绕过防火墙的隐蔽攻击
- SIEM（Security Information and Event Management）：上游聚合平台，吃 IDS / 防火墙 / 端点等多源告警做关联分析，IDS 是 SIEM 的数据源之一
- EDR（Endpoint Detection and Response）：可看作"加强版 HIDS"，覆盖检测 + 响应 + 取证全链路，IDS 偏纯检测
典型告警噪音问题：
- 误报率高：特征库匹配过宽，正常流量频繁触发——大型 SOC 一天上万条 IDS 告警，95%+ 是噪音，分析师疲劳
- 漏报率：异常检测模型对未见过的 0-day 不敏感；特征检测对加密流量、变形 Payload 失效
- AI 在 IDS 的当前角色：用 ML 做告警去重 / 优先级排序 / 自动关联（SOAR），让分析师只看真正高优的告警，而非取代规则引擎
常见误用 / 踩坑：
- 把 IDS 当 IPS 用：IDS 只告警不阻断，部署后还在等"自动挡攻击"是误解——要阻断必须用 IPS 或联动防火墙下发临时规则
- 只盯 NIDS 不上 HIDS：加密流量普及后 NIDS 看不清 Payload，攻击者拿到主机权限后的横向行为只有 HIDS 能捕获
- 告警不闭环：IDS 接入了但没人响应告警——等于没装；必须配套 SIEM/SOAR 流程和值班 SOC
- 靶场环境调通的检测规则直接上生产：生产流量基线和靶场差异巨大，规则误报率会爆炸——必须有灰度 / 影子模式
本仓库相关文档：
- 产品案例研究/其他/06-贾维斯计划-MCP串联安全工具链的渗透测试Agent架构（攻防视角下的检测/绕过）
个保合规审计（Personal Information Protection Compliance Audit）
定义：依据《个人信息保护法》（2021）建立的法定监督制度——对个人信息处理者的收集、存储、使用、加工、传输、提供、公开、删除等全流程处理活动是否合规进行审查与评价。审计对象不是数据本身，而是数据处理活动；依据不限于《个保法》，还包括《网络数据安全管理条例》《未成年人网络保护条例》等行政法规。
法规体系七里程碑：
| 时间 | 文件 | 价值 |
|---|---|---|
| 2021.8.20 | 《个人信息保护法》（第 54/64 条） | 顶层立法基础 |
| 2024.1.1 | 《未成年人网络保护条例》（第 37 条 每年审计） | 专项规则 |
| 2025.1.1 | 《网络数据安全管理条例》（第 27 条） | 制度衔接 |
| 2025.5.1 | 《个保合规审计管理办法》+《审计指引》 | 可落地准则 |
| 2025.5.19 | TC260-PG-20255A《网络安全标准实践指南》 | 实践推动 |
| 2025.11 | 《大型网络平台个保规定（征求意见稿）》 | 专项规则 |
| 2025.12.31 | GB/T 46903—2025《数据安全技术 个人信息保护合规审计要求》 | 推荐性国标（"怎么审"标准答案） |
与相邻术语区分：
- 等保（等级保护）：等保面向网络与系统安全整体，按定级（1-5 级）部署技术与管理措施；个保合规审计面向个人信息处理活动，按法定义务定期评估。两套体系并行不替代——等保过了不代表个保合规
- 数据安全评估：《数据安全法》框架下的"数据出境/重要数据"评估，关注数据本身的风险；个保合规审计关注处理活动的合规性
- PIA（隐私影响评估）：欧美 GDPR 体系下的事前评估，国内对应"个人信息保护影响评估"（《个保法》第 55 条要求高风险场景必做），与合规审计是事前/事中关系
两类触发条件：
- 定期审计：处理者按法定频次自行或委托第三方机构开展（未成年人场景明确为每年）
- 专项审计：存在风险或已发生安全事件时，监管部门可强制要求"委托专业机构审计 + 整改"（《个保法》第 64 条）
常见误用 / 踩坑：
- 把 SaaS 合规当成"过等保就够了"：等保和个保合规审计是两套独立体系，AI 客服/CRM/HR SaaS 类产品须分别覆盖
- 用户权利入口埋太深：查阅/复制/删除/撤回同意是法定权利，深埋设置页会被认定"未切实保障用户权利"——产品设计必选项而非加分项
- 审计日志没埋点：收集/共享/导出关键节点未留可追溯日志，专项审计时无证据链——事后补造成本极高
- 未成年人产品按"通用频次"做：未成年人场景法定每年审计，按年度做预算与人力规划
本仓库相关文档：
- [商业策略/15-个人信息保护合规审计-法定义务与法规体系]（法规体系全景与产品设计要点）
数据主权（Data Sovereignty）
定义：企业/政府对其产生与持有的核心数据具备的全链路控制权——包括存储位置（境内/境外）、访问权限（谁可读）、流转边界（不出域）、二次使用授权（是否可用于训练）、销毁可验证性。在 AI 时代特指当数据经过大模型 API 后，其衍生的业务规律与经验是否仍归属原数据持有者。
行业敏感度分级：
| 敏感度 | 行业 | 核心痛点 | 私有化需求 |
|---|---|---|---|
| 极高 | 金融、政务 | 监管合规、保密法律要求 | 必须私有化 |
| 高 | 医疗、军工 | 隐私保护、国家安全 | 强烈倾向私有化 |
| 中高 | 制造、能源 | 商业机密、竞争壁垒 | 倾向私有化 |
| 中 | 零售、电商 | 客户数据、价格策略 | 可接受混合部署 |
三大防御手段（对应 SaaS 接入大模型场景）：
- 业务黑盒：SaaS 内部完成敏感计算，只输出脱敏结论给大模型——切断"经验内化"路径
- 私有化部署（算力下乡）：百亿级轻量小模型打包到客户服务器，"网线一拔数据 100% 物理隔离"
- 数据水印：必须开放数据接口时埋入不可见标记，作为"数据被用于训练"的法律证据
与相邻术语区分：
- 数据安全：数据安全是技术维度（加密/访问控制/防泄露），数据主权是治理与权属维度（谁有最终决定权）
- 数据合规：合规是"满足法规底线"，数据主权是"超越合规的战略选择"——可以合规但仍丧失主权
- 数据出境：数据出境是地理边界问题，数据主权是控制权问题——数据不出境但被大模型经验内化，仍可能丧失主权
常见误用 / 踩坑：
- 以为"数据用完即焚"就保住主权：大模型在调用过程中已"经验内化"行业规律（成本核算/业务玩法），即便原始数据删除也无法收回
- 私有化部署 = 把 SaaS 装到客户机房：真私有化需要算力下乡 + 小模型本地化训练，纯 SaaS 私有化只是部署位置变化、未解决模型主权
- 混淆"数据所有权"与"数据主权"：法律上数据归客户所有，但若大模型已学到其业务规律，客户实际丧失了竞争壁垒——主权 ≠ 所有权
本仓库相关文档：
- [商业策略/10-SaaS数据生死局-大模型虹吸与三大防御手段]（大模型经验内化机制与企业防御三招）
数字水印（Digital Watermarking）
定义：在不显著影响数据可用性的前提下，将可识别、可验证、可追溯的标记信息嵌入到数据载体（文本、图像、视频、结构化业务流）中的技术。在 AI 数据安全场景下，特指SaaS 厂商将专属标记埋入开放给大模型的数据接口，一旦发现大厂模型表现出"该独家业务逻辑"，标记可作为"数据被用于训练"的法律证据。
两大技术分类：
| 类型 | 特点 | 典型场景 |
|---|---|---|
| 可见水印 | 肉眼可识别，主要用于版权声明 | 图像 LOGO、文档"机密"水印 |
| 隐写水印（Steganography） | 肉眼/常规检测不可见，需密钥/算法提取 | 大模型训练数据溯源、数据接口防伪 |
与相邻术语区分：
- 数字签名：签名验证"数据未被篡改 + 来源真实"，水印用于"嵌入身份信息、追踪流向"——签名是验真，水印是追踪
- 数据指纹（Data Fingerprinting）：指纹是从数据本身计算特征值（如 hash），水印是主动嵌入额外标记——指纹只能识别"是否同一份数据"，水印能识别"是哪个来源/谁的副本"
- DRM（数字版权管理）：DRM 是一整套加密 + 授权 + 撤销体系，水印只是 DRM 中的一个模块（追溯环节）
典型应用场景：
- 大模型训练数据溯源：在向 AI 厂商开放的数据接口流中埋入水印，若 AI 模型对其他客户的输出中泄露该水印，证明"数据被用于训练"
- 企业敏感文档防泄露：每份文档嵌入"接收人 ID"水印，泄露后可定位泄露源
- AI 生成内容溯源：水印嵌入到 AI 生成的图像/文本中，便于识别"该内容是 AI 生成"（C2PA 等标准方向）
常见误用 / 踩坑：
- 水印 = 一定能法律维权：维权前提是水印可被独立第三方提取验证、且未被对抗性清洗——目前大模型场景下"水印能否抵御模型微调清洗"仍是研究热点
- 被动防御，发现时损失已成：水印是"事后追溯"手段，不能阻止"经验内化"本身——必须配合业务黑盒、私有化部署组合使用
- 把水印当唯一防线：水印对"显式复制"有效，对"模型学到规律后重新表达"几乎无效——AI 时代水印是兜底而非主防御
本仓库相关文档：
- [商业策略/10-SaaS数据生死局-大模型虹吸与三大防御手段]（水印作为 SaaS 三大防御手段之一）
EDR（Endpoint Detection and Response，端点检测与响应）
定义：部署在 endpoint（用户电脑、服务器、虚拟桌面）上，持续采集进程行为 / 文件操作 / 网络连接 / 注册表 / 内存事件并通过特征匹配 + 行为分析 + 威胁情报关联，实现检测 → 调查 → 响应（隔离 / 进程终止 / 文件回滚）→ 取证全链路的端点安全产品。本质是"加强版 HIDS + 响应自动化 + 云端关联分析"。代表厂商：CrowdStrike Falcon、Palo Alto Cortex XDR、Microsoft Defender for Endpoint、SentinelOne Singularity。
与相邻术语区分：
| 术语 | 核心动作 | 安全对象 | 与 EDR 关系 |
|---|---|---|---|
| HIDS | 检测 + 告警 | 主机进程 / 日志 / 文件完整性 | EDR 的前辈，缺响应能力 |
| EPP（Endpoint Protection Platform） | 预防（杀毒 / HIPS） | 已知 malware | EDR 通常包含 EPP |
| XDR（Extended Detection and Response） | EDR 能力 + 网络 / 邮件 / 身份 / 云日志关联 | 跨域威胁 | EDR 是 XDR 的子集 |
| MDR（Managed Detection and Response） | 24/7 人工 + EDR/XDR 平台 | 服务化交付 | EDR 是 MDR 的基础工具 |
| AES（Agentic Endpoint Security） | install-time 治理 + agent 行为审计 | endpoint 上的 autonomous actors（agent / MCP / 扩展 / 包 / 模型 / 容器） | EDR 看 malware，AES 看"合法授权的 AI agent"——互补不替代（见下文 AES 卡片） |
核心假设与盲区：
- 核心假设：endpoint 上最大的风险是恶意软件 / 勒索软件 / 木马 / 未知二进制文件——EDR 围绕"进程是不是坏的"做检测。
- 传统盲区：EDR 是 runtime 检测（事后观察），缺 install-time 治理；EDR 的 file hash / 进程行为视角对"合法安装、合法登录、合法调用工具、合法读取数据的 AI agent"几乎失明——这正是 AES 出现的根因。
- 典型场景失效：一个开发者安装合法的 VS Code AI coding extension，扩展读取打开的文件 / workspace / 代码片段 / 密钥并发到外部服务器——EDR 看到的是"合法编辑器加载了合法扩展"，无法判断该扩展应不应该出现在研发机器上、它的发布者是不是被收购、它上次更新改了什么。
常见误用 / 踩坑：
- 把 EDR 当 AES 用：在 AI Agent 时代，员工 endpoint 上的最大风险已不是 malware 而是 autonomous actor——EDR 看不到"agent 为什么在这里 / 谁装的 / 能访问什么 / 数据发到哪里"
- 只买 EDR 不接 SIEM/SOAR：EDR 告警每天上千条，没有上游聚合和 playbook 自动化会让 SOC 团队疲于响应
- 替换 EDR 求新求快：EDR 合同迁移成本极高（误报基线 / SOC 流程 / 合规审计 / 响应脚本 / 资产标签全要重建）——除非新平台同时提供成熟 EDR + AES + identity + cloud + SIEM/SOAR 一体化，否则不要为单个新概念替换 EDR
本仓库相关文档：
- 技术趋势/AI重塑网络安全-2026-05-13（案例 G：AES 与 EDR 的三阶段路径——并存 / 升级 / 融合）
- 技术认知/05-AI与Agent/05-AI安全/Agent安全工程（Agent 安全工程内核，与 EDR/AES 的 endpoint 治理面互补）
AES（Agentic Endpoint Security，智能体端点安全）
定义：Palo Alto Networks 2026-04-14 收购 Koi 时正式命名的 endpoint security 新品类，定位为"保护运行在员工电脑、开发机、浏览器、IDE、本地环境里的 AI Agent"。核心治理对象不是 malware，而是"合法安装、合法登录、合法调用工具、合法读取数据"的 autonomous actor——包括 AI agents / MCP servers / 浏览器扩展 / IDE 扩展 / npm·PyPI 包 / 本地或远程模型 / 容器 / 脚本 / API token / SaaS connector。通过 install-time 治理（在到达 endpoint 之前进行准入控制）+ runtime 审计（agent 调用了什么工具 / 访问了什么系统 / 拿了什么权限）+ Supply Chain Gateway（GitHub / Hugging Face / Chrome Web Store / VS Code Marketplace / Homebrew 等"安装入口"统一治理）三件套构成。
与 EDR 假设差异：
| 维度 | EDR | AES |
|---|---|---|
| 安全对象 | 进程 / 文件 / 网络连接 / 注册表 | endpoint 上的 autonomous actors |
| 核心问题 | 这个进程是不是坏的？ | 这个 agent 为什么在这里？谁装的？能访问什么？调用了什么？数据发到哪里？是否越权？是否应该继续存在？ |
| 时间窗 | runtime 检测（事后观察） | install-time 准入 + runtime 审计 + 权限内约束 |
| 治理语言 | file hash / 进程行为 / 网络 IoC | publisher ownership change / update channel drift / code diff / install source / tool permission |
| 类比 | "病毒查杀" | "数字员工管理（HR + 准入审批 + 行为审计）" |
Ultimate Insider Threat 的产品逻辑：Palo Alto 产品负责人将 agentic AI 称为"ultimate insider threat"——过去 insider threat 是人，现在 insider threat 是"人合法授权的 agent"，它用员工权限读公司代码 / 文档 / 邮件 / CRM / 工单 / 数据库，调用 shell / 浏览器 / IDE / MCP server / API key / SaaS connector，全程"不是黑进来的"。AES 就是把"如何治理员工亲手装上的 AI 助手"这个问题做成产品。
与相邻术语区分：
- EDR / XDR：见上文 EDR 卡片。AES 是 EDR 的补盲区伙伴，不是替代；2026-2028 并存，2028+ 大概率被 XDR / AI Security Platform 吸收（类比 CASB → SASE、CWPP/CSPM → CNAPP）
- AI 护栏（AI Guardrails）：护栏在模型输入/输出做检测拦截（防 prompt injection / 内容违规 / PII 泄露），AES 在 endpoint 做安装准入 + agent 行为治理——前者是模型边界、后者是设备边界
- MCP 治理：MCP 治理是 Agent 安全工程内核（协议层）的一部分，AES 是 MCP 在 endpoint 上的发现 + 准入 + 审计产业落地形态（对应 OWASP MCP Top 10 中的 LLM09 Shadow MCP / LLM03 工具投毒 / LLM04 软件供应链攻击 / LLM08 审计缺失）
- NHI（Non-Human Identity）/ 影子 Agent 检测：NHI 偏身份管理视角（agent 的 token / 凭证 / 权限），AES 偏 endpoint 治理视角（agent 这个软件在不在、装在哪、做了什么）——两者互补
七种适用场景判断（满足任意三条即应评估）：
- 研发团队已大规模使用 AI coding agent
- 公司允许员工自行安装 VS Code / browser extensions / MCP servers / Homebrew / npm / PyPI / 容器 / 本地模型
- 员工 endpoint 上有源代码 / 客户数据 / 财务数据 / 内部文档 / API key / 生产凭证
- 已出现 Shadow AI 但缺完整 inventory
- 处于金融 / 医疗 / SaaS / 政府 / 制造 / 能源 / 法律 / 咨询等高敏感行业
- 已在做 AI agent 项目，计划让 agent 调用真实业务系统
- 董事会 / 监管在问"AI 工具访问了哪些数据？谁批准的？是否可审计？"
采购 12 问筛选伪 AES 产品：详见 技术趋势/AI重塑网络安全-2026-05-13 框架九（覆盖资产发现 / pre-install blocking / 多维风险信号 / 策略粒度 / 平台集成 / 风险解释 / 审批流 / 工具调用审计 / MCP 治理深度 / 开发者体验 / MITRE 映射 / 真控制 vs 仅可视化 12 个维度）。
常见误用 / 踩坑：
- 把 AES 当"EDR + AI 仪表盘"买：12 问会让伪 AES 产品自动露馅——只做 inventory 不做 pre-install blocking、只看网页 AI 工具不看 MCP server、只做 dashboard 不做 endpoint 控制的，都不是真 AES
- rip and replace EDR 上 AES：错误路径。正确路径是"短期并存 → 中期升级 → 长期融合"，AES 补盲区不换底座
- 只买不接 SOC 流程：AES 告警若不映射到 MITRE / SIEM / 合规报告，仍会沉在产品控制台无人响应
本仓库相关文档：
- 技术趋势/AI重塑网络安全-2026-05-13（案例 G：Palo Alto 收购 Koi / 框架七-九：AES+EDR 三阶段路径 + 七种适用场景 + 12 问）
- 技术认知/05-AI与Agent/05-AI安全/Agent安全工程（Agent 安全工程内核——协议-身份-执行三层与 AES 第四层 endpoint 治理的对应关系）
Shadow AI（影子 AI）
定义：企业内部未经安全 / IT / 合规审批就被员工或团队启用的 AI 工具、组件、agent 与配套基础设施。本质是 Shadow IT 在 AI 时代的延续与升级——区别在于 Shadow AI 不仅泄露数据，还可能"代员工执行操作"。
两阶段演进：
| 阶段 | 形态 | 风险维度 |
|---|---|---|
| Shadow AI 1.0（约 2023-2025） | 员工把公司资料复制到 ChatGPT / Claude / 文心等网页 LLM | 数据泄露（单维度） |
| Shadow AI 2.0（2026 起） | 员工在本机安装 Cursor / Claude Code / 浏览器 agent / VS Code AI extension / MCP server / npm·PyPI 包 / 本地模型 / 各种 AI helper | 五维叠加：数据泄露 + 工具调用 + 代码执行 + 凭证滥用 + 软件供应链投毒 |
为什么 Shadow AI 2.0 比 1.0 危险得多：网页聊天最多泄露员工主动复制的内容；本地 agent 拥有员工同等权限——能读 workspace 全部文件、能调用 shell 与 git、能访问 SSO 后的 SaaS、能加载 MCP server 连接 GitHub / Slack / Drive / Jira / 数据库 / 内网 API。一个被投毒的 npm 包或 VS Code 扩展可以在员工"完全合法的使用过程中"完成数据外传 + 凭证窃取 + 横向移动。
与相邻术语区分：
- Shadow IT：泛指未经批准的 IT 资产（私接服务器 / 私装 SaaS）；Shadow AI 是其 AI 子集，且因 agent 可"代理行动"风险更重
- Shadow MCP（影子 MCP 服务器）：Shadow AI 2.0 的具体形态之一——开发 / 研究 / 数据团队临时搭起来测试的、未经治理的 MCP 实例，常带默认凭证 / 宽松配置 / 未加固 API。OWASP MCP Top 10 中编号 LLM09
- BYOAI（Bring Your Own AI）：管理学视角的同一现象——员工自带 AI 工具到工作场景。Shadow AI 偏安全视角（强调风险），BYOAI 偏治理视角（强调政策）
安全团队的两条路线选择：
- ❌ 禁止路线：宣布"不许用 AI"——研发 / 业务 / 高管 / 外包都会用，禁不掉，最后 Shadow AI 蔓延更失控
- ✅ 可治理路线：允许创新，但把 agent / 插件 / 模型 / MCP / 包 / 扩展放进可见、可控、可审计的框架（AES 的核心价值主张就在这里）
常见误用 / 踩坑：
- 只盯网页 ChatGPT 不看本地 agent：合规问卷停留在"是否使用 ChatGPT"，但员工 endpoint 上已有 5-10 个本地 AI helper——盘点维度严重落后
- 把 Shadow AI 等同数据泄露问题：忽视"工具调用 + 代码执行 + 凭证滥用 + 供应链投毒"四个新维度，传统 DLP 框架治不住
- 依赖人工填报 inventory：员工不会主动报告自己装了什么扩展 / MCP / 包——必须工具自动发现（这是 AES 的 #1 能力要求）
本仓库相关文档：
- 技术趋势/AI重塑网络安全-2026-05-13（核心概念 Shadow AI 2.0 / 案例 G AES 品类应对）
- 技术认知/05-AI与Agent/05-AI安全/Agent安全工程（Shadow MCP / LLM09 影子 MCP 服务器治理）
上述 EDR / AES / Shadow AI 三个术语于 2026-05-19 由 /route-knowledge 路由"Palo Alto花30亿买下Koi"长文时新增。