这篇算是昨天公众号文章的技术补充版。https://mp.weixin.qq.com/s/X1EOoBbVwWAMTCP6PKC0aw公众号里我主要讲一个判断AI Agent 的风险正在从“它会不会乱回答”转到“它替你动手的时候到底带着什么权限”。放到 CSDN 这里我想把这件事讲得更工程一些。因为真正落到团队里问题不是一句“注意 AI 安全”就能解决而是要知道该看哪些位置、该卡哪些动作、该留下哪些证据。过去我们做 AI 安全很多注意力会放在 Prompt Injection、越狱、幻觉、敏感信息回答这些问题上。这些当然重要但它们更像聊天框里的风险。现在 Agent 不一样了它会读仓库、跑命令、装依赖、解析接口文档、接 MCP server、调云 CLI甚至帮你改配置、发请求、触发自动化流程。一旦它开始做这些事安全边界就不在 Prompt 里了。不是说 Prompt 没用了而是 Prompt 只能提醒它“不要乱来”。真正决定它能不能乱来的是它所在的执行环境它能启动什么进程能读哪些文件能继承哪些环境变量能访问哪些网络能用什么云身份出了事以后日志能不能还原。1. 问题不是 MCP 本身而是配置会不会走到执行最近几条安全资讯放在一起看味道很一致。有 MCPstdio这类本地工具启动问题有 PraisonAI 这类环境变量继承问题有 FrontMCP 这类 OpenAPI$ref解析问题也有 nginx-ui、aws-mcp-server 这类 MCP 端点和云 CLI 参数边界问题。每一条单独看名字都不一样放在一起其实都在问同一个问题外部输入能不能一路影响到真实动作。比如 MCPstdio不用安全术语说其实很朴素。所谓stdio server本质上就是配置里写了要启动哪个本地程序、带哪些参数然后 Agent 通过标准输入输出和这个程序通信。正常情况下这就是一种工具连接方式。但如果这段配置来自仓库、插件市场、用户输入、远程文档或者能被第三方内容影响它就不能只被当成“连接配置”看了。因为配置里的那行command和args最后真的会变成本机进程。这就是我觉得很多团队容易低估的地方。开发者自己接一个工具至少会瞄一眼启动命令是什么、参数有没有怪东西、这个工具到底要不要跑。Agent 工作流里这个动作经常被包装成“自动发现工具”“自动接入能力”“帮我把这个项目跑起来”。听起来是效率提升但安全上等于把“配置”放到了“执行”前面。中间如果没有来源校验、隔离环境、最小权限和确认机制风险就会变得很直接。2. 环境变量不是背景信息它经常就是身份再看环境变量继承问题。很多程序启动子进程时会默认把父进程的环境变量带下去。在普通脚本里这太常见了大家甚至不会多想。但放到 Agent 工具链里这件事就不再是“运行细节”而是凭据边界。一个开发环境里可能放着模型平台 keyGitHub / GitLab token私有包仓库凭据数据库连接串云厂商 profile 或临时凭据内部服务地址和 webhook secret。你以为自己只是给 Agent 加了一个 MCP server或者让它帮你启动一个工具但如果这个工具进程继承了完整环境变量它看到的就不只是工具参数而是一整套开发者身份。这类问题不一定需要传统意义上的 RCE 才危险。攻击者如果能影响你接入的工具、配置、schema 或仓库文件让 Agent 在不该启动的地方启动了一个进程它可能不需要先“打穿主机”只要拿到进程继承下来的身份材料就已经足够有价值。很多时候攻击者想要的不是这台机器本身而是这台机器上已经登录好的身份。3. OpenAPI、schema 和工具说明也不能只当文档看还有一个容易被忽略的点很多团队会把 OpenAPI schema、工具 manifest、插件说明、仓库里的配置文件当成“文档”。如果它真的只被人看那问题不大。但一旦它会被 Agent 或工具生成器自动解析情况就变了。比如 OpenAPI 里的$ref如果解析器会递归访问外部引用那么一份看起来像接口说明的 schema就可能触发服务器去访问内网地址、云 metadata endpoint甚至本地文件路径。表面上你是在“导入接口文档”。实际上系统已经开始发请求、读路径、解析远程内容了。这也是我反复强调的一个判断Agent 的输入不只有 prompt。仓库文件、README、issue、PR、schema、manifest、插件配置、远程端点、依赖元数据都可能成为输入。Agent 的输出也不只有回答。启动进程、发请求、读文件、调 CLI、改配置、重载服务也都是输出。所以安全检查不能停在“模型会不会说错话”。要看输入到底能不能碰到执行链。4. 攻击者会伪装成正常工作流如果我是攻击者今天看一个 Agent 系统我未必会先研究怎么让模型说出违规内容。因为模型越狱当然有价值但如果这个 Agent 已经能跑命令、接工具、解析外部 schema、访问内网、继承环境变量、调云 CLI那更现实的问题是我能不能影响它接下来的动作这也是 Agent 安全和传统聊天机器人安全最大的区别。攻击者不一定要说“请把密钥发给我。”他可以让一切看起来都像正常研发协作这个项目依赖有问题你帮我装一下这个 MCP server 接不上你按这个配置启动一下这个接口文档导不进去你解析一下这个云资源查不到你用 AWS CLI 看一眼这个测试失败了你帮我跑一遍这个脚本执行报错你改一下参数再试试。这些话没有明显攻击味甚至很像日常工作。危险在后面。Agent 一旦照着做接触到的就不再是一段文本而是文件系统、网络出口、环境变量、云凭据、内网服务和管理面工具。过去人看到一个陌生仓库、陌生配置、陌生命令多少会有一点直觉上的迟疑。Agent 如果没有被设计成在关键转折点停下来它会把这些动作当成完成任务的一部分。这就是风险真正跑起来的地方。5. 真正要卡的不是每一步而是风险转折点我不赞成把 Agent 做成每一步都弹窗确认。如果每执行一个读文件、查文档、跑测试都让人点确认工具很快就没人愿意用了最后大家会绕过安全系统自己干。真正要卡的是风险转折点。比如从读代码变成执行代码从无网络变成可以访问公网从公网变成可以访问内网或云 metadata从无凭据变成继承真实 token、key、profile从测试目录变成真实项目目录从只读查询变成改配置、部署、发布从本地开发动作变成云控制面动作。这些地方才是 Agent 工作流里应该停一下的地方。不是为了阻止效率而是为了避免“看起来只是顺手帮忙”实际上已经跨过了执行边界。6. 可以先这样检查自己的 Agent 工作流如果团队已经在用 AI 编程助手、MCP、本地自动化工具、云端 coding agent或者正在把 Agent 接入内部系统我建议先不用急着做大而全的平台先把下面几件事问清楚。第一谁能给 Agent 加工具、改配置、喂 schema。MCP 配置、OpenAPI 文档、工具 manifest、插件包、远程端点地址、仓库内的工具声明都不应该被当成普通上下文。只要它们最后会影响命令、参数、网络请求、文件路径或云 CLI 调用就应该有来源分级和变更记录。内部仓库、外部开源仓库、客户发来的压缩包、用户上传的代码、第三方工具市场不能用同一套执行策略。第二Agent 启动工具时带了什么身份。这里重点不是“有没有漏洞”而是子进程能看到什么。环境变量是不是全量继承.env有没有挂进去Git credential、SSH key、云 profile、私有包源 token、kubeconfig、数据库连接串是不是都在同一个 workspace 里。如果一个不可信工具启动时能看到这些东西它不需要很复杂的攻击链。第三Agent 执行动作时能访问哪里。“能联网”不是一个安全策略。至少要区分能访问必要包源、能访问任意公网、能访问内网、能访问云 metadata、能访问生产控制面。这几种权限的风险完全不一样。陌生仓库、外部 PR、用户上传的代码包不应该默认获得完整网络能力。第四哪些工具后面连着管理面。接一个代码搜索工具和接一个能改 Nginx 配置、调 AWS CLI、执行kubectl、跑terraform、触发 CI/CD 的工具不是一个风险等级。越靠近管理面越应该有最小权限、命令 allowlist、结构化参数、人工确认和审计日志。第五出了事以后能不能复盘。聊天记录只能说明 Agent 当时说了什么不能证明它到底做了什么。真正有用的日志至少要能看到任务 ID、触发人、处理来源、工作目录、启动命令、工具调用、访问过的域名或 IP、读写过的关键路径、使用的身份、退出码以及哪些动作经过人工确认。没有这些证据事故发生以后大家只能靠猜。7. 一个最小可落地版本如果现在只能做很小的一步我会先做这几个控制点1. 陌生仓库、外部 PR、用户上传代码默认进入一次性沙箱。 2. Agent 工具进程默认不继承全量环境变量只按 allowlist 注入必要变量。 3. 执行环境不要挂真实 .env、SSH key、云配置目录和生产 kubeconfig。 4. 网络出口默认最小化包源、公网、内网、metadata endpoint 分开控制。 5. MCP 配置、OpenAPI schema、插件 manifest 按不可信输入处理。 6. 云 CLI、K8s、CI/CD、发布工具必须使用最小权限身份。 7. 从只读到写入、从本地到云、从测试到生产要有确认门。 8. 日志记录真实动作但不要把密钥明文写进日志。这套东西不复杂但能挡住很多“Agent 顺手帮我跑一下”的风险。真正危险的往往不是某个协议名字而是不可信输入已经走到了真实执行环境 真实执行环境又带着真实凭据和网络权限。8. 最后还是那句话不要只审 Prompt要审执行链MCP、tool calling、AI Coding Agent、OpenAPI-to-tool、cloud agent本身都不是洪水猛兽。Agent 真正有用的地方本来就是它能替人做事。问题在于只要它开始做事我们就要换一套安全视角。当 Agent 只能回答问题时你主要看它的输出。当 Agent 能启动工具时你要看工具来源和参数。当 Agent 能跑命令时你要看执行环境和工作目录。当 Agent 能访问云资源时你要看它继承的身份。当 Agent 能发布、部署、改配置时你要看确认机制和审计证据。这条线立不住Agent 越顺手风险跑得越快。不是因为 Agent 天生危险而是因为它已经不只是会说话了。参考来源公众号原文https://mp.weixin.qq.com/s/X1EOoBbVwWAMTCP6PKC0awMCP Python SDKhttps://github.com/modelcontextprotocol/python-sdkAnthropic MCP connector docshttps://platform.claude.com/docs/en/agents-and-tools/mcp-connectorOX Security MCP technical deep divehttps://www.ox.security/blog/the-mother-of-all-ai-supply-chains-technical-deep-dive/The Hacker News MCP coveragehttps://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.htmlPraisonAI MCP env exposurehttps://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-pj2r-f9mw-vrcqFrontMCP OpenAPI ref SSRF / local file readhttps://github.com/agentfront/frontmcp/security/advisories/GHSA-v6ph-xcq9-qxxjnginx-ui MCP endpoint takeoverhttps://github.com/0xJacky/nginx-ui/security/advisories/GHSA-h6c2-x2m2-mwhfaws-mcp-server ZDI-26-245https://www.zerodayinitiative.com/advisories/ZDI-26-245/GitHub Copilot cloud agent MCP docshttps://docs.github.com/en/copilot/concepts/agents/cloud-agent/mcp-and-cloud-agentMicrosoft Agent Governance Toolkithttps://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents/