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 典型的“幽灵”引入场景在实际开发运维中“幽灵”智能体的产生往往源于一些看似合理甚至高效的实践但这些实践绕过了既定的管控流程。生产环境直接调试这是最常见的原因。开发者需要测试一个依赖生产数据库特定数据的Agent。由于在预发Staging环境复制完整的生产数据成本高昂或不可行他们便直接在生产集群的某个Pod内或通过临时Pod运行脚本。测试完成后可能忘了清理或者这个测试脚本被配置成了定时任务CronJob但该CronJob资源并未通过GitOps流程提交。手动应急与热修复线上服务出现了一个紧急问题初步判断某个AI推理逻辑有误。运维人员通过kubectl exec进入容器直接编辑并重启了Agent进程或者替换了某个Python文件。这个热修复生效了但对应的代码变更和配置更新没有及时回写到代码库和部署清单中导致运行时状态与版本控制严重偏离。第三方脚本与承包商工作外部团队或承包商在协助开发时可能会将自己的工具脚本直接放置在集群内运行。这些脚本的交付物可能只是一个压缩包或几句安装命令并未纳入主项目的代码管理和部署体系。当合作结束后这些脚本可能仍在默默运行。Agent框架的副作用一些Agent框架或工作流引擎如AutoGen、LangGraph在运行时可能会动态创建和管理子进程来执行任务。如果框架本身异常退出或被终止这些子进程有可能变成“孤儿进程”继续运行脱离了父框架的生命周期管理和可视范围。基于会话的临时部署使用kubectl run my-agent --imagepython: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连接及其对应的进程IDPID。识别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提供的资源清单进行比对。如果一个进程满足以下所有条件它就是一个强力的“幽灵”候选者正在进行AI相关的网络活动。运行在Kubernetes节点上即在容器内。无法关联到任何一个当前由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已正确配置能连接到目标集群。安装ScannerScanner是一个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在后台做了什么收集清单首先它会快速通过Kubernetes API拉取所有工作负载、配置资源ConfigMaps, Secrets引用、服务账户ServiceAccounts的清单建立“声明式资产索引”。部署临时监控Pod为了监控网络和进程Scanner会在你的集群的kube-system或default命名空间取决于权限中创建一个带有特权模式privileged: true或必要Linux能力CAP_SYS_ADMIN,CAP_NET_ADMIN的DaemonSet。这个DaemonSet是临时的扫描结束后会自动清理。它的Pod会在每个节点上运行执行短暂的监控任务。执行四层检测临时Pod收集各节点的进程列表和网络连接。尝试与Kubernetes容器运行时交互将进程映射到容器和Pod。如果集群配置允许且用户授权会尝试部署基于eBPF的深度检测通过Tetragon的轻量级部署。最后进行交叉关联分析。生成报告所有数据收集完毕后临时资源被清理分析结果在本地终端以表格形式输出并保存为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 10scan-all命令会同时执行静态代码扫描和动态集群扫描实现“声明”与“现实”的完整比对。5. 响应与治理发现“幽灵”之后该怎么办扫描出“幽灵”智能体只是第一步更重要的是如何安全、有效地处置它并建立长效机制防止其再次出现。这是一个需要开发、运维和安全团队协同工作的过程。5.1 即时响应流程一旦确认一个“幽灵”智能体建议遵循以下步骤隔离而非立即终止首先不要盲目地kill -9进程或删除Pod。突然终止一个正在处理任务或持有数据库连接的Agent可能导致数据不一致或业务中断。优先进行网络隔离。在Kubernetes中如果该进程运行在某Pod内可以修改该Pod的NetworkPolicy拒绝其所有出站流量特别是到外部AI API和内部数据库的流量。如果它是一个“裸Pod”可以为其添加一个“隔离”标签然后通过NetworkPolicy针对该标签进行阻断。在节点层面可以使用主机防火墙如iptables临时屏蔽该进程所属容器的虚拟网卡veth对外的特定连接。取证与影响评估审查进程与连接记录完整的命令行、环境变量、打开的文件描述符。使用lsof -p PID或通过/proc/PID/目录获取详细信息。检查数据访问分析它的网络连接目标。它访问了哪些数据库如Pinecone索引名调用了哪些内部API评估可能被读取或写入的数据范围。审查API密钥与凭证这个Agent使用什么身份进行认证是硬编码在脚本中的密钥还是通过Pod的ServiceAccount绑定的Kubernetes Secret立即在相应的云平台或内部认证系统中审查该凭证的调用日志查看其历史活动。溯源与责任人识别查询集群审计日志Kubernetes API Server的审计日志可能记录了是谁创建了那个临时Pod如果它是通过kubectl run创建的。查询kubectl命令、来源IP和时间。检查镜像来源如果进程来自某个容器镜像检查该镜像的构建历史和推送者。是谁在什么时候构建并推送的沟通与询问在隔离后立即在相关团队开发、数据科学、运维内沟通询问是否有人知道这个进程的用途。很多时候“幽灵”只是被遗忘的合法工具。制定处置方案如果是合法的、被遗忘的资产将其“合法化”。将代码提交至版本控制系统编写Dockerfile和Kubernetes部署清单通过CI/CD管道重新部署。更新相关文档并通知安全团队将其纳入常规监控。如果是未经授权的测试或临时工具与相关开发者确认后如果不再需要在确保无后续影响后安全地终止进程并清理相关资源如临时配置文件、CronJob等。如果是恶意或未知来源的立即启动安全事件响应流程。保留所有证据内存转储、磁盘文件、网络包捕获彻底清理相关资源轮换所有可能泄露的凭证并进行全面的安全审查。5.2 建立长效治理机制根除“幽灵”需要从流程和文化上入手而不仅仅是技术检测。将AI智能体纳入软件开发生命周期SDLC定义AI资产明确什么是“AI智能体”。任何包含LLM调用、具备自主任务执行能力的代码模块或服务都应被识别为AI资产。强制代码仓库化制定政策禁止在生产环境直接运行来自本地IDE、临时脚本或未经验证的镜像的AI代码。所有生产代码必须源自受控的Git仓库。CI/CD流水线集成在CI阶段加入静态AI代码扫描识别所有AI框架的使用。在CD阶段确保所有Kubernetes资源都通过声明式文件Helm, Kustomize部署并经过合规性检查。实施动态的运行时安全监控将AgentDiscover Scanner集成到监控流水线不是一次性工具而是定期如每小时或持续运行的监控组件。可以将其作为CronJob运行在集群内将结果发送到安全团队的SIEM或告警平台如Slack, PagerDuty。定义告警规则对任何新出现的、未在清单中注册的AI进程即“幽灵”触发高优先级告警。对“影子AI”和“未知”类别的资产触发中优先级审查工单。利用服务网格Service Mesh进行策略控制对于像Istio或Linkerd这样的服务网格可以编写授权策略AuthorizationPolicy明确规定哪些服务可以访问外部的AI API端点如api.openai.com:443。任何未经授权的Pod尝试建立此类连接都会被拦截并产生告警日志。提升凭证与访问管理禁止硬编码密钥强制要求所有AI服务OpenAI, Pinecone等的API密钥必须通过Kubernetes Secret管理并以环境变量或卷挂载的方式注入容器。使用细粒度的云IAM角色为每个AI应用创建独立的云服务账户如GCP Service Account, AWS IAM Role并授予其完成任务所需的最小权限。避免使用集群节点或宽泛的默认服务账户。定期审计凭证使用情况利用云提供商的审计日志或专用密钥管理服务如HashiCorp Vault的审计功能定期检查API密钥的调用情况发现异常模式或未授权使用。培养安全左移的文化对开发者进行教育向开发者和数据科学家阐明“幽灵”智能体的风险——不仅是安全风险还有成本失控API调用费用和数据泄露的风险。提供便捷的“合法化”路径让提交代码、构建镜像、部署到测试环境变得非常简单。如果合法路径比走捷径更顺畅人们自然会选择前者。进行红蓝演练安全团队可以定期模拟创建“幽灵”智能体测试检测系统的有效性并以此为契机培训团队如何响应。6. 扩展视野MCP服务器与其他风险在我们的扫描案例中除了“幽灵”智能体报告还提到了另一个发现2个未经验证的MCP服务器。这揭示了AI安全另一个容易被忽视的维度。6.1 什么是MCP模型上下文协议MCPModel Context Protocol是一种新兴的协议旨在为AI模型特别是智能体提供标准化的方式来访问外部工具、数据和上下文信息。你可以把它想象成AI的“插件系统”或“驱动程序”标准。一个MCP服务器可以暴露文件系统访问、数据库查询、API调用等能力给AI模型。6.2 MCP服务器的安全风险MCP服务器的风险在于其强大的能力和潜在的隐蔽性。高权限访问一个MCP服务器可能被配置为允许AI模型读取服务器上的任意文件包括配置文件、密钥文件执行系统命令或访问内部网络服务。隐蔽部署开发者可能为了测试方便在本地或开发容器中快速启动一个MCP服务器。如果这个容器镜像被不小心部署到生产环境或者其配置被复制到生产配置中这个高权限的访问通道就被打开了。缺乏验证与成熟的软件包仓库如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带来的自动化红利的同时牢牢守住安全的底线。工具是辅助真正的安全源于对每一行生产代码的敬畏以及对运行时状态永不松懈的关注。