Kubernetes集群AI智能体安全检测：从运行时逆向追踪“幽灵”Agent

1. 项目概述：当Kubernetes集群里出现了“幽灵”

上个月，在对一个客户的生产环境Kubernetes集群进行例行扫描时，我们撞见了一个本不该存在的东西。一个Python进程，静静地运行着。它保持着活跃的网络连接，目的地是api.openai.com和一个Pinecone向量数据库索引。它的执行周期非常规律，每4分钟一次，这完全符合一个AI智能体（Agent）的工作循环特征。然而，翻遍整个集群的配置清单，我们找不到任何关于它的记录：没有部署清单（Deployment Manifest），没有Pod定义，没有ConfigMap，甚至在代码仓库里也搜不到它的源代码。这是一个运行在生产环境中的AI智能体，但团队里没有一个人知道它的存在。我们称它为“幽灵”（GHOST）智能体。它只存在于运行时，在你的任何资产清单里都找不到它的踪影。

这件事让我背后发凉，也点醒了许多正在或计划将AI能力集成到生产系统的团队。传统的软件部署，遵循着从代码到构建，再到通过声明式配置（如YAML文件）部署的清晰路径。我们的安全工具链——代码扫描、配置检查、依赖分析、日志监控——都建立在这条可追溯的路径之上。但AI智能体，尤其是那些基于大语言模型（LLM）能自主执行任务的Agent，其引入和运行方式正在打破这条规则。开发者可能在生产环境快速测试，因为测试环境没有真实数据；外部承包商可能直接往节点上丢了个脚本；某个Agent框架可能启动了一个比其父进程生命周期更长的子进程；甚至有人只是通过kubectl exec执行了命令，却忘了创建对应的资源清单。结果就是，这些“幽灵”智能体获得了对你内部API、向量数据库和工具的访问权限，却在你的安全雷达上完全隐形。

如果你的团队正在生产环境运行AI智能体（大多数工程团队都在这么做，即使安全部门不知情），那么你很可能已经面临“幽灵”问题。这无关恶意，而是因为适用于传统软件的部署纪律，在灵活、动态的Agent工作流面前常常失效。核心问题不再是“我们有没有幽灵”，而是“我们是否知道它们的存在”。接下来，我将详细拆解我们如何发现它、为什么现有工具会失效，以及我们构建的检测方案是如何从运行时逆向追踪，将这些“幽灵”揪出来的。

2. 幽灵智能体的成因与安全盲区

2.1 为什么传统安全工具会失效？

要理解“幽灵”智能体的威胁，首先要明白现有安全工具的检测逻辑及其局限性。当前主流的AI安全工具大多遵循“由内而外”的扫描思路，它们需要一个明确的起点——通常是某种形式的静态资产。

• 代码扫描器：起点是你的源代码仓库。它们搜索openai、langchain、llama_index等库的导入语句，寻找Agent的初始化代码。但如果Agent的代码从未进入版本控制系统，或者是以动态生成、临时脚本的形式存在，这类工具就完全看不见。
• 配置扫描器：起点是你的基础设施即代码（IaC）文件，如Kubernetes的YAML清单、Terraform配置。它们检查部署定义、环境变量、密钥引用。然而，“幽灵”智能体恰恰没有这些声明式配置，它是通过kubectl run、kubectl exec或直接在容器内执行Python脚本等方式“溜”进集群的。
• 软件物料清单（SBOM）与依赖扫描器：起点是你的requirements.txt、package.json或容器镜像层。它们分析依赖关系以发现漏洞。但对于一个直接通过容器内pip install安装包并运行的进程，如果其依赖没有记录在项目的依赖管理文件中，扫描器同样无能为力。
• 日志分析与应用性能监控（APM）：起点是应用程序主动上报的日志和指标。这要求Agent框架集成了日志SDK，并且按照预期输出日志。一个刻意隐藏或简单粗暴的脚本很可能不产生任何可被集中收集的日志，或者其日志被输出到了不被监控的标准错误流（stderr）中。

