880万人的隐私，败给一个弱密码

一个『123456』，让丹麦约880万个公民身份编号暴露在黑客面前；与此同时，越来越多公司正把 Text-to-SQL Agent 接进生产数据仓库，而它们手里的账号权限，往往比那位设弱密码的管理员还大。两件事看似无关，其实是同一道题：数据安全的溃败，几乎从不发生在炫技的攻防前沿，而是发生在最不起眼的账号与权限治理上。AI 越热，这道旧题越致命。

🔑 一个『123456』，放倒了全国人口底座

安全事件里最讽刺的部分，往往便宜得像个笑话。

黑客利用『123456』等弱密码，入侵了 丹麦 支付服务公司 Pays ApS 的账户，进而导致丹麦中央民事登记数据库约 880 万个 CPR 编号泄露。奥胡斯大学 教授的批评一针见血：这等同于为黑客敞开大门。

几个细节值得放大。丹麦人口约 590 万，泄露的编号却有 880 万个——从数量推算，这个库覆盖的远不止现存居民，而是含历史编号在内的几乎全部记录。CPR 编号类似我们的身份证号，伴随终身、极难更换，它的泄露不是一次性的『数据打湿』，而是数十年防不住的长尾风险：身份盗用、精准诈骗、信用冒用，都会在未来的某个时间点反复兑付。

再看攻击本身：没有 0day，没有供应链投毒，没有什么花哨的 APT。攻击者拿到的第一张门票，就是一个没改过的默认密码。据安全圈私下流传的一句话：『攻防演练比的是谁更聪明，真实泄露比的是谁更懒。』

这起事件真正的产业含义是：在凭据治理这一层，投入产出比高到离谱，但恰恰是这一层，最容易被『先跑起来再说』的工程文化牺牲掉。管理员账号、第三方接入账号、长期不轮换的服务账号——它们是整个数据底座上最便宜也最危险的组件。

🤖 Text-to-SQL Agent：一个手握高权限的『实习生』

如果你觉得弱密码只是别人的疏忽，那再看看另一条正在蔓延的战线。

一位在北美做数据平台的工程师复盘：过去三个月，他一直盯着一个 LLM 试图『热心地』把 users 表和 transaction_logs 表 join 起来——那是一次足以泄露 HIPAA 合规数据的查询，最后没出事，纯粹是因为数据库用户权限设得足够严，『严得像个金库』。他还见过团队上线的 Agent，被问一句『我们有多少用户』，就对整个元数据目录执行 SELECT ，差点把数仓直接压垮。

他的结论很硬：当前 AI 热潮里最危险的迷思，就是以为一个基于 RAG 的 Text-to-SQL Agent 『聪明到』能分清只读报表 schema 和客户敏感数据表。它分不清，也不在乎。

两种泄露路径的对比，其实高度同构：

业内私下有句话传得很广：『把 Agent 当新来的实习生没问题，问题是这个实习生默认有 root。』当业务方喊着『让分析师直接用自然语言查数』时，平台工程师真正要回答的问题不是『模型够不够聪明』，而是『它拿的是什么账号』。

🧱 提示词不是护栏，权限才是

Prompt 是建议，权限才是法律。

市面上大多数 Text-to-SQL 教程，都在讲『怎么把 SQL 写对』：LangChain Agent、schema 向量化、温度参数怎么调。这位工程师的判断是：这搞错了层。常见的失败模式，是把 LLM 当成一个被授权的用户——如果你的 Agent 用一个宽权限账号连着 Snowflake 或 Databricks 集群，那么一次模型幻觉出来的 JOIN，就足以跨越合规边界，剩下的只看运气。

换句话说，系统提示词里写一句『不要查询敏感表』，本质上是把安全策略寄托在概率采样上。而数据库的用户权限、行列级安全、审计日志，是把安全策略固化在架构里。前者是请求，后者是强制。

把当前主流的防护手段放到一张图上看，投入与收益的分布相当清晰：

左上角那几项——MFA、最小权限、审计——都不是什么新技术，成本不高，收益极高。右下角靠提示词硬撑的做法，则是典型的『看着做了安全，实际什么也没拦住』。AI 时代的数据安全，第一性原理没变：能力越强的访问者，越要被更硬的边界约束。

⚖️ 第三方接口，是数据底座的暗门

丹麦这起泄露还有一个容易被略过的细节：失守的不是登记库本身，而是一家第三方公司 Pays ApS 的账户。

也就是说，攻击链其实是这样的：

核心数据库自己的门可能锁得很好，但它授权出去的每一个第三方接口，都是一把复制的钥匙。Pays ApS 的钥匙为什么是『123456』？为什么一个支付服务公司能触达全国人口登记数据？这两个问题比『密码太简单』更值得所有数据平台负责人失眠。

在数据要素流通的大趋势下，这件事只会更普遍：数据要流通，就意味着更多外部系统、更多集成商、更多 Agent 拿到凭据。每一条对外接口，都等于一组凭据加一段权限加一份审计责任。接口越多，暗门越多——除非账号治理的成熟度跟上接口增长的速度。

现实中的普遍做法是：采购前填一份供应商安全问卷，签一份协议，然后账号一开就是一年。据多位做合规审计的人士反馈，大量泄露复盘到最后，都会落到同一类 conclusion：某个第三方账号权限过大、长期未用、无人复审。安全的最后一公里，拼的不是论文里的高级威胁模型，而是这些枯燥的账号生命周期管理。

💡 把安全做进架构：一份务实清单

安全团队最贵的产出不是报告，是默认配置。

把丹麦的教训和 Agent 时代的风险合在一起，落到工程上，其实就是一张不长的清单。每个条目都不新，但每一条都在真实事故里被反复验证过：

给正在接 Text-to-SQL Agent 的团队再强调三句：

第一，给 Agent 单独建账号。只读、限 schema、限表、脱敏视图先行，绝不复用任何人的个人凭据。模型怎么写 SQL 不可控，但账号能查什么完全可控。

第二，给查询上配额和熔断。防止一次 SELECT 扫穿元数据目录、压垮数仓——这是已经真实发生过的故障，不是假想。

第三，把审计做在 SQL 层而不是对话层。日志里要留下的是被执行的语句、命中的表和返回的行数，而不是一段无法归责的自然语言请求。

这套东西没有一件事需要大模型突破，全是十几年前的数据库基本功。区别只在于：以前忘了做，损失可能是几张报表；现在忘了做，损失可能是 880 万条国民身份编号，或者一纸 HIPAA 罚单。

880 万个 CPR 编号，和一次差点发生的幻觉 JOIN，其实是同一场事故的两次预演。数据基础设施越向 AI 开放，攻防的主战场就越会从『能不能攻进来』转移到『你发出去多少把钥匙』。数据要素流通越繁荣，账号与权限治理这份枯燥的工程纪律，就越值钱。下一轮安全升级的主角，不会是更聪明的模型，而是更死的默认配置——这大概是对『AI 改变一切』最冷峻的一种注脚。