Bonfy 对“Shady AI”的警告揭示了安全领域下一项治理难题

Bonfy CEO Gidi Cohen 指出，获批的企业 AI 系统内部存在令人担忧的治理缺口。拥有合法访问权限，已不再意味着结果必然恰当。

Cohen 将这一问题称为“shady AI”。该术语指的是：获批 AI 以获得授权的数据，做出违背业务意图、政策或客户预期的使用。与 shadow AI 不同，系统本身并未对安全团队隐藏。

这一警告通过安全领域报道和 Google News 触达了更广泛的受众。但真正重要的并非又一个吸睛的网络安全标签，而是一项长期假设正在失效：获批技术在有效权限下运行，就等于受治理的技术。

在软件遵循可预测指令的时代，这一假设更为成立。员工打开一条记录、更改一个字段，或导出一份文档。安全团队可以将该操作关联到具体人员、权限、应用程序和时间戳。

AI 改变了这种关系。系统可以检索数千条获得授权的记录，推断它们之间的关联，并生成无人直接要求过的结果。每一次单独访问都可能被允许，但汇总后的结果却可能越过边界。

这种冲突让企业安全团队陷入两个都不令人满意的选择：要么通过严格控制放缓 AI 采用，要么在不了解公司数据所有下游用途的情况下允许快速部署。

两种选择都无法解决核心问题。组织需要能够评估数据为何被使用的控制措施，而不仅仅是评估应用程序能否访问数据。

Shady AI 将风险带入获批系统内部

Shady AI 无需流氓员工、未知应用程序或被盗凭证，就能将获批工作流变成治理问题。

Cohen 在讨论 AI 如何区分“相关性”和“恰当性”时提出了这一术语。他的论点聚焦于那些在获批平台和既定工作流内运行的系统。

用户可能拥有正确的角色。应用程序可能已通过安全审查。底层记录也都可能可通过合法权限获取。

但最终行动仍可能与政策相冲突。AI 助手可能将客户沟通记录、合同细节和支持历史结合起来，生成未经授权的风险画像。每个来源看似都相关，但它们的组合使用改变了数据用途。

Cohen 的这一区分很重要，因为安全计划通常将审批视为关键控制边界。一旦供应商、应用程序、集成和身份通过审查，监控往往就集中于未经授权的访问或可疑行为。

Bonfy 对该概念的阐释称，AI 系统可以检索获准的信息，却依然生成违背客户预期的结果。该公司在其对 shady AI 概念的总结中，将其描述为获批 AI 超出预期边界的行为。

这仍是一种由供应商支持的表述，而非公认的监管类别。尚无独立机构将“shady AI”确立为标准术语或可量化的事件类别。

尽管如此，其所描述的底层行为足够真实，值得审视。生成式系统可以跨存储库整合数据、推断敏感属性，并通过连接的工具发起行动。这些能力扩展了“获授权访问”的含义。

设想一个连接到电子邮件、文档、日历和客户记录的工作场所助手。某位经理要求它识别本季度最可能流失的客户。

该助手可能从账单争议中推断财务压力，从私密支持对话中提取不满情绪，还可能将这些发现与合同续约日期和员工评论关联起来。

每个来源都可能处于该经理的技术权限范围内。但组织可能从未批准过这种组合画像用途，也可能没有记录哪些因素影响了该建议。

这不同于常规的 shadow AI。Shadow AI 通常指员工使用未经批准的模型、个人聊天机器人账户、浏览器扩展或未经认可的代理。

在这些情况下，安全问题首先表现为可见性。团队必须发现哪些工具正在使用，确定哪些数据已输入其中，并决定是阻止还是治理其使用。

The Hacker News 曾描述过获批软件内部的另一种风险形式。AI 功能可能会在供应商最初审查完成后，出现在现有帮助台、文档系统和客户平台中。

其对 shadow AI 风险的概述指出，过去完成的软件审查并不能治理后来启用的每一项 AI 功能。这一观察缩小了 shadow AI 与 Cohen 新框架之间的距离。

但这两个概念描述的仍是不同的控制失效。

Shadow AI 关注的是组织是否知道某项工具或功能的存在。Shady AI 关注的是，获批系统的行为是否仍然适合特定用户、用途和关系。

Google News 可能会将两类报道归入广泛的 AI 安全主题。企业防御者却不能将它们视为同一个运营问题。

发现工具可以识别未知聊天机器人，却无法自动判断获批助手是否应使用敏感客户对话来影响销售决策。

这一决定需要语境，也需要软件能够在检索、生成或行动前评估的政策。

为什么身份与访问控制已不再足够