“幽灵”智能体的核心特征就是“运行时可见，资产清单不可见”。它作为一个操作系统级别的进程存在，进行网络调用、消耗计算资源、访问数据，但没有任何“书面记录”。你的安全信息和事件管理（SIEM）系统抓不到它，因为缺乏触发告警的事件源；你的供应链安全工具也检测不到，因为它的“供应链”根本不存在于你的管理范畴内。

2.2 典型的“幽灵”引入场景

在实际开发运维中，“幽灵”智能体的产生往往源于一些看似合理甚至高效的实践，但这些实践绕过了既定的管控流程。

1. 生产环境直接调试：这是最常见的原因。开发者需要测试一个依赖生产数据库特定数据的Agent。由于在预发（Staging）环境复制完整的生产数据成本高昂或不可行，他们便直接在生产集群的某个Pod内，或通过临时Pod运行脚本。测试完成后，可能忘了清理，或者这个测试脚本被配置成了定时任务（CronJob），但该CronJob资源并未通过GitOps流程提交。
2. 手动应急与热修复：线上服务出现了一个紧急问题，初步判断某个AI推理逻辑有误。运维人员通过kubectl exec进入容器，直接编辑并重启了Agent进程，或者替换了某个Python文件。这个热修复生效了，但对应的代码变更和配置更新没有及时回写到代码库和部署清单中，导致运行时状态与版本控制严重偏离。
3. 第三方脚本与承包商工作：外部团队或承包商在协助开发时，可能会将自己的工具脚本直接放置在集群内运行。这些脚本的交付物可能只是一个压缩包或几句安装命令，并未纳入主项目的代码管理和部署体系。当合作结束后，这些脚本可能仍在默默运行。
4. Agent框架的副作用：一些Agent框架或工作流引擎（如AutoGen、LangGraph）在运行时可能会动态创建和管理子进程来执行任务。如果框架本身异常退出或被终止，这些子进程有可能变成“孤儿进程”继续运行，脱离了父框架的生命周期管理和可视范围。
5. 基于会话的临时部署：使用kubectl run my-agent --image=python:3.11 --command -- python agent.py这样的命令创建一个临时Pod。这种Pod通常不会被任何控制器（Deployment, StatefulSet）管理，一旦节点调度或重启就可能消失，但也可能因为某种原因（如配置了restartPolicy: Always且进程持续重启）而长期存在。

这些场景的共同点是：活动绕过了CI/CD流水线和GitOps的审计跟踪。它们创造了“事实上的部署”，却未留下“声明式的记录”，从而在安全视野中形成了一个盲区。

3. 检测方案设计：从运行时逆向追踪

既然“幽灵”存在于运行时，那么检测思路就必须反转过来，采用“由外而内”的策略。我们的目标不是从代码推演出可能运行什么，而是直接从运行时状态观察正在运行什么，再反向关联回资产清单。我们设计的AgentDiscover Scanner采用了四层检测模型，像剥洋葱一样从最外层的运行时现象逐层向内核对。

3.1 第一层：运行时网络活动监控

这是检测的起点，也是最直接的信号。一个AI智能体只要工作，就必须与外界通信：调用LLM API（如OpenAI、Anthropic、Google AI Studio）、查询向量数据库（如Pinecone、Weaviate、Qdrant）、访问内部工具API。

实现要点：

• 抓取活动连接：在目标系统（宿主机或容器内）执行类似netstat -tunp或ss -tunp的命令，或直接解析/proc/net/tcp文件，获取所有TCP/UDP连接及其对应的进程ID（PID）。
• 识别AI相关端点：维护一个已知的AI服务域名和IP地址列表。这个列表需要持续更新，包括主流云厂商的AI服务、开源自托管模型端点（如本地部署的vLLM、Ollama）、以及常见的向量数据库和Agent工具平台。
• 关联进程信息：通过PID可以找到进程的执行路径（/proc/<PID>/exe）、命令行参数（/proc/<PID>/cmdline）和所属容器（在Kubernetes环境下，通过cgroup信息关联容器ID）。

