好荐的鱼爸我做了快十年开发和运维，最近两年又把大部分精力投到AI应用上，结果发现一个让我特别头疼的现象：很多团队花大价钱买防火墙、上WAF、做渗透测试，却把最要命的API密钥、数据库密码、云服务凭证当成明文贴在代码里。尤其是AI应用，简直就是凭证泄漏的重灾区。标题里说“99%”可能有点夸张，但我真的在不少客户的仓库里见过OpenAI的Key、向量数据库的连接串、对象存储的Secret直接躺在Git提交历史里，权限还开到最大。这篇文章我就想认认真真聊清楚一件事：AI应用里的凭证管理到底哪里出了问题、会怎么裸奔、又该怎么系统性地收口。
这个话题适合谁看呢？正在用LangChain、LlamaIndex、Coze这类框架做AI应用的人，公司在给大模型应用做安全评审的技术负责人，以及那些把“快速上线Demo”当成第一优先级、还没考虑过密钥泄漏后果的独立开发者。涉及的也不只是“把Key放到环境变量里”这种入门动作，还包括怎么扫描存量泄漏、怎么清理Git历史、怎么用密钥管理服务做动态取用，以及怎么把检查机制固化到CI流程里。看完之后，你至少能给自己手上正在跑的项目做一次全面体检。
1. 先聊清楚：AI应用里的“凭证裸奔”到底是怎么发生的
1.1 一个被讲烂但永远有人踩的词：凭证管理不当
凭证（Credential）不光是密码，更泛指一切能让程序“证明自己有权访问某资源”的凭据：API Key、Access Token、服务账号的JSON密钥、数据库连接字符串里带的用户名密码、云平台的临时安全凭证，甚至某些内部系统的签名密钥。凭证管理不当，最常见的形式就是把它们当成普通配置，硬编码在源码或配置文件里，完事还随手把仓库设成公开。
放到AI应用的语境里，这个问题的放大效应特别明显。传统Web应用可能只需要一把数据库密码，顶多加一个支付宝/微信支付密钥。但一个典型的AI应用，至少要具备以下几类凭证：调用大模型服务的API Key（可能是OpenAI、Claude、国产模型多路供应商），向量数据库或对象存储的连接凭证，私有化知识库或业务系统的访问令牌，还有为了采集训练数据、调用第三方数据服务而申请的各类Token。凭证数量一多，管不过来的团队就会选择图省事，全部塞进一份.env文件、一份application.yml，或者更离谱，直接写成示例代码里的字符串常量。
对于AI应用而言，凭证泄漏的后果往往不只是数据泄露这么简单。AI应用通常会串联很多自动化动作，比如调用外部工具、读写文件、发邮件、付钱下单之类的Agent能力。一旦密钥被拿走，攻击者就相当于获得了这套自动化流程的“操作权”，可以直接指挥你的AI替你花钱、替你发消息、替你删数据。这不是普通Web漏洞可以比拟的。
1.2 为什么偏偏是AI项目最容易“裸奔”
我复盘过不少AI项目，发现它们普遍存在三个特征：迭代速度极快、复制粘贴比例极高、安全review极度缺失。
迭代速度快，意味着开发者会优先把功能跑通，不会考虑“这个Key能不能写死在代码里”这种延迟满足的事。某AI创业团队为了快速验证一个RAG问答效果，直接在Notebook里写完向量化脚本，顺手把OpenAI API Key写死在里面，之后Notebook被分享给外部合作方，Key就这么漏了。我见过不止一次类似的场景。
复制粘贴比例高，是AI开发者的日常。很多人会直接去GitHub上搜项目模板或示例代码，拿到手发现代码里居然带着作者的API Key，就以为这是“可用的默认配置”，连替换都不做。有些Key甚至还能用，因为原作者使用了免费额度的账号，根本不设防。这类泄漏属于“传染式泄漏”，你抄我、我抄他，一条真实的Key可能潜伏在几十个复刻仓库里。
至于安全review缺失，更是常态。传统开发团队好歹有Code Review流程，会有人盯着“你的密码别写到代码里”这件事。但AI项目的Owner往往就是两三个全栈工程师，甚至是一个人从模型选型干到前端部署，整个开发过程没有第二双眼睛盯着凭证。大家默认“能跑就行”，而“能跑”和“安全”在很多AI原型项目里天然冲突。
1.3 先搞懂攻击者拿到凭证后会干什么
很多开发者觉得“就算Key泄漏了，最多被人调用几次，扣点费而已”。我建议你千万别这么想。让我按攻击者的视角给你摆一摆拿到凭证后的操作路径，你大概就知道这事的严重程度了。
第一类路径是直接用你的资源：用你的云账号密钥启动GPU实例去挖矿、用你的对象存储凭证把桶里的训练数据全拖走、用你的模型服务API Key去跑批量任务，刷爆你的账单。第二类路径是横向移动：AI应用很少只有一个凭证，它往往同时持有数据库密码和模型服务密钥。攻击者拿到其中一个，就会以此为跳板去翻配置中心、环境变量、K8s的Secret，尝试拿更多权限。第三类路径最隐蔽也最致命：如果是Agent类应用，凭证往往绑定了“工具调用”权限，攻击者可以用你的身份指挥Agent调用邮件、支付、数据库写入等工具，这个叫凭证接管，本质上比数据库被拖库还要难防范，因为每一次调用看起来都是合法行为。
所以你在评估AI应用的凭证风险时，不要只想着“少一点费用损失”，要想一想“这套凭证能让别人替我做多少事”。想清楚这一点，你就知道为什么凭证管理不能靠自觉，必须靠机制。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 泄漏面盘点：AI应用里的凭证是从哪些渠道漏出去的
我替团队做安全巡检时，一般会按六个泄漏管道逐项排查。每个管道对应不同的泄漏场景，修复手段也完全不一样，所以先把路数分清楚。
2.1 硬编码到代码仓库：最低级但最常见
这是老生常谈，但AI项目里仍然大量存在。形式包括：Python脚本里直接写openai_api_key = "sk-xxx"，Jupyter Notebook里写死云数据库连接串，前端代码里嵌了后端接口的认证Token，示例配置文件里留着真实密钥没替换。
我见过最典型的一个案例是某团队用Streamlit快速搭了一个AI对话Demo，为了方便，把OpenAI Key写在一个叫config.py的文件里，然后整个目录推到了GitHub公开仓库。Key直到三个月后收到账单才发现被盗刷。事后检查时发现，那条Key在泄漏后的24小时内就被爬虫捕获并开始调用，但因为用量不大，账单上没有立刻体现异常。
为什么AI开发者特别喜欢把Key硬编码？除了“图省事”，还有一个心理因素是“这不是生产环境，只是一个demo”。但GitHub的代码爬虫不会区分demo和生产，它扫到Key就抓走，然后立刻在暗网上批量验证。这个坑我强调过无数次：凡是被推到远端仓库的代码，就要默认它可能被公开。
2.2 日志与监控链路：AI编排工具的信息“顺风车”
第二个泄漏点特别容易被AI原生产品忽视：大模型调用链路上的日志。很多应用会在调试阶段打印完整的请求体、响应体和中间步骤。问题在于，现在AI应用经常用ReAct模式或Agent模式，模型在推理过程中可能会把某一步获取的凭证信息当作普通文本输出到日志里。
举个例子，一个Agent被赋予了读取数据库Schema的能力。它在执行任务时，内部调用的SQL连接串可能带用户密码。这部分信息一旦被记录进LangSmith或Langfuse这类追踪工具，甚至只是print到控制台，凭证就进了日志系统。很多团队的日志是明文存储且全员可查的，一旦内部账号被攻破，日志就成了凭证金矿。
更麻烦的是，现代AI Agent的思维链输出（Chain of Thought）往往包含很多中间变量。如果程序在设计Prompt时不小心让模型“看到”了连接凭证或者Token，模型输出复盘时可能将其复述出来。这种泄漏在普通应用里根本不存在，却是AI应用独有的一种“非典型泄漏面”。
2.3 AI编程助手与训练语料：新时代的泄漏放大器
现在很多开发者在用AI编程助手写代码。它确实能提升效率，但也带来了一个非常危险的问题：如果编辑器里的代码包含真实密钥，这些代码片段可能会被IDE的补全插件自动发送到模型