一个企业管理员给 AI 助手点了授权：读邮箱、看日历、查知识库，顺手再接上 CRM。页面上写的是“提升效率”。服务器那边，可能是一套很普通的 Python Web 服务：FastAPI 起接口，Uvicorn 跑进程，后面挂一堆工具。
开发者盯着模型会不会胡说、提示词会不会被注入、权限弹窗怎么设计。安全研究人员这次指向的是 Starlette。
Starlette 是 FastAPI 下面常见的开源 Python Web/ASGI 框架，用来处理异步请求。Starlette 开发者称，它每周下载量达到 3.25 亿次。下载量不能等同于真实部署量，CI 构建、镜像打包、重复安装都会把数字抬高。但这个数字足够说明一件事：它藏在大量服务里。
麻烦在于，AI Agent 后端通常不只存一张用户表。它可能握着邮箱、日历、CRM、数据库、文件系统、企业知识库的 token。
很多人没装过 Starlette，但服务里已经有它
Starlette 不是少数人试玩的 GitHub 项目。它是 Python 异步 Web 服务里常见的一层框架。ASGI 可以简单理解成 Python 异步 Web 服务的接口规范，让服务能处理大量并发请求。很多人用 Uvicorn 跑 FastAPI，Starlette 就在下面工作。
FastAPI 建立在 Starlette 之上。开发者未必主动执行过 pip install starlette，也未必读过它的文档。只要项目用了 FastAPI，生产环境里就很可能带着它。
现在不少 AI 应用看起来很新，工程形态并不新：一个接口收请求，一个工具层去连邮箱、日历、知识库和数据库，再把结果交给模型。外面叫 Agent，里面还是一台暴露服务的 Python 服务器。
源材料还提到，数千个其他开源项目因为依赖 Starlette 而处在风险范围内。一个组件越靠近基础位置，开发者越容易忘记它；等漏洞出现，影响会顺着依赖关系往上冒。
这也是很多 Agent 快速开发教程的问题。视频里
十分钟接好企业助手，代码里 pip install fastapi uvicorn langchain，能跑就算交付。镜像里到底带了哪些包，版本怎么锁，谁负责升级，很少有人问。
等研究人员把名字点到 Starlette，团队才发现，自己维护的不是一个抽象的“AI 产品”，而是一台连着企业系统、还开着接口的服务器。
Agent 后端一旦失守，丢的可能是钥匙
传统 Web 服务被打穿已经够麻烦。用户表、订单、业务数据都可能出事。
Agent 后端更麻烦。它经常替用户保存访问外部系统的凭据。
尤其是 MCP server。MCP 的作用，是让 Agent 访问外部资源，比如邮件、日历、数据库、CRM、文件系统和企业知识库。原文里有一句话很直接：MCP servers store credentials for each one, making them especially valuable storehouses for attackers to breach。
翻成人话：MCP 服务器会为每个外部系统保存凭据，所以它对攻击者来说是一个很有价值的仓库。
这些凭据可能是 OAuth token，可能是 API key，也可能是数据库密码。销售助手接 CRM，行政助手接日历，知识库助手接网盘，数据分析 Agent 接数仓。产品经理看到的是工具越接越多，攻击者看到的是入口集中存放。
源材料称，全球有数百万 AI agents 和工具可能受到影响，另有数百万暴露 ASGI 的服务器可能相关。这里的“可能”不能省。
这不是说几百万个 Agent 已经被攻破，也不是说所有使用 FastAPI 的服务都能被直接利用。材料里没有给出漏洞编号、具体披露日期、受影响版本、补丁版本、利用条件，也没有真实攻击案例。把它写成“全网沦陷”，只是吓人。
真正麻烦的是，很多团队不知道自己的 Agent 后端到底存了什么。
开发环境里一个 .env 文件，生产环境里一堆环境变量，Kubernetes Secret 里塞满 token，MCP server 对内网系统一路可达。模型有没有幻觉当然要管，但服务器如果被拿下，模型还没开口，凭据可能已经被复制走了。
先别写制度，先把服务器翻一遍
国内做企业 Agent 的团队，技术栈并不特殊。
FastAPI、Uvicorn、Starlette、LangChain、MCP server、向量数据库，再接企业微信、钉钉、飞书、OA、CRM。金融、政务、医疗、教育的私有化项目也差不多，只是部署位置不同：客户机房、专有云，或者某个“内网环境”。
内网不是免死金牌。
有些项目只给内部员工用，管理后台却没有强认证。MCP server 不暴露公网，但能直连核心数据库。token 权限开得很大，因为“先跑通再说”。依赖版本没有锁，镜像每次构建都拉最新包。跑通时很快，排查时像考古。
这类团队现在最该查的不是十页安全制度，而是几件很具体的事：
- 项目有没有完整依赖清单。
- Starlette、FastAPI、Uvicorn 分别是什么版本。
- 版本有没有锁定，还是每次构建都随机变化。
- 有没有用 pip-audit、Safety、Snyk、GitHub Dependabot 这类工具扫依赖漏洞。
- MCP server 有没有直接保存邮箱、日历、CRM、数据库和云服务的 token。
- token 是不是最小权限。
- token 能不能按用户、按系统单独吊销。
- Agent 服务和 MCP server 是否暴露公网。
- 前面有没有鉴权、WAF、访问日志和告警。
还有一个更现实的问题：补丁谁来打。
很多创业团队有模型负责人、应用负责人、交付负责人，但没人真正负责依赖升级。客户问大模型效果，销售能答；客户问 Starlette 用的哪个版本，现场没人接话。
开源不是问题。拿开源组件拼出一个能动的 Agent，然后没人管更新，才是问题。
企业管理员在后台给 AI 助手授权读取邮箱、日历和知识库时，页面上只看见一个按钮。那台保存权限的 MCP server，今天用了哪个版本的 Starlette，谁负责更新，token 是否只有必要权限，出事后能不能一键吊销——这些问题不该等到漏洞通报出来才问。