注意：网络监控可能遇到权限问题。在容器内执行命令需要足够的权限。我们的方案在Kubernetes环境中优先考虑使用非侵入式的、基于eBPF的技术，或利用Kubernetes API提供的有限可见度。

3.2 第二层：进程树与行为分析

仅凭网络连接可能误判（例如，一个普通的爬虫程序也可能访问某个公共API）。我们需要更丰富的上下文。这一层关注进程本身。

实现要点：

• 进程特征识别：检查进程的命令行参数。一个典型的Python AI Agent进程，其命令行可能包含明显的脚本名（如agent.py,main_loop.py）或模块执行语句（python -m autogen.agentchat）。同时，检查进程加载的动态库，看是否链接了openai、langchain等关键库。
• 进程生命周期与规律性：监控进程的启动时间和运行时长。“幽灵”智能体可能是常驻进程，也可能是定时触发的。检测异常的定时任务（cron）或系统服务（systemd unit），特别是那些不在标准镜像或部署清单中定义的。
• 资源消耗画像：观察进程的CPU、内存占用模式。一些推理或训练任务会产生周期性的、可识别的资源脉冲。

3.3 第三层：Kubernetes控制平面审计

对于Kubernetes环境，我们需要将运行时发现的进程与K8s官方管理的资源进行比对。这是确认“幽灵”身份的关键一步。

实现要点：

• 列举所有合法工作负载：通过Kubernetes API，获取集群中所有命名空间下的Pod、Deployment、StatefulSet、DaemonSet、Job、CronJob等资源。提取它们的核心标识：容器镜像、Pod名称、标签（Labels）、选择器（Selectors）。
• 容器运行时关联：将第一步发现的进程映射到其所在的容器。在Kubernetes中，每个容器都有一个唯一的ID。通过容器运行时接口（CRI，如containerd、CRI-O）或查询底层Docker/containerd，可以将宿主机PID关联到具体的Kubernetes Pod。
• 交叉比对：将运行时发现的、与AI相关的进程/容器，与Kubernetes API提供的资源清单进行比对。如果一个进程满足以下所有条件，它就是一个强力的“幽灵”候选者：
  1. 正在进行AI相关的网络活动。
  2. 运行在Kubernetes节点上（即在容器内）。
  3. 无法关联到任何一个当前由Kubernetes控制器管理的、活跃的Pod资源。或者，其所属的Pod是一个“裸Pod”（即不被任何控制器管理），且没有对应的YAML定义在版本控制中。

3.4 第四层：内核级深度可见性（eBPF）

对于拥有节点操作权限的环境（如自建K8s集群），我们可以使用更强大的武器——eBPF。它允许我们以安全、高效的方式在内核层面追踪系统调用，提供无可辩驳的行为证据。

实现要点：

• 选择eBPF工具：我们选用Tetragon。它是一个基于eBPF的Kubernetes原生安全可观测性工具，能够实时追踪进程执行、文件访问和网络活动等系统调用。
• 追踪关键事件：
  • execve系统调用：捕获所有进程执行事件。可以过滤出启动Python解释器、并带有可疑参数（如包含“agent”、“openai”、“pinecone”等关键词的脚本路径）的事件。
  • connect系统调用：在更底层捕获网络连接尝试，直接关联到发起连接的进程，比用户态的netstat更及时、更难以绕过。
  • openat/read系统调用：监控对敏感文件的访问，例如包含API密钥的配置文件（~/.openai/config， 环境变量文件等）。
• 关联Kubernetes元数据：Tetragon等现代工具能够自动将eBPF事件与Kubernetes元数据（Pod、Namespace、Labels）丰富地关联起来，使得我们能够直接看到“哪个Pod里的哪个进程，在什么时候，执行了什么操作，连接了哪里”。