身份控制回答的是谁可以访问数据，而 shady AI 则迫使组织决定哪些关系和用途能让这种访问变得恰当。

传统访问控制通过角色、群组、资源所有权和策略规则授予权限。例如，客户支持经理可能可以阅读某个区域的所有工单；财务分析师可能可以查看某业务部门的每一张发票。

这些控制仍然不可或缺。它们能阻止许多未经授权的用户和应用程序接触敏感系统，也会留下供调查人员在事件发生后检查的记录。

但广泛权限之所以存在，往往是因为人们需要灵活性。一名资深员工可能可以访问数千份文档，却只会在每项任务中使用其中一小部分。

人类判断提供了非正式的第二层防护。员工通常明白，能够访问客户记录，并不代表可以任意使用其中内容。

不能假定 AI 具备同样的理解。模型会根据可用语境、指令和学习到的模式优化回应。它并不天然了解组织未写明的边界。

这带来了用途问题。为客户支持收集的数据，可能在技术上可供销售助手使用，但这并不必然授权其利用支持电话中的情绪化语言来调整商业对待方式。

这也带来了关系问题。临床医生、律师、人力资源经理和系统管理员，可能在不同的职业职责下访问同一条记录。

传统权限可以表示资源和用户，却很少能捕捉 AI 所作每项推断背后的完整关系。

代理进一步提高了风险。AI 代理是一种能够通过连接工具选择并执行行动的软件，而不只是生成文本。

获批代理可能读取电子邮件、查询数据库、更新客户记录并发送消息。它的每一步权限都可能有效。

但整个操作序列仍可能不安全。隐藏在电子邮件中的不可信指令可能改变代理的行为；宽泛目标也可能鼓励过度检索或不必要行动。

OWASP 将提示词注入描述为：通过直接输入或模型之后处理的内容来操纵模型的指令。根据其提示词注入指南，影响在很大程度上取决于系统可用的工具和权限。

这一威胁将安全漏洞与治理失效联系起来。恶意指令可能导致不恰当行动，但模糊的政策即使在没有攻击者的情况下，也可能产生类似结果。

OWASP 还单独警告了过度代理权限问题，即 AI 系统拥有超出其所需的功能、权限或自主性。其示例包括：恶意电子邮件指示代理搜索收件箱并转发敏感信息。

最小权限仍是答案的一部分。助手无法滥用其无法访问的数据或功能。

但仅仅缩减权限也有局限。组织部署 AI 往往正是因为它能够连接跨系统信息。移除所有跨系统能力，可能会消除部署 AI 所依据的业务价值。

更困难的任务是让授权更具针对性。决策应考虑请求身份、业务目的、数据关系、行动、目的地以及当前语境。

例如，客户服务助手可以为已分配的工单总结投诉内容；但同一助手不应将该投诉中的健康信息添加到营销档案中。

两项行动涉及相同的身份和底层数据，区别在于用途、受众和预期使用方式。

这正是 shady AI 从根本上属于治理挑战的原因。安全团队可以定义技术边界，但法务、隐私、合规、产品和业务负责人必须共同界定恰当行为。

这种共同责任并不轻松。安全组织更倾向于可执行的规则，而政策团队常常制定依赖人类解释的原则。

AI 系统暴露了这两种方法之间的缺口。除非组织将“恰当”一词转化为可测试的控制措施，否则一项规定客户数据必须被“恰当”使用的政策几乎无法提供有效保护。

Google News 正在呈现从访问权限到意图的转变

更广泛的安全讨论正从发现 AI 工具，转向治理获批模型和代理如何利用合法访问权限。

Shady AI 出现在 Google News 中，反映了企业安全报道更广泛的变化。第一波关注聚焦于员工将敏感数据粘贴到公共聊天机器人中。

这种风险并未消失。个人账户、未经批准的应用程序和嵌入式 AI 功能仍会造成可见性和数据泄露问题。

但获批的企业部署如今提出了一个更复杂的问题。组织之所以将助手和代理连接到有价值的系统，是因为孤立的聊天界面只能带来有限的运营价值。

这些连接创造了语境，也创造了权限。

连接到公司知识库的模型可以定位内部信息；连接到运营软件的代理则可以基于这些信息采取行动。因此，治理必须同时覆盖理解与执行。

IBM 的 2025 年数据泄露研究发现，企业 AI 监督存在明显缺口。其官方发布称，在接受研究的组织中，13% 报告发生过涉及 AI 模型或应用程序的数据泄露。

在这些组织中，97% 缺乏适当的 AI 访问控制。IBM 还表示，63% 的受访组织尚未制定 AI 治理政策，或仍在制定过程中。

