2023年11月,当OpenAI董事会以“不够坦诚”为由解雇CEO萨姆·奥尔特曼时,整个硅谷都以为这又是一场教科书式的权力游戏。然而,这场持续五天的“宫斗大戏”以奥尔特曼的回归告终,却留下了一个远比戏剧本身更深刻的问题:那个曾被预言“即使被空投到食人岛也能成为岛主”的天才,究竟遭遇了怎样的考验?
保罗·格雷厄姆的比喻在今天读来格外意味深长。食人岛象征着极端恶劣的环境——资源匮乏、规则缺失、危机四伏。而奥尔特曼的前半生,确实像开了挂的冒险游戏:8岁学会编程,20岁从斯坦福辍学创业,29岁成为硅谷最知名孵化器YC的掌门人,35岁缔造出估值近千亿美元的OpenAI。他的人生轨迹,仿佛就是格雷厄姆预言的完美注脚。
但真正的考验,往往不是来自外部环境的恶劣,而是来自成功本身。当奥尔特曼站在AI革命的浪尖,他面临的挑战已经不再是“如何在食人岛生存”,而是“如何驾驭一艘正在改变世界的巨轮”。这艘巨轮的名字,叫通用人工智能(AGI)。
**第一重考验:理想与商业的撕裂**
OpenAI的创立初衷充满了理想主义色彩——确保AGI造福全人类。为此,它采用了非营利架构,承诺不以盈利为目的。但现实很快给了这个理想一记重拳:训练大模型的算力成本高得惊人,仅仅GPT-3的训练费用就超过1200万美元。没有商业输血,理想只能是无源之水。
奥尔特曼的解决方案是创立“有限盈利”子公司,引入微软的百亿美元投资。这个精妙的商业设计在2023年迎来了爆发:ChatGPT成为史上增长最快的应用,OpenAI年化收入突破16亿美元。但讽刺的是,正是这种成功引发了内部危机。非营利董事们开始担忧:当商业利益与安全准则发生冲突时,奥尔特曼会站在哪一边?
这场冲突在2023年11月达到顶点。董事会以“沟通不够坦诚”为由解雇奥尔特曼,但明眼人都知道,真正的原因是理念分歧:非营利派希望放慢商业化步伐,优先确保AI安全;而奥尔特曼则坚信,只有通过商业化才能获得持续研发的资金,最终实现AGI的宏伟目标。
**第二重考验:速度与安全的博弈**
如果说商业与理想的冲突是显性的,那么速度与安全的博弈则更为隐蔽,也更致命。奥尔特曼曾公开表示:“AI的潜在好处远远大于风险,但我们必须谨慎前行。”然而,他的行动却常常与此相悖。
2023年3月,OpenAI发布了GPT-4,其能力之强让整个科技界为之震惊。但仅仅两个月后,公司内部就爆发了关于“AI对齐”问题的激烈争论。所谓“对齐”,就是确保AI的目标与人类价值观一致。当时,有研究人员警告,GPT-4已经展现出某种“说服能力”,可能被用于操纵舆论。
奥尔特曼的选择是:继续加速。他相信,只有通过大规模部署,才能在实践中发现并解决安全问题。这种“在奔跑中调整姿态”的策略,让OpenAI在技术上遥遥领先,但也埋下了巨大的隐患。当欧洲、美国、中国相继出台AI监管法规时,奥尔特曼不得不频繁周旋于各国政要之间,试图在监管与创新之间找到平衡点。
**第三重考验:天才的孤独与傲慢**
奥尔特曼的第三个考验,也是最隐秘的考验,来自他的个人特质。作为硅谷公认的“天才”,他习惯了以绝对理性驱动决策。在YC时,他能用数据和逻辑说服最挑剔的创业者;在OpenAI,他同样依赖这种能力来推动团队。
但AI研发不同于商业孵化。当你的目标是创造比人类更聪明的智能体时,单纯的理性可能成为枷锁。2023年,OpenAI首席科学家伊利亚·苏茨克沃(Ilya Sutskever)曾公开表示:“我们正在创造的东西,可能比所有人类加起来都更聪明。这需要的不仅是逻辑,还有敬畏。”
奥尔特曼的回应是:“敬畏是重要的,但不能因此停下脚步。”这种态度让他在内部赢得了“理性机器”的称号,但也让一些研究人员感到不安。他们担心,奥尔特曼的自信正在变成傲慢,而这种傲慢可能导致灾难性的后果。
**第四重考验:从“岛主”到“造物主”的角色转换**
格雷厄姆的“食人岛”比喻,本质上是在赞美奥尔特曼的生存和领导能力。但AI时代的挑战,已经远远超出了“生存”的范畴。当奥尔特曼试图成为AGI的“造物主”时,他必须回答一个根本性问题:人类是否有权创造比自己更聪明的智能体?
这个问题没有标准答案。奥尔特曼的答案是:AGI的出现不可避免,与其让其他国家或公司抢先,不如让OpenAI来主导。这个逻辑听起来无懈可击,但却忽略了最关键的一点:权力越大,责任越大。当OpenAI掌握着最先进的AI技术时,它实际上已经拥有了影响人类文明进程的能力。
2024年初,OpenAI发布了Sora视频生成模型,其逼真程度让好莱坞特效师都感到恐惧。紧接着,GPT-5的传言甚嚣尘上。每一次技术突破,都在加深奥尔特曼的“造物主”光环,也在加剧外界的担忧:这个人,真的准备好承担如此巨大的责任了吗?
**结语:传奇的终局,还是新篇章的序章?**
萨姆·奥尔特曼的传奇正在经历前所未有的考验。这些考验不是来自外部的竞争或监管,而是来自成功本身带来的复杂困境。他必须同时扮演多个角色:商业领袖、技术先知、安全卫士、政治游说者。每个角色都有不同的诉求,而任何一方的失衡都可能导致整个体系的崩塌。
格雷厄姆的预言或许依然成立——奥尔特曼确实能在食人岛上成为岛主。但今天,他面对的已经不是食人岛,而是一个正在被AI重塑的世界。在这个世界里,他不再只是“幸存者”,而是“创造者”。创造者的考验,远比幸存者更加残酷。
我们或许无法预知奥尔特曼的最终结局。但有一点是确定的:他的故事,将成为人类探索AI时代的经典样本。而你我,都是这场伟大实验的见证者。
**你认为,奥尔特曼能通过这场考验吗?欢迎在评论区分享你的观点。**
CVSS 9.9分!GitLab AI网关爆出致命漏洞,你的代码仓库可能正在”裸奔”
一个评分高达9.9的漏洞,足以让全球运维和安全团队彻夜难眠。这一次,轮到了GitLab。
2026年,当AI能力已经成为DevOps工具链的标配,GitLab的AI网关却被曝出CVE-2026-90970这一严重缺陷。CVSS评分9.9,距离满分仅差0.1——在安全领域,这意味着”接近理论极限的严重性”。攻击者无需复杂条件,即可通过AI网关这一看似”智能”的入口,撬开整个代码仓库的大门。
问题的本质,远比一个补丁复杂得多。
**AI网关:DevOps的”新边疆”,也是”新软肋”**
GitLab AI网关是什么?简而言之,它是GitLab将大模型能力嵌入研发流程的”神经中枢”。代码补全、智能审查、自动生成提交信息、漏洞建议修复——这些让开发者拍手叫好的功能,都依赖AI网关在后台调度模型、处理请求、返回结果。
但问题恰恰出在这里。为了完成”智能”任务,AI网关必须拥有极高的权限:读取代码内容、访问项目元数据、调用内部API、甚至代表用户执行操作。它就像一把万能钥匙,被挂在了GitLab这栋大楼最显眼的门把手上。
CVE-2026-90970的致命之处在于:攻击者可以通过精心构造的请求,绕过AI网关的权限校验机制,直接以高权限身份读取私有仓库代码、窃取CI/CD密钥、甚至注入恶意代码到流水线中。CVSS 9.9的评分,意味着利用门槛极低、影响范围极广、后果极其严重。
**为什么AI组件的漏洞总是”特别致命”?**
这不是GitLab第一次因AI组件登上安全头条,也不会是最后一次。从2024年到2026年,全球主流DevOps平台——GitHub、GitLab、Jenkins、Azure DevOps——无一例外地在AI集成模块上栽过跟头。
根本原因有三。
第一,AI组件的”权限膨胀”是结构性的。传统API网关的权限边界清晰,一个查询接口只能查数据,一个写入接口只能写数据。但AI网关不同:它需要”理解”上下文,就必须访问上下文;它需要”生成”建议,就必须拥有建议所涉及的资源权限。这种”为了智能而让渡权限”的设计范式,天然埋下了越权隐患。
第二,AI组件的输入面极其宽广。自然语言、代码片段、文件路径、模型参数——任何一个输入点都可能成为注入攻击的入口。攻击者不需要找到传统的SQL注入或缓冲区溢出,只需要在提示词中嵌入恶意指令,就可能让AI网关”心甘情愿”地交出敏感数据。
第三,安全测试跟不上AI迭代的速度。传统安全工具擅长扫描已知模式的漏洞,但AI网关的行为逻辑是概率性的、上下文相关的。同一个请求,在不同项目、不同模型版本、不同上下文下,可能产生完全不同的结果。这让自动化安全测试几乎束手无策。
**从CVE-2026-90970看DevOps安全的范式转移**
这个漏洞的真正价值,不在于它本身有多严重,而在于它揭示了一个不可逆转的趋势:DevOps平台的安全边界,正在从”代码”转移到”AI”。
过去,我们保护代码仓库,核心是管好Git协议、SSH密钥、访问令牌。后来,我们保护CI/CD,核心是管好流水线权限、环境变量、制品仓库。现在,我们保护AI网关,核心是什么?是提示词过滤?是模型输出审查?是权限最小化?还是行为审计?
答案可能是:以上全部,但远远不够。
真正需要的,是一种”零信任AI”的架构思维。具体而言:
其一,AI网关必须运行在独立的、隔离的权限域中。它不应该直接持有用户的长期凭证,而应该通过短期令牌、动态授权的方式,在每次请求时重新校验权限。
其二,所有AI网关的输入输出必须经过严格的内容安全策略。不是简单的关键词过滤,而是基于语义的意图识别——判断这个请求是否在试图诱导AI执行越权操作。
其三,AI网关的行为必须可审计、可回滚。每一次代码读取、每一次API调用、每一次模型推理,都要留下不可篡改的日志。一旦发现异常,能够快速定位、快速阻断、快速恢复。
其四,也是最根本的:不要把AI网关当作”更聪明的API”,而要把它当作”拥有超级权限的新用户”。对待新用户,我们从来不会一上来就给root权限。
**修复之外:每个团队都应该问自己的三个问题**
GitLab已经发布了补丁,升级到最新版本即可修复CVE-2026-90970。但补丁只能解决这一个漏洞,解决不了系统性的风险。
每一个使用AI增强型DevOps平台的团队,都应该立即问自己三个问题:
第一,我们的AI网关拥有哪些权限?这些权限是否经过了严格的必要性审查?是否存在”为了省事”而授予的过度权限?
第二,如果AI网关被攻破,攻击者能接触到什么?是只有公开代码,还是包括私有仓库、生产密钥、客户数据?最坏情况下的影响范围有多大?
第三,我们有没有能力检测和响应AI网关的异常行为?当AI网关在凌晨三点突然大量读取私有仓库时,有没有告警?有没有阻断?有没有溯源?
这三个问题,比任何补丁都更重要。
**结语:AI越智能,安全越不能”偷懒”**
CVE-2026-90970是一个警钟,但它不是第一个,也不会是最后一个。当我们将越来越多的权限交给AI,我们就必须用更严苛的标准去审视AI的每一个接口、每一次调用、每一行代码。
安全从来不是AI的对立面,而是AI能够被信任的前提。一个CVSS 9.9的漏洞,足以让整个行业重新思考:我们到底应该给AI多少信任,以及,我们准备好为这份信任付出多少安全成本了吗?
你的团队,是否已经检查了GitLab AI网关的权限配置?欢迎在评论区分享你的安全实践或困惑。如果觉得这篇文章有价值,请点个”在看”,让更多运维和安全同行看到。