对于托管集群（EKS, GKE, AKS）的考量：托管Kubernetes服务通常不允许用户安装自定义内核模块或eBPF程序，以保障多租户安全和集群稳定性。在这种情况下，我们退而求其次，主要依赖第三层（K8s API审计）和增强的第一层（通过DaemonSet部署具有特权模式的Pod来执行节点级监控）相结合的策略。虽然深度不及eBPF，但通过分析调度事件、资源变更事件和结合容器运行时的日志，仍然能构建有效的检测能力。

4. AgentDiscover Scanner 实战部署与扫描

理论需要实践验证。下面我将带你一步步使用我们开源的AgentDiscover Scanner，在一个模拟环境或你自己的集群中，亲自体验如何发现“幽灵”。

4.1 环境准备与工具安装

首先，你需要一个可以访问的Kubernetes集群。可以是本地的Minikube、Kind，也可以是云上的EKS、GKE或自建集群。确保你的kubectl已正确配置，能连接到目标集群。

安装Scanner：Scanner是一个Python命令行工具，通过pip即可安装。它被设计为轻量级、无需在集群内安装长期代理。

# 安装 scanner pip install agent-discover-scanner

验证安装：

agent-discover-scanner --version

如果显示版本号，说明安装成功。

4.2 执行集群扫描

Scanner支持多种扫描模式。最全面的模式是scan-cluster，它会自动适配你的集群类型。

# 对当前kubeconfig上下文指向的集群进行扫描，持续监控10秒的网络活动 agent-discover-scanner scan-cluster --duration 10

命令详解：

• scan-cluster: 指示工具扫描整个Kubernetes集群。
• --duration 10: 指定网络活动监控的持续时间（秒）。时间越长，发现低频定时任务的机会越大，但扫描时间也越长。对于初步排查，10-30秒通常足够。

Scanner在后台做了什么？

1. 收集清单：首先，它会快速通过Kubernetes API拉取所有工作负载、配置资源（ConfigMaps, Secrets引用）、服务账户（ServiceAccounts）的清单，建立“声明式资产索引”。
2. 部署临时监控Pod：为了监控网络和进程，Scanner会在你的集群的kube-system或default命名空间（取决于权限）中，创建一个带有特权模式（privileged: true）或必要Linux能力（CAP_SYS_ADMIN,CAP_NET_ADMIN）的DaemonSet。这个DaemonSet是临时的，扫描结束后会自动清理。它的Pod会在每个节点上运行，执行短暂的监控任务。
3. 执行四层检测：
   • 临时Pod收集各节点的进程列表和网络连接。
   • 尝试与Kubernetes容器运行时交互，将进程映射到容器和Pod。
   • 如果集群配置允许且用户授权，会尝试部署基于eBPF的深度检测（通过Tetragon的轻量级部署）。
   • 最后，进行交叉关联分析。
4. 生成报告：所有数据收集完毕后，临时资源被清理，分析结果在本地终端以表格形式输出，并保存为JSON或HTML报告。

4.3 解析扫描结果

执行完扫描后，你会看到一个结构化的输出，类似于我们在开篇案例中展示的那样。我们来详细解读一下这个报告：

🤖 Autonomous Agent Inventory ┏━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Classification ┃ Count ┃ Description ┃ ┡━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩ │ CONFIRMED │ 2 │ Active — detected in code and observed at runtime │ │ UNKNOWN │ 3 │ Code found — not yet observed at runtime │ │ SHADOW AI │ 0 │ Known app using AI — review for governance │ │ ZOMBIE │ 0 │ Inactive — code exists but no recent runtime activity │ │ GHOST │ 1 │ ⚠ Critical — runtime activity with no source code (ungoverned) │ └────────────────┴───────┴────────────────────────────────────────────────────────────────┘ Risk Breakdown: ● Critical: 1 ● High: 2 ● Medium: 3 ● Low: 0

分类说明：