这些数据来自厂商赞助的研究，不应被用来界定每家组织的风险。但它们仍说明，AI 安全已不再局限于假设性的模型攻击。

IBM 的泄露调查结果表明，采用速度正在超过治理能力。Shady AI 则揭示了这种失衡在获批系统内部可能产生的一种后果。

现有框架提供了有用的基础。NIST AI 框架围绕治理、映射、衡量和管理风险来组织 AI 风险管理。

NIST 还发布了一份生成式 AI 概要，将该框架调整用于模型特定风险。它强调职责记录、测试、事件处理流程和持续衡量。

这些实践有助于组织超越一次性的审批。它们鼓励团队将已部署的 AI 视为需要持续监督的动态系统。

不过，框架无法为每家公司提供具体的业务规则。银行、医院、软件供应商和大学对适当数据使用的定义会有所不同。

监管又增加了一层要求。欧盟规则会根据 AI 系统的角色与风险分类，对提供商和部署方施加义务。

欧盟委员会表示，通用模型的相关义务已于 2025 年 8 月 2 日开始适用。其中包括文档与透明度要求；被认定具有系统性风险的模型还须履行额外义务。

这些规则主要聚焦于提供商和指定使用场景。它们不会自动解决企业助手在使用获授权内部数据时作出的每一项情境化决策。

一家组织可能满足供应商文档要求，却仍部署了内部用途定义不清的助手。法律合规与运营上的适当性存在重叠，但两者并不相同。

隐私法中也存在同样的区别。用户同意或其他法律依据可以在高层面授权数据处理；但新的推断或合并后的数据集仍可能带来意外后果。

这正是“相关性不等于许可”这一表述的价值所在。一条信息可能改善模型的回答，却未必适合用于该项决策。

搜索引擎和 Google News 往往倾向于奖励简单的分类，例如影子 AI、AI 智能体和数据泄露。Shady AI 并不完全契合其中任何一类。

它横跨访问管理、隐私、模型行为、数据治理和业务流程设计。这种交叉性使其更难明确归属，也更容易被忽视。

因此，承受压力的不只是安全运营中心。首席信息安全官、隐私负责人、法务团队、数据所有者和应用管理者都会承担其中一部分问题。

他们需要对允许行为形成统一且可执行的视图。否则，每个团队都可能认为风险应由其他团队负责。

最困难的部分，是将政策转化为运行时决策

可信的应对措施必须在检索和执行操作期间落实情境控制，而不只是再发布一份可接受使用政策。

许多组织从清单开始进行 AI 治理。一份清单列出获批工具，另一份列出禁止使用的数据，第三份则指定应用负责人和审查日期。

这些清单是必要的，尤其有助于发现影子 AI。但它们无法完全解决这样的问题：一个获批系统从允许使用的资源中得出了不恰当的结果。

Shady AI 需要更接近运行时的控制。运行时是指 AI 接收请求、检索信息、生成输出或调用已连接工具的那一刻。

此时，系统掌握的情境信息多于静态审批流程。它知道用户是谁、请求内容、所选数据、预期目的地以及拟议操作。

治理层可在允许工作流继续前评估这些因素。它可以拒绝访问、移除敏感上下文、要求审批，或限制可执行的操作。

政策必须具体到足以执行。“保护客户信任”是一项重要原则，但软件需要更精确的规则。

例如，一条规则可以禁止助手利用支持对话来决定折扣；另一条规则可以限制在未经授权的福利工作流之外汇总员工医疗信息。

组织还需要数据溯源记录，用于记录 AI 回应从何处获取信息。溯源可以帮助审查人员理解哪些来源影响了回答或行动。

对于许多智能体工作流而言，仅记录最终提示词和回答并不足够。调查人员可能还需要检索到的文档、工具调用、政策评估、模型版本和审批历史。

这些记录支持审计和事件响应，也可以揭示哪些政策规则阻碍了无害工作，或允许了高风险组合。

测试必须反映真实的业务关系。通用模型基准无法判断某条特定客户消息是否应纳入续约建议。

团队应围绕自身的数据、角色、工作流和禁止结果构建场景。测试应同时包含恶意提示词，以及目的模糊的普通请求。

对于高影响操作，人工审批可以降低风险。当审查人员获得相关上下文并能理解警报原因时，它最为有用。

如果审查人员无法看到哪些敏感来源影响了操作，一个标有“批准”的按钮几乎没有作用。审批疲劳也会将正式控制变成机械点击。

因此，组织应将人工审查保留给重要边界。较低风险的工作流可以采用自动限制、抽样和事后监控。

数据最小化是另一项实用控制。即使服务账户可以访问更多信息，助手也应只获得完成当前任务所需的数据。

