MCP Server 真正危险的地方在于它把代码执行能力包装成了一个看起来很温和的 JSON-RPC 接口。一个文件读写工具、一个 Shell 执行工具在 Agent 眼里只是“tool”在攻击者眼里就是一台没有售货员的自动取款机。我前阵子做本地工具层安全加固最头疼的还不是功能不稳定而是本地 MCP Server 被随意调用——curl 一下 127.0.0.1 的端口或者往标准输入塞一段 JSON-RPC我的 Agent 就能被远程操纵去读写文件。更隐蔽的是“劫持”。合法的客户端进程还在运行但它的子进程、环境变量、动态库加载路径已经被污染攻击者借着一个“合法身份”对 MCP Server 发号施令。单纯加 Token、加 IP 白名单在这种场景下基本是纸糊的锁。这篇文章想和你聊聊我在 MCP Server 上落地的一层基于“进程父子关系校验”的内核级安全锁。它的核心思路不复杂进程的 PID、PPID、启动时间这些属性由操作系统内核维护用户态进程很难伪造。我们只要判断“当前调用 MCP Server 的进程是否真的由一个可信入口进程派生出来”就能把绝大多数的非法调用和劫持挡在门外。适合正在做 MCP Server 开发、Agent 工具平台、或者给本地 AI 工具做安全加固的同学参考。1. 为什么要在 MCP Server 前面做进程级防护1.1 MCP Server 的真实攻击面在哪MCP 全称 Model Context Protocol核心模型是 client-server 之间用 JSON-RPC 交换工具列表和调用请求。一个 Agent 能查文件、执行脚本、访问网络本质上都是因为这些工具暴露给了模型。问题在于很多本地 MCP Server 为了方便直接监听 localhost或者干脆用标准输入输出通信把“谁能访问”这件事完全交给了系统。这就等于把保险柜钥匙挂在了门口。恶意进程只要能往这个端口或管道里塞入合法的 JSON-RPC 数据就能触发工具调用。Chrome 浏览器自动化类 MCP Server 尤其典型它经常需要打开本地调试端口一不小心就会被任意网页探测到。所以 MCP Server 的攻击面不只是“网络端口”还包括本机任意进程的 IPC 通道。要防住这类攻击传统的办法是“让 Server 知道谁在调用它”。但大多数实现只是拿一个 Token 或者 API Key 做判断。Token 是应用层的东西只要 Server 进程的内存被读到或者启动参数被看到Token 就等于公开了。我们需要一个更底层、更难伪造的身份信息。1.2 非法调用和劫持是两类完全不同的问题我在加固过程中最大的体会是非法调用和劫持不能混为一谈。非法调用是一个不该来的进程发起请求。比如某个爬虫脚本扫描到了 127.0.0.1 上的 MCP 端口尝试调用工具。这时候我们只需要判断“调用方是不是我认识的进程”。劫持是合法进程被冒用或污染。攻击者没有直接发起调用而是让合法进程“变坏”。常见的手法包括修改 PATH 环境变量让 Agent 框架启动 MCP Server 时执行了攻击者的 wrapper 脚本。注入 LD_PRELOAD / DYLD_INSERT_LIBRARIES让 MCP Server 在启动时加载恶意动态库。修改系统代理配置比如 Windows 下的 AutoconfigURL / IE 自动配置脚本劫持让 MCP Server 发出的 fetch 请求全部走攻击者代理。这两种问题处理思路不同。非法调用靠“来源校验”劫持靠“链路完整性校验”。进程父子关系校验主要解决第一类问题但它也是第二类问题的地基先把“调用者身份是不是可信入口派生”这事搞清楚再去谈环境是否被污染。1.3 为什么我不建议只做 IP 白名单和 Token有同学会说我在 MCP Server 里加一个 Bearer Token 不就行了吗实测下来Token 的维护成本很高而且防不住本机攻击。本机恶意进程可以通过读取 Server 进程的环境变量拿到 Token也可以直接 hook Server 的 socket 读写函数把 Token 截走。IP 白名单更弱。监听 localhost 时所有本机进程的源地址都是 127.0.0.1根本区分不出是谁。如果 Server 跑在局域网攻击者伪造一个内网 IP 也不是什么难事。进程父子关系校验的优势在这里体现得很明显PID 和 PPID 是操作系统内核在进程创建时写死的用户态进程没有接口去“指定”自己的父进程是谁。我们只要像查户口一样沿着 PPID 一路向上追溯就能确认当前调用链是不是从一个受信任的根进程长出来的。这个属性没法通过伪造 HTTP Header 或改配置绕过。2. 父子关系校验是怎么做到的2.1 沿着 PPID 向上追溯祖先链在 Linux 上进程的父子关系可以通过/proc/pid/stat获取。这个文件里面第四个字段就是父进程 PID。我们从一个候选进程开始不停地读它的 PPID就能得到一条完整的祖先链。举个例子完整的启动链可能是systemd(1) → 用户桌面(2456) → Agent 客户端(3821) → mcp-server-tool(4096)当我们收到一个来自 PID 4096 的调用时向上追溯得到的祖先链是[4096, 3821, 2456, 1]。如果配置的信任根 PID 是 3821就说明这个 MCP Server 确实是由 Agent 客户端拉起的可以放行。这里有个细节要注意拿到 PPID 之后要一直循环到 PID 1 为止。因为中间任何一层都可能是攻击者插进来的进程。只校验“父进程的 PID 是否是期望值”是不够的必须看整条链。比如攻击者可能启动一个自己的进程再让这个进程 fork 出 MCP Server 子进程这时候的第一层父进程就不是可信进程了。2.2 只认 PID 不够还要认启动时间如果只校验 PID很快会踩到一个坑PID 会被复用。Linux 内核分配 PID 是一个递增再回绕的过程某个进程退出后它的 PID 可能被新进程重复使用。假设攻击者先让可信进程退出再立刻启动一个同名进程抢到同一个 PID那么单纯比对 PID 的校验就会被绕过。解决办法是把“PID 启动时间”作为进程唯一标识。Linux 的/proc/pid/stat里有很多时间戳其中 starttime 表示进程相对于系统启动的时间单位是 clock tick。把这个值一起读出来和信任根 PID 的启动时间一起传给 MCP Server校验时就同时比对 PID 和 starttime。PID 可以被复用但同一时间点只能存在一个进程starttime 几乎不可能被伪造。2.3 信任根进程是怎么确定的所谓“信任根”就是整个进程树中最上层的那个“可信发起者”。在实际场景里它可以是你手动启动的 Agent 客户端主进程一个固定的命令行启动器一个系统服务管理工具如 systemd-run 启动的用户服务。MCP Server 本身是信任根的孙子、重孙子我们通过环境变量或启动参数把信任根的 PID 传下去。比如客户端 spawn 子进程时设置环境变量MCP_TRUSTED_ROOT_PID为自身的 process.pid。这里有一个容易踩的坑不要用 Shell 里的$PPID来传。Shell 的$PPID指向的是当前 Shell 的父进程可能是一个终端、一个 CI 系统、甚至已经被攻击者替换过的 wrapper。正确做法是在你真正可信的客户端代码里显式把process.pid写入子进程环境变量而不是依赖 Shell 解释器的隐式行为。3. 实操在 MCP Server 中落地父子关系校验3.1 客户端把可信 PID 传下去假设你正在用 Node.js 的 child_process 启动一个 MCP Server代码可以这样写const { spawn } require(child_process); const child spawn(/usr/local/bin/mcp-server-tool, [], { stdio: [pipe, pipe, pipe], env: { ...process.env, MCP_TRUSTED_ROOT_PID: String(process.pid), }, });如果 MCP Server 是由某个 Agent 框架自动拉起的而这个框架不开放环境变量透传配置我的建议是写一个 wrapper 启动器。wrapper 脚本专门负责做两件事一是记录并透传可信 PID二是清理环境变量然后再 exec 真正的 MCP Server 二进制。在生产环境尽量使用绝对路径启动 MCP Server不要依赖 PATH 搜索。PATH 搜索是最容易被劫持的环节攻击者只要放进一个同名的可执行文件就能在你不知情的情况下替换整个程序。父子关系校验解决的是“谁生了我”的问题绝对路径解决的是“我是什么”的问题两者要配套使用。3.2 读取祖先链并比对下面是一段可以在 Linux 上直接使用的 Python 实现。思路是从当前 Server 进程的父进程开始沿着 PPID 向上追溯然后检查祖先链里是否包含信任根 PID 和启动时间。import os import re import sys def _read_stat(pid: int) - str: with open(f/proc/{pid}/stat, r, encodingutf-8, errorsignore) as f: return f.read() def _get_ppid_and_starttime(pid: int): 返回 (ppid, starttime)解析时处理进程名包含空格和右括号的情况。 stat _read_stat(pid) # comm 字段可能包含空格和右括号所以从最后一个 ) 后开始找剩余字段 right stat.rfind()) fields stat[right 2:].split() state fields[0] # 字段3 ppid int(fields[1]) # 字段4 starttime int(fields[19]) # 字段22从 fields[0] 开始数第19个 return ppid, starttime def get_ancestor_chain(pid: int): 返回祖先链元素为 (pid, starttime)从当前进程一直到 PID 1。 chain [] seen set() current pid while current 1 and current not in seen: seen.add(current) try: ppid, starttime _get_ppid_and_starttime(current) except FileNotFoundError: break chain.append((current, starttime)) if ppid current: break current ppid return chain def is_trusted_caller(caller_pid, trusted_root_pid, trusted_root_starttime) - bool: chain get_ancestor_chain(caller_pid) for pid, starttime in chain: if pid trusted_root_pid and starttime trusted_root_starttime: return True return False if __name__ __main__: trusted_pid int(os.environ.get(MCP_TRUSTED_ROOT_PID, 0)) trusted_start int(os.environ.get(MCP_TRUSTED_ROOT_STARTTIME, 0)) # 这里 caller_pid 在 stdio 模式下通常是 os.getppid() caller_pid os.getppid() ok is_trusted_caller(caller_pid, trusted_pid, trusted_start) print(ancestors:, get_ancestor_chain(caller_pid)) print(trusted:, ok)使用方式是在启动 MCP Server 时把信任根的 starttime 也一起传过去。客户端在 Linux 上可以通过同样的/proc/self/stat解析出自己的 starttime然后放进环境变量。这一步不能省否则你会遇到 PID 复用导致的间歇性放行。3.3 校验放在 MCP 协议的哪个环节MCP Server 的入口有几种最常见的是 stdio transport 和 Streamable HTTP transport。校验位置选择直接影响安全性。对于 stdio transportMCP Server 进程的直接父进程通常就是启动它的客户端。此时可以用os.getppid()作为 caller_pid然后向上追溯祖先链。如果客户端本身也是被某个上层框架拉起的祖先链会自然包含那个上层进程。对于监听 HTTP 的本地 MCP Server建议优先使用 Unix Socket 加SO_PEERCRED获取对端进程 PID而不是依赖 HTTP Header 里传来的 PID。HTTP Header 是文本任何人改个 Header 就能伪造。SO_PEERCRED是内核在 accept 时填充的进程凭证无法在应用层伪造。import socket import struct def get_peer_pid(sock: socket.socket) - int | None: if sys.platform.startswith(linux): # SO_PEERCRED 返回 struct ucred { pid_t pid; uid_t uid; gid_t gid; } cred sock.getsockopt(socket.SOL_SOCKET, socket.SO_PEERCRED, struct.calcsize(3i)) pid, uid, gid struct.unpack(3i, cred) return pid return None校验时机上我建议做两层在initialize请求时做一次强校验校验失败直接断开连接。在每次工具调用请求前做一次轻量校验。为什么每次都要校验因为 MCP Server 进程可能会 fork 出子进程处理任务而调用方进程也可能在会话中途被替换。一次校验不能覆盖整个生命周期。好在读取几个/proc文件的开销很小实测每次几十微秒级别对工具调用来说完全可接受。3.4 跨平台怎么做Linux 上/proc是最好用的但 macOS 和 Windows 没有这么方便。macOS 可以通过sysctl(KERN_PROC_PID)拿到进程信息包括父进程和启动时间。Windows 则可以用 Toolhelp32 快照CreateToolhelp32SnapshotPROCESSENTRY32枚举进程其中th32ParentProcessID就是父进程 PID。Windows 的启动时间需要通过OpenProcess拿到句柄后再调用GetProcessTimes获取。跨平台实现确实麻烦但核心逻辑不变拿到当前 MCP Server 自己的 PID以及调用方进程 PID向上追溯完整祖先链最后和信任根进程做比对。只要保证同一套“信任根 PID 启动时间”的传递机制各平台的行为就能保持一致。4. 劫持攻击路径与排查实录4.1 我遇到过的一个典型环境劫持场景有一次线上排查MCP Server 日志显示所有工具调用都来自可信进程但行为非常可疑。后来发现攻击者没有直接碰 MCP Server而是修改了 HOME 目录下某个配置文件的路径解析。启动 MCP Server 的客户端被引导去执行了一个攻击者提供的脚本脚本内部再 exec 真正的 Server 二进制。由于 exec 之后进程 PID 不变从 MCP Server 的角度看父进程还是那个合法客户端祖先链完全正常。这类“前置环境劫持”恰恰说明进程父子关系校验不是银弹。要补上这个洞需要在启动器这一层做两件事使用绝对路径指定可执行文件禁止 PATH 搜索。启动前对关键路径做完整性检查比如比对可执行文件的哈希值和签名。父子关系校验在这个过程中仍然有价值它让攻击者至少不能直接复用“已经存在的合法进程通道”只能从更上游动手。动手的位置越上游暴露面越大被监测到的概率也越大。4.2 代理配置劫持和 MCP 请求劫持的关系有段时间大家在讨论 Linux 下的系统代理劫持Windows 下的 AutoconfigURL / IE 自动配置脚本劫持也是同一个套路。攻击者通过注册表或浏览器策略把系统的自动配置脚本指向恶意 URL。MCP Server 内部如果用了fetch或 HTTP 客户端去回调外部服务请求就会自动走进攻击者控住的代理。这种劫持不发生在 TCP 层也不是简单改 Header而是网络库初始化时主动读取了被污染的系统代理配置。发现“请求没发到该去的地方”时如果只盯着进程父子关系方向就完全错了。我的建议是给 MCP Server 的网络客户端独立配置代理参数不自动跟随系统代理。具体做法包括显式设置NO_PROXY白名单内部服务地址永远不走代理。对回调 URL 做域名白名单非白名单一律拒绝。Windows 环境下定期检查 AutoconfigURL 注册表项发现非预期变更就告警。进程父子关系校验解决的是“谁在调用”代理配置校验解决的是“流量往哪走”。两者是不同层的问题不能混着用。4.3 排查步骤当 MCP Server 开始干奇怪的事如果你怀疑本地 Agent 工具栈被劫持按下面这个顺序排查最省力打开 MCP Server 的详细日志重点看每次请求记录到的 caller_pid 和祖先链。用ps -ef --forest或pstree -p查看整个进程树确认是否存在异常中间进程。用strace -f -e traceprocess -p mcp_server_pid跟踪 MCP Server 的 fork 和 exec 行为。用lsof -p mcp_server_pid查看 Server 进程打开的文件和网络连接。检查环境变量重点看LD_PRELOAD、DYLD_INSERT_LIBRARIES、PATH是否被非预期修改。如果怀疑代理劫持直接在 MCP Server 的日志里打印最终代理配置和使用 proxy.pac 文件的内容对比。有一次排查就是靠第一步拿到线索的。日志里同一个 caller_pid 的祖先链前后不一致说明调用方在会话中途被替换过。顺着线索去查发现是某个定时任务不干净把合法客户端重启后换了注入过的动态库。4.4 常见问题速查现象可能原因处理办法Server 重启后校验失败可信根 PID 被新进程复用把 PID 和 starttime 一起传比对两者容器里祖先链到 PID 1 就断PID namespace 隔离通过环境变量传递宿主侧 PID或在同一 pid namespace 内运行macOS 读不到 /proc 文件macOS 没有 procfs改用 sysctl KERN_PROC 接口Windows 获取的父进程 ID 不对Toolhelp32 遍历权限不足确认进程以同一用户身份运行必要时使用受限管理员句柄IDE 内置 MCP 客户端被拦截客户端不在受信祖先链中通过 wrapper 设置受信 PID或用开发模式放行校验通过但行为仍异常进程被注入或环境被污染检查动态库预加载、环境变量、可执行文件哈希5. 让这层校验更硬的进阶做法5.1 先清场再校验顺序很重要MCP Server 启动时自身可能会加载很多动态库。如果攻击者通过环境变量注入了LD_PRELOAD那么你的校验代码本身也可能被 hook。所以严格意义上校验必须发生在任何外部库被信任之前。实际工程里我建议用一个“最小启动器”来做这件事。启动器只做三件事清理环境变量中的危险项。解析/proc或sysctl计算信任根祖先链。通过 exec 或 pipe 校验后再拉起真正承载业务逻辑的 MCP Server 进程。启动器本身要尽量静态编译不依赖系统动态库降低被预加载注入的可能。这一步看着啰嗦但在高安全场景下非常值得。5.2 配合 seccomp 缩小攻击面进程父子关系校验只能确认“调用方的身份”不能保证“调用方是干净的”。为了降低单点失守后的影响可以把运行 MCP Server 的用户态进程用 seccomp 约束起来。比如只允许需要的系统调用白名单禁止加载内核模块、ptrace 附加、修改进程内存等危险操作。这样即使攻击者拿到了 MCP Server 进程的代码执行权也无法轻易横向移动。Linux 上实现时可以用seccomp_uname加载一个简单的过滤器只放行文件读写、socket、poll 等必要调用。这里面的细节较多建议单独做一次压力测试否则很容易误伤正常业务逻辑。5.3 后续可以补上的几个扩展点如果你团队的安全要求更高还可以在这些方向上继续加固可执行文件签名校验启动时检查 MCP Server 以及客户端二进制的代码签名。审计日志外发把校验通过/失败的事件实时上报到集中日志平台而不是只写在本地。调用链路追踪给每次 MCP 请求分配 trace_id和调用方的进程元数据绑定方便事后回溯。这些手段和父子关系校验并不冲突它们是同一个安全模型的叠加层。底层身份锚点越扎实上层加再多的策略都不会觉得虚。我在实际加固过程中最深的体会是安全手段必须成环不能靠单点。PID 校验负责确定“谁在调用”绝对路径和哈希校验负责确定“程序是什么”代理白名单负责确定“流量去哪”。当这三个环扣在一起时标题里说的“非法调用与劫持”才真正有了被压住的可能。最后再分享一个小技巧传给 MCP Server 的信任根信息不要只传 PID把启动时间也带上服务端校验失败的时候把祖先链完整打印到日志。不要只打印“校验失败”这四个字否则你在茫茫日志里根本无从下手。把祖先链打出来你一眼就能看出多出来的那个中间进程是谁排查效率能提升一个量级。