• CONFIRMED (已确认)：在源代码或配置中声明，并且在运行时也被观测到的AI智能体。这是理想状态，表示资产可追溯、可管理。
• UNKNOWN (未知)：在代码库中发现了AI框架的使用痕迹（如import语句），但在本次扫描的监控窗口内，未观测到其对应的运行时活动。可能是未部署、已下线或执行频率极低。
• SHADOW AI (影子AI)：已知的非AI核心应用程序，被发现正在使用AI功能（例如，一个用户管理服务悄悄调用了文本摘要API）。需要审查其AI使用是否经过审批和合规。
• ZOMBIE (僵尸)：代码库中存在AI智能体代码，但长时间（可配置，如7天）没有观测到任何运行时活动。可能是被遗弃的旧功能，需要清理。
• GHOST (幽灵)：关键发现。在运行时观测到活跃的AI活动（进程、网络连接），但在代码库、部署清单或任何配置中找不到对应的声明。这是最高风险项。

报告详情：除了摘要表格，Scanner还会生成一个详细列表，列出每一个被发现的实体。对于一个“幽灵”条目，报告通常会包含：

• 进程信息：PID、命令行、可执行文件路径。
• 网络连接：目标IP/域名、端口、连接状态。
• 容器上下文：容器ID、镜像名称（如果可识别）。
• Kubernetes关联尝试结果：明确提示“未找到匹配的Pod/Deployment资源”。
• 证据时间线：首次和最后一次被观测到的时间。

在我们的案例中，那个每4分钟调用一次OpenAI和Pinecone的Python进程，就被标记为GHOST，风险等级为Critical。报告显示它已运行约11天。

4.4 高级扫描与集成

Scanner还提供了更精细的扫描选项：

# 扫描指定的命名空间 agent-discover-scanner scan-cluster -n ai-team,production --duration 30 # 启用eBPF深度检测（需要集群支持） agent-discover-scanner scan-cluster --deep-ebpf --duration 10 # 将结果输出为JSON文件，便于集成到CI/CD或安全平台 agent-discover-scanner scan-cluster --duration 10 --output-format json --output-file scan_results.json # 结合静态代码分析，提供完整的资产视图（需提供代码路径） agent-discover-scanner scan-all ~/projects/my-ai-app --duration 10

scan-all命令会同时执行静态代码扫描和动态集群扫描，实现“声明”与“现实”的完整比对。

5. 响应与治理：发现“幽灵”之后该怎么办？

扫描出“幽灵”智能体只是第一步，更重要的是如何安全、有效地处置它，并建立长效机制防止其再次出现。这是一个需要开发、运维和安全团队协同工作的过程。

5.1 即时响应流程

一旦确认一个“幽灵”智能体，建议遵循以下步骤：

1. 隔离而非立即终止：首先，不要盲目地kill -9进程或删除Pod。突然终止一个正在处理任务或持有数据库连接的Agent可能导致数据不一致或业务中断。优先进行网络隔离。

   • 在Kubernetes中：如果该进程运行在某Pod内，可以修改该Pod的NetworkPolicy，拒绝其所有出站流量，特别是到外部AI API和内部数据库的流量。如果它是一个“裸Pod”，可以为其添加一个“隔离”标签，然后通过NetworkPolicy针对该标签进行阻断。
   • 在节点层面：可以使用主机防火墙（如iptables）临时屏蔽该进程所属容器的虚拟网卡（veth）对外的特定连接。

2. 取证与影响评估：

   • 审查进程与连接：记录完整的命令行、环境变量、打开的文件描述符。使用lsof -p <PID>或通过/proc/<PID>/目录获取详细信息。
   • 检查数据访问：分析它的网络连接目标。它访问了哪些数据库（如Pinecone索引名）？调用了哪些内部API？评估可能被读取或写入的数据范围。
   • 审查API密钥与凭证：这个Agent使用什么身份进行认证？是硬编码在脚本中的密钥，还是通过Pod的ServiceAccount绑定的Kubernetes Secret？立即在相应的云平台或内部认证系统中审查该凭证的调用日志，查看其历史活动。