检索系统可以在内容进入模型上下文前落实这一限制。工具网关同样可以限制智能体能够执行的操作。

对于知识工作者而言，本地上下文可以减少向广泛外部服务进行不必要的数据传输。设计良好的个人知识库可以更清晰地划分个人信息与组织共享信息之间的边界。

然而，仅靠架构并不能保证使用方式恰当。本地处理可以减少暴露，却仍可能产生不公平、侵扰性或未经授权的推断。

这是一个重要的审慎观点。安全厂商可能将情境化执行描述为完整答案，但政策解释仍然困难。

自然语言具有歧义，业务关系会变化。适用于一个部门的规则，可能阻碍另一个团队，或遗漏某种细微的滥用。

误报可能促使员工寻找变通方法。漏报则可能让人对自动化治理层产生不应有的信心。

模型行为也会在更新后发生变化。适用于某个版本的提示词、检索策略或政策测试，在另一个版本中可能表现不同。

组织应将情境控制视为分层计划的一部分。身份管理、最小权限、数据分类、检索过滤、工具限制、评估和人工监督仍然不可或缺。

没有任何单一控制能够证明每个结果都恰当。目标是让违反政策的行为可见、可测试，并更难以机器速度执行。

三个信号将显示 Shady AI 是否会成为真正的安全类别

只有当组织能够衡量 Shady AI、执行有意义的控制措施，并将失败与可问责的负责人关联起来时，它才会真正重要。

第一个信号是，主要安全框架是否会将不恰当的授权使用与普通的未经授权 AI 区分开来。NIST、OWASP 和行业组织已经覆盖了相关问题的一部分。

提示词注入涉及被操控的模型行为。过度自主性涉及危险的自主决策。影子 AI 则涉及未知或未经批准的系统。

这些标签都无法完美描述这样一种情形：获批系统在没有攻击者的情况下作出情境上不可接受的决定。更清晰的分类法将有助于团队一致地报告事件。

关注涉及目的、关系和推断的新框架指引。这类指引将强化 Cohen 的观点：传统访问控制仍存在实质性缺口。

如果现有类别已经能够在没有运营混乱的情况下涵盖这些事件，这一判断就会被削弱。新术语若只是对既有失败重新命名，价值不大。

第二个信号是可衡量运行时控制的出现。供应商会承诺提供情境化治理，但买家应寻找政策仪表板之外的证据。

有用的证据包括可执行的目的限制、决策日志、检索层控制、工具调用审批和可重复测试。产品还应解释一项政策为何允许或拒绝某项操作。

独立评估尤其有价值。供应商不应成为定义风险、衡量产品并宣布控制成功的唯一一方。

买家应在大规模部署前测试真实场景。他们应询问系统是否能阻止不恰当的数据组合，而不只是阻止已知恶意提示词。

他们还应审查失效模式。即使安全逻辑看似可靠，若一项控制过于频繁地阻断合法工作流，也会失去支持。

第三个信号是组织问责。Shady AI 横跨安全、隐私、法务、数据和产品职责。

治理委员会可以协调这些团队，但委员会往往只产出指导意见，缺乏运营层面的责任归属。每个已部署系统仍需要一位可问责的决策者。

该负责人应批准预期用途、可接受的数据关系、禁止结果和升级规则。安全团队随后可以将这些决定转化为技术控制和测试。

事件报告将揭示这一模式是否有效。组织应能区分未知工具、遭入侵的智能体、权限失效和不恰当的授权操作。

这些类别对应不同的补救措施。封禁某个域名可以应对未经批准的聊天机器人，却无法治理已经嵌入业务应用的获批模型。

Google News 的曝光会让更多人关注 shady AI，但关注本身不足以确立这一术语。来自已部署系统的证据必须显示，这是一种现有控制持续遗漏的反复出现的失效模式。

安全负责人应先建立一份范围有限的获批 AI 工作流清单，重点关注涉及敏感数据或重大决策的工作流。对于每个工作流，他们应提出四个问题。

系统可以检索哪些信息？哪些目的可以证明该检索合理？它可以采取哪些操作？谁能够解释并阻止不恰当的结果？

如果这些问题得到的答案含糊不清，治理缺口就已经存在。团队无需等待泄露、监管或新的产品类别出现后才开始审视它。

实际的下一步是选择一个高影响工作流，并从请求到结果进行追踪。记录身份、检索数据、政策、模型决策、工具调用和人工审批。

然后测试在技术上获允许、但在情境上错误的请求。这项练习将表明，“获批”是否真正意味着受到治理，还是仅仅意味着已连接并被信任。