2025 年 8 月，美国网络安全与基础设施安全局（CISA）代理局长 Madhu Gottumukkala 将标记为「仅供官方使用」（For Official Use Only，FOUO）的敏感合同文件上传至公共版 ChatGPT。这一事件引发了对政府机构 AI 使用安全性的深度反思，也暴露出 OAuth 集成中内部威胁路径的防护盲区。
事件核心：特权用户绕过企业控制
CISA 作为美国最重要的网络安全机构，其内部 IT 环境有着严格的安全策略。绝大多数 DHS 员工被禁止访问公共版 ChatGPT，只能使用经过审批的内部 AI 工具，如 DHSChat。这些经过审批的工具「被配置为防止输入其中的查询或文档离开联邦网络」，从架构层面保障了数据不出境。然而，Gottumukkala 作为代理局长，通过特殊权限申请获准使用 ChatGPT，并在此过程中触发了多次内部网络安全警报。
值得玩味的是，这一权限的获取过程本身就存在争议。据 DHS 官员向 Politico 透露，在工作人员看来，Gottumukkala 「迫使 CISA 同意让他使用 ChatGPT，然后他滥用（abused）了它」。这揭示了一个关键问题：当高权限用户主动寻求突破安全边界时，现有控制机制的执行力度往往取决于个人自觉而非技术强制。
FOUO 分类虽然不属于机密信息，但根据 DHS 官方定义，这类信息「用于识别敏感性质的非分类信息」，一旦未经授权披露，「可能对个人隐私或福利产生不利影响」，或妨碍「对国家利益至关重要」的项目运作。更令人担忧的是，由于公共 ChatGPT 服务全球拥有超过 7 亿活跃用户，这些上传的敏感信息理论上可能被用于回答其他用户的提示，形成跨用户的信息泄露风险。
公共版与企业版的本质差异
理解这一事件的安全含义，首先需要厘清公共版 ChatGPT 与企业级产品在数据处理上的根本区别。OpenAI 官方文档明确指出，企业版（ChatGPT Enterprise、Business、Edu）提供了一系列专为组织安全设计的功能：默认情况下不会使用企业客户的数据训练模型、支持 SAML SSO 企业级身份认证、细粒度的基于角色的访问控制（RBAC）、管理员可配置的数据保留策略，以及审计日志接口。
相比之下，公共版 ChatGPT 的数据处理逻辑截然不同。虽然 OpenAI 声称不会默认使用 API 和企业版数据训练模型，但公共版服务的默认保留策略更为宽松，用户对会话数据的控制权限也更为有限。当特权用户将高敏感度文档上传至公共版服务时，这些数据进入的是一个与内部隔离、且受外部用户共享机制影响的系统环境。
OpenAI 的企业隐私承诺中提到，授权员工仅在「解决事件、在用户明确许可下恢复对话、或法律要求时」才会访问对话内容。然而，访问权限的存在本身就意味着潜在的泄露路径。对于处理敏感政府信息的机构而言，这种「理论上不会访问」的安全承诺，无法替代「技术上无法访问」的架构保障。
内部威胁的独特风险向量
此次事件不同于常见的外部攻击或提示注入（Prompt Injection）攻击场景，其核心威胁来自组织内部具有特权的用户主动行为。这引出了 AI 工具安全中一个较少被讨论的维度：内部威胁风险管理。
传统企业安全框架中，内部威胁防护通常聚焦于恶意员工的数据窃取行为。但 AI 工具的特殊性在于，即便是善意的内部用户，也可能因工作便利性考量或对技术风险的认知不足，而将敏感信息输入不受控的外部系统。CISA 代理局长的案例尤为典型 —— 一位本应比大多数人都更理解网络安全重要性的高级官员，却成为了突破安全边界的主体。
从攻击面分析的角度看，内部威胁相比外部攻击具有几个显著特征：攻击者通常拥有合法的系统访问权限、了解组织的敏感数据分布、能够绕过针对外部攻击者设计的外围防御机制，以及其行为模式更难被基于异常检测的安全系统识别。当 AI 工具被纳入组织的数字化工作流后，这些内部威胁特征同样适用于 AI 使用场景。
OAuth 集成的权限边界迷思
事件报道中提到，Gottumukkala 使用 ChatGPT 时「有 DHS 控制措施在位」。这一描述留下了关键的技术空白：这些控制措施究竟是什么？它们能否真正约束特权用户的数据外泄行为？
OAuth 2.0 协议本身提供的是授权框架，而非数据流向控制。当用户通过 OAuth 授权第三方应用访问其数据时，被授权应用获得的是代表用户执行操作的权限，而非访问该用户不应该接触的数据。问题在于，OAuth 并不限制用户主动向第三方服务提供什么信息 —— 它只控制第三方服务能够代表用户做什么。
在实际部署中，企业对 ChatGPT 的 OAuth 集成控制通常体现在：限制哪些用户可以发起 OAuth 授权、定义可访问的 API 范围、设置会话超时和续期策略。然而，这些控制都无法阻止用户本人在与 ChatGPT 的交互中主动输入敏感内容。Gottumukkala 获准使用 ChatGPT 的「DHS 控制措施」，很可能指的是账户层面的访问控制，而非会话内容的数据防泄漏（DLP）机制。
这指向了一个更深层的设计问题：企业 AI 工具的治理框架，往往默认用户会遵守数据分类政策，却缺乏对高权限用户绕过行为的强制约束机制。当组织的二号人物（甚至一号人物）决定将敏感文档上传至外部服务时，现有技术手段往往形同虚设。
工程防护的关键控制点
基于此次事件的分析，企业在部署 AI 工具时应当建立多层次的防护架构。在身份与访问控制层面，组织应实施基于角色的访问控制（RBAC），明确区分哪些用户可以访问企业版 AI 工具、哪些用户可以访问公共版 API、以及哪些用户在任何情况下都不得将工作数据输入外部 AI 系统。高权限用户应当接受更严格的数据处理培训，并在技术层面被纳入更高优先级的监控范围。
数据防泄漏（DLP）集成是第二道关键防线。企业版 AI 平台通常提供与现有 DLP 解决方案的集成接口，能够在用户输入内容中检测敏感模式（如机密标记、内部编号格式、特定的敏感字段关键词）并触发阻止或告警机制。然而，这些功能需要在企业版部署中才能使用，而公共版服务通常不提供此类集成。对于需要处理高敏感度数据的组织，应当在技术上强制使用经过审批的企业版产品，而非依赖用户自觉选择。
审计与监控能力是第三道防线。ChatGPT Enterprise 提供合规 API，允许管理员访问对话审计日志。组织应当建立对 AI 工具使用行为的持续监控机制，包括异常时段的大批量查询、高敏感度关键词的出现频率、以及高级用户的异常使用模式。审计日志本身不能阻止数据泄露，但能够提供事后追溯和威慑效应。
会话隔离与数据保留策略构成第四道防线。OpenAI 企业版允许管理员配置数据保留期限，并承诺对话内容在 30 天内从系统中删除（除非法律要求保留）。组织应当根据自身的数据分类政策，设置与敏感等级相匹配的保留期限，并定期审查保留策略的执行情况。
回到根本：治理框架与技术控制同等重要
CISA 泄密事件的技术教训，最终指向的是一个组织治理层面的问题：AI 工具的安全使用，不能仅依赖技术控制，更需要清晰的策略定义、有效的执行机制，以及对特权用户行为的约束力。
这一事件中，最令人警觉的细节或许是：据报道，CISA 首席信息官 Robert Costello 因频繁在政策问题上与 Gottumukkala 产生分歧，而被试图调离职位。Costello 正是参与调查此次 ChatGPT 不当使用事件的官员之一。这暗示了一个可能的因果链条：当安全控制试图约束高层决策时，执行者本身可能面临职业风险。
对于任何组织而言，AI 安全治理框架的建立，必须在制度层面保障安全团队能够独立于业务压力地执行控制措施。技术控制可以设计得再精细，如果安全团队因政治压力而无法启用或执行这些控制，数据泄露的风险依然存在。
政府在推进 AI 现代化、响应白宫「消除人工智能领导力障碍」行政命令的同时，必须建立与 AI 部署速度相匹配的安全治理能力。公共版 ChatGPT 的便利性，不应成为绕过安全审查的借口；企业级 AI 工具的配置，也不能仅仅依赖于用户自觉。
资料来源
本文核心事实来源：Ars Technica 对 CISA 代理局长 ChatGPT 泄密事件的报道；OpenAI 企业隐私政策文档。