3. 溯源与责任人识别：

   • 查询集群审计日志：Kubernetes API Server的审计日志可能记录了是谁创建了那个临时Pod（如果它是通过kubectl run创建的）。查询kubectl命令、来源IP和时间。
   • 检查镜像来源：如果进程来自某个容器镜像，检查该镜像的构建历史和推送者。是谁在什么时候构建并推送的？
   • 沟通与询问：在隔离后，立即在相关团队（开发、数据科学、运维）内沟通，询问是否有人知道这个进程的用途。很多时候，“幽灵”只是被遗忘的合法工具。

4. 制定处置方案：

   • 如果是合法的、被遗忘的资产：将其“合法化”。将代码提交至版本控制系统，编写Dockerfile和Kubernetes部署清单，通过CI/CD管道重新部署。更新相关文档，并通知安全团队将其纳入常规监控。
   • 如果是未经授权的测试或临时工具：与相关开发者确认后，如果不再需要，在确保无后续影响后，安全地终止进程并清理相关资源（如临时配置文件、CronJob等）。
   • 如果是恶意或未知来源的：立即启动安全事件响应流程。保留所有证据（内存转储、磁盘文件、网络包捕获），彻底清理相关资源，轮换所有可能泄露的凭证，并进行全面的安全审查。

5.2 建立长效治理机制

根除“幽灵”需要从流程和文化上入手，而不仅仅是技术检测。

1. 将AI智能体纳入软件开发生命周期（SDLC）：

   • 定义AI资产：明确什么是“AI智能体”。任何包含LLM调用、具备自主任务执行能力的代码模块或服务，都应被识别为AI资产。
   • 强制代码仓库化：制定政策，禁止在生产环境直接运行来自本地IDE、临时脚本或未经验证的镜像的AI代码。所有生产代码必须源自受控的Git仓库。
   • CI/CD流水线集成：在CI阶段加入静态AI代码扫描，识别所有AI框架的使用。在CD阶段，确保所有Kubernetes资源都通过声明式文件（Helm, Kustomize）部署，并经过合规性检查。

2. 实施动态的运行时安全监控：

   • 将AgentDiscover Scanner集成到监控流水线：不是一次性工具，而是定期（如每小时）或持续运行的监控组件。可以将其作为CronJob运行在集群内，将结果发送到安全团队的SIEM或告警平台（如Slack, PagerDuty）。
   • 定义告警规则：对任何新出现的、未在清单中注册的AI进程（即“幽灵”），触发高优先级告警。对“影子AI”和“未知”类别的资产，触发中优先级审查工单。
   • 利用服务网格（Service Mesh）进行策略控制：对于像Istio或Linkerd这样的服务网格，可以编写授权策略（AuthorizationPolicy），明确规定哪些服务可以访问外部的AI API端点（如api.openai.com:443）。任何未经授权的Pod尝试建立此类连接，都会被拦截并产生告警日志。

3. 提升凭证与访问管理：

   • 禁止硬编码密钥：强制要求所有AI服务（OpenAI, Pinecone等）的API密钥必须通过Kubernetes Secret管理，并以环境变量或卷挂载的方式注入容器。
   • 使用细粒度的云IAM角色：为每个AI应用创建独立的云服务账户（如GCP Service Account, AWS IAM Role），并授予其完成任务所需的最小权限。避免使用集群节点或宽泛的默认服务账户。
   • 定期审计凭证使用情况：利用云提供商的审计日志或专用密钥管理服务（如HashiCorp Vault）的审计功能，定期检查API密钥的调用情况，发现异常模式或未授权使用。

4. 培养安全左移的文化：

   • 对开发者进行教育：向开发者和数据科学家阐明“幽灵”智能体的风险——不仅是安全风险，还有成本失控（API调用费用）和数据泄露的风险。
   • 提供便捷的“合法化”路径：让提交代码、构建镜像、部署到测试环境变得非常简单。如果合法路径比走捷径更顺畅，人们自然会选择前者。
   • 进行红蓝演练：安全团队可以定期模拟创建“幽灵”智能体，测试检测系统的有效性，并以此为契机培训团队如何响应。

6. 扩展视野：MCP服务器与其他风险

在我们的扫描案例中，除了“幽灵”智能体，报告还提到了另一个发现：2个未经验证的MCP服务器。这揭示了AI安全另一个容易被忽视的维度。

6.1 什么是MCP（模型上下文协议）？

MCP（Model Context Protocol）是一种新兴的协议，旨在为AI模型（特别是智能体）提供标准化的方式来访问外部工具、数据和上下文信息。你可以把它想象成AI的“插件系统”或“驱动程序”标准。一个MCP服务器可以暴露文件系统访问、数据库查询、API调用等能力给AI模型。

6.2 MCP服务器的安全风险

MCP服务器的风险在于其强大的能力和潜在的隐蔽性。

1. 高权限访问：一个MCP服务器可能被配置为允许AI模型读取服务器上的任意文件（包括配置文件、密钥文件），执行系统命令，或访问内部网络服务。
2. 隐蔽部署：开发者可能为了测试方便，在本地或开发容器中快速启动一个MCP服务器。如果这个容器镜像被不小心部署到生产环境，或者其配置被复制到生产配置中，这个高权限的访问通道就被打开了。
3. 缺乏验证：与成熟的软件包仓库（如PyPI, npm）不同，MCP服务器生态还处于早期，缺乏权威的签名验证和发布者审计机制。运行一个从互联网上随意获取的MCP服务器，相当于运行了一个未知来源的、具有高权限的后门。

Scanner如何检测MCP风险？AgentDiscover Scanner的静态分析组件会扫描代码，寻找MCP客户端库（如mcp-client）的导入和使用。同时，在运行时，它会检测是否有进程在监听MCP的标准端口（或已知端口），或者是否有进程加载了MCP相关的库。当发现一个MCP服务器在运行，但其二进制文件或配置来源未被验证（例如，不在批准的软件清单内），它就会被标记为“未验证的MCP服务器”，构成一个需要立即审查的中高风险项。

6.3 其他高风险Agent框架

Scanner的检测库也在不断扩充，以覆盖更多高风险模式。例如，报告中提到的OpenClaw等平台，它们可能因其设计模式（如允许动态代码执行、自动工具发现）而带来更高的潜在风险。Scanner会识别这些框架的使用，并在风险评估中给予更高的权重。

6.4 构建完整的AI资产清单与爆炸半径分析

最终，一次成功的扫描不仅仅是找出问题，更是为了生成一份完整的AI资产清单和爆炸半径分析。

• 资产清单：一份包含所有CONFIRMED、UNKNOWN、SHADOW、ZOMBIE、GHOST类AI资产的详细目录，记录其代码位置、运行位置、配置、依赖和责任人。
• 爆炸半径分析：对于清单中的每一个AI资产，分析其“爆炸半径”——即如果该资产被入侵或出现故障，会影响到哪些系统。
  • 数据访问：它能接触到哪些数据库、数据湖、API？
  • 权限边界：它使用的服务账户或API密钥拥有哪些权限？
  • 网络可达性：它可以与集群内外的哪些服务通信？
  • 下游依赖：有哪些其他服务或用户依赖它的输出？

这份分析报告对于理解AI系统的整体风险态势、进行灾难恢复规划和实施最小权限原则至关重要。

发现“幽灵”不是终点，而是构建可观测、可治理、安全的AI生产环境的起点。通过将运行时检测与左移的安全实践相结合，我们可以在享受AI Agent带来的自动化红利的同时，牢牢守住安全的底线。工具是辅助，真正的安全源于对每一行生产代码的敬畏，以及对运行时状态永不松懈的关注。