文章总结： AIAgent的安全核心不仅在模型本身，更在于连接模型与现实世界的执行层Harness。通过三大真实案例揭示风险：信任边界失效导致顶级AI厂商被攻破、仅更换Harness即可使攻击成功率从1%飙升至24%、恶意Skill实现供应链持久化感染。建议企业建立Agent动态资产清单、实施最小权限原则、将所有Agent输入视为不可信内容、对完整Agent系统进行红队测试并严格审查默认配置以应对此新兴攻击面。 综合评分： 91 文章分类： AI安全,供应链安全,红队,安全建设,漏洞分析

---

别只盯着LLM越狱了！Harness才是AI Agent的“阿喀琉斯之踵”：换层皮，攻击成功率从1%暴涨到24%

安全牛

2026年8月25日 14:13 北京

在小说阅读器读本章

去阅读

点击蓝字 关注我们

引言：被忽视的新边界

过去两年间,当企业谈论AI Agent安全时,几乎所有的注意力都集中在大模型本身——模型会不会被越狱?能否抵御提示注入?权重是否可信?这些问题固然重要,但来自Black Hat、真实攻防演练以及顶尖AI安全研究机构的最新案例却揭示了一个令人警醒的事实:对于那些已经能够调用工具、访问文件、执行命令并操作业务系统的AI Agent而言,真正的攻击面可能并不在模型,而是在那层包裹着模型、负责连接模型与现实世界的软件层——研究人员称之为Harness。

如果将大模型比作AI Agent的”大脑”,那么Harness就是它的”眼睛、手脚和神经系统”。它决定着模型能看到什么信息、能调用哪些工具、持有什么权限,以及模型输出最终会不会转化为Shell命令、文件写入、API调用,甚至生产数据库中的真实操作。近期多项权威研究给出了一个值得所有安全团队警惕的结论:即使模型本身没有失控,Agent依然可能被攻陷。原因在于,攻击者不一定需要让模型”变坏”,只需利用模型周围的软件架构、信任关系、权限配置或供应链组件即可实现突破。

这意味着,企业正在面对一个全新的AI攻击面——AI Harness。本文将通过三个真实案例,深入剖析这一新兴威胁的本质,并为企业安全团队提供切实可行的防护策略。

一、理解Harness:模型与现实世界之间的”执行层”

从对话到行动的关键转换

AI Agent与传统聊天机器人的根本区别并不仅在于它能进行多轮推理,而在于它能够”做事”。传统大模型的工作流程相对简单:输入文本,模型生成文本。但AI Agent的工作流程已经演变成一个复杂的执行链条:

在这个链条中,真正将”语言”转化为”动作”的关键角色,正是Harness。

Zenity联合创始人兼CTO Michael Bargury给出了一个极为形象的比喻:Harness相当于模型的”手、脚和眼睛”。模型本身只负责Token的输入与输出,而Harness则负责将这些抽象的Token转换为现实世界中的具体操作,例如:

• 执行Shell命令
• 创建或修改文件
• 调用企业API
• 访问数据库
• 操作SaaS应用
• 使用用户凭证
• 调用第三方插件、Skill或MCP Server

SANS Institute首席AI官Rob T. Lee则将模型比作”发动机”,将Harness比作”底盘”。而Lasso Security的高级机器学习工程师Michael Sromin使用了更贴近计算机体系结构的比喻:Harness就像Agent的操作系统——它运行Agent循环,连接模型、用户与工具,并决定整个Agent系统如何持续工作。

Harness的安全职责

Cisco杰出工程师Omar Santos给出了更加完整的定义:AI Harness是包围模型、并使模型真正具有应用价值的那一层系统,其中包括编排逻辑、工具调用机制、Prompt管理、上下文维护、角色定义、评估机制、安全护栏,以及最终将模型输出转化为受控、可重复执行动作的整个工作流。

从安全视角审视,这些定义最终指向同一个核心问题:Harness是AI Agent获得现实世界权限的地方。模型负责”思考”,但Harness负责”执行”。它位于模型推理过程与真实文件系统、API密钥、生产数据库之间,扮演着守门人的角色。因此,Harness实际上承担着一个至关重要的安全职责:它决定模型拥有什么权限,以及这些权限如何被使用。

二、为什么仅关注”模型安全”已经不够

传统模型安全的局限

传统的大模型安全讨论很大程度上围绕模型自身展开,关注的问题包括:模型是否会生成危险内容?能否被提示注入操纵?是否遵循系统Prompt?是否存在越狱风险?是否能识别恶意指令?

然而,Agent时代带来了一个根本性的变化:一个完全遵循规则的模型,也可能运行在一个存在严重漏洞的Harness中。

设想这样的场景:模型完全按照安全策略执行,但Harness错误地信任了Shell通配符;或者Agent在两次处理不可信内容时复用了同一个工作空间;又或者一个低权限阶段产生的结果,被后续高权限阶段直接信任而未重新验证。在这些情况下,无论模型本身的对齐(Alignment)做得多么优秀,都无法解决问题——因为漏洞根本不在模型层。

三大核心风险方向

近期AI安全研究揭示的Harness风险大致可归纳为三个方向:

1. 架构信任边界错误:不同组件之间的信任假设不当,导致权限提升时缺乏必要的重新验证
2. Harness设计差异导致的安全差异:即使模型、工具相同,不同Harness的实现细节也会显著改变安全性
3. Agent生态供应链攻击:恶意Skill、插件或MCP Server通过合法渠道进入Agent执行环境

这三个问题形式各异,但最终攻击的都是同一个目标:模型与现实世界之间的执行层。接下来,我们将通过三个真实案例深入剖析这些风险。

三、案例一:仅通过GitHub Issue,攻入三家顶级AI厂商的官方系统

攻击链条的起点

Novee Security创始工程师、安全研究员Elad Meged在Black Hat大会上展示的研究极具代表性。他针对Anthropic、Google和OpenAI的官方自动化代码仓库进行了安全测试,攻击入口出人意料地简单:GitHub Issue。

这不是复杂的模型越狱,也不是针对模型参数的精巧攻击,而是利用了Harness架构中的信任边界缺陷。Meged最终在三家顶级AI厂商的自动化工作流中发现了不同类型的安全问题:

• 一个漏洞导致代码执行
• 一个漏洞泄露了Harness本以为已过滤的凭证
• 另一个漏洞允许攻击者植入指令,让后续更高权限的处理阶段在未重新验证的情况下信任这些指令

共同的攻击模式

虽然三个漏洞的具体实现各不相同,但Meged总结出的共同模式极具启发性,值得所有企业安全架构师深思:在一个地方做出安全判断,却在另一个权限更高的地方消费这个判断结果。

换言之,一个组件认为某段信息已经”安全”,于是标记通过。随后,另一个权限更高的组件直接接受了这个结果,问题在于:第二个组件没有重新验证。

这种架构模式在传统应用安全中并不陌生——前端校验后后端盲目相信、上游服务过滤后下游高权限服务直接消费、一个低权限组件完成身份判断后高权限组件直接继承结果。但在Agent系统中,这类信任边界问题变得更加危险,因为Agent的执行链条往往极其漫长:

GitHub Issue↓内容分析Agent↓生成处理建议↓自动化工作流↓代码仓库操作↓CI/CD凭证↓生产环境\begin{align*} &\text{GitHub Issue} \ &\quad \downarrow \ &\text{内容分析Agent} \ &\quad \downarrow \ &\text{生成处理建议} \ &\quad \downarrow \ &\text{自动化工作流} \ &\quad \downarrow \ &\text{代码仓库操作} \ &\quad \downarrow \ &\text{CI/CD凭证} \ &\quad \downarrow \ &\text{生产环境} \end{align*}GitHub Issue↓内容分析Agent↓生成处理建议↓自动化工作流↓代码仓库操作↓CI/CD凭证↓生产环境

如果其中某个环节错误地认为”上一个环节已完成安全验证”,攻击输入就可能沿着整个Agent执行链一路传播,最终进入更高权限环境。因此,这类问题的本质并非”模型理解错误”,而是一个典型的信任边界失效(Trust Boundary Failure)。

核心启示:权限提升时必须重新验证

这个案例给企业的第一个核心启示是:每一次权限提升,都应该重新验证。

传统自动化系统常采用一个隐含假设:上游已检查过的数据,下游可直接使用。但在Agent系统中,这个假设风险极高。原因在于Agent处理的输入极其复杂,可能来自用户输入、GitHub Issue、邮件、网页、CRM记录、文档、MCP Server、Skill、插件或第三方API——这些输入本质上都可能不可信。

因此,当Agent流程跨越不同权限边界时,安全团队需要追问三个具体问题:

1. 安全判断在哪里发生?是模型判断内容安全?还是Harness中的过滤模块?还是独立的策略引擎?
2. 谁在消费这个判断结果?是同一进程?还是另一个更高权限的Agent?
3. 消费方是否重新验证?如果没有,这里就可能形成信任边界漏洞。

在Agent安全架构中,一个至关重要的原则是:权限提升后,不应默认继承之前的安全判断。尤其当流程进入Shell执行、文件写入、凭证访问、Git仓库写操作、数据库写入、SaaS管理接口或云资源配置等环境时,安全检查应该重新发生。这与经典安全架构中的”零信任”思想高度契合:不要因为上一个环节信任它,就假设当前环节也应该信任它。

四、案例二:仅更换Harness,攻击成功率从1%飙升至24%

令人震惊的实验结果

如果说Meged的研究展示的是Harness中的”漏洞”,那么Lasso Security的研究则揭示了一个更加值得关注的现象:即使Harness本身不存在传统意义上的软件漏洞,它的设计选择依然可能显著改变Agent的安全性。

Lasso Security在实验中精心控制变量,保持以下因素完全相同:

• 使用相同的开放权重模型
• 使用相同的Prompt
• 使用相同的工具集
• 执行相同的任务

唯一改变的变量是:Harness。

实验结果令人震惊。在某组测试中,仅仅更换Harness,攻击成功率就从1%跃升至24%——提升了24倍。更值得注意的是,在100组”模型+任务”测试组合中,仅因Harness不同,就有43组测试的最终安全结果发生了完全反转。

换言之,同一个模型在Harness A中可能表现得相当安全,但切换到Harness B后,却可能变得明显更易受攻击。

Harness不是”中间层”,而是安全的决定性因素

Michael Sromin因此得出一个关键结论:当你选择一个LLM、工具以及Harness时,你最终得到的是一个Agent;如果你换一个Harness,那么你实际上得到的是另外一个完全不同的Agent。

这句话对企业采购和AI安全评估具有深远意义。因为在很多企业内部,Harness至今仍被视为一种”基础管道”或”胶水代码”。安全团队可能重点测试GPT、Claude等模型本身、Prompt质量、工具能力和模型输出质量,但Harness本身可能被视为可替换的中间层。

Lasso的研究明确指出:这种理解可能严重低估了Harness对Agent安全性的影响。Harness并非单纯的”连接代码”,它会决定:

• Agent循环如何执行
• 工具调用如何触发
• 上下文如何保存
• 不同来源的信息如何组合
• 系统Prompt何时注入
• 外部内容是否进入上下文
• 用户输入与工具输出之间如何隔离
• 模型输出在什么条件下转换成真实操作

这些实现细节看似微小,却会根本性地改变Agent面对攻击时的最终表现。

最佳实践:不要只Benchmark模型,也要Benchmark Harness

目前企业采购大模型时已逐渐形成相对成熟的评估机制,会测试推理能力、幻觉率、响应速度、Token成本、提示注入抵御能力和内容安全能力等指标。但如果Lasso的研究结论成立,那么Agent时代需要增加一个新的Benchmark对象:Harness。

企业不能只问”哪个模型最安全?”,还应该问:”哪个模型、Harness、工具与权限组合,在我们的实际业务环境里最安全?”这是两个完全不同的问题。

因为真正运行在企业内部的,从来不是一个孤立的大模型,而是一个组合系统:

因此,更合理的AI安全测试方式应该是:尽可能还原真实部署环境,然后进行完整的Agent级测试。例如:

• 同一个模型,分别连接不同Harness
• 同一个Harness,配置不同工具权限
• 同一组工具,接入不同外部数据源

然后系统性地测试提示注入、间接提示注入、工具滥用、越权访问、凭证泄漏、跨Agent信任、恶意网页内容、恶意文档和恶意Skill等攻击场景。

只有这样,安全团队测试的才是真实Agent系统的安全能力,而非某个模型在实验室Benchmark中的理论表现。企业不应迷信”99%提示注入防御率”这类数字,因为这些数字很可能来自不符合企业真实部署环境的Benchmark。即使某个模型在实验中表现优秀,也不能推断部署后的Agent同样安全。

五、案例三:恶意Skill通过所有扫描,却能持续重新感染Agent

AI Agent的供应链攻击

如果说前两个问题属于架构和工程实现范畴,那么Zenity披露的研究已将问题扩展到AI Agent供应链领域。随着AI Agent生态蓬勃发展,大量”Skill”正在涌现。Skill可以简单理解为教Agent如何完成特定任务的文件或组件,例如如何操作某个SaaS、调用某个API、执行某种数据分析、处理某类业务流程或使用某种开发工具。

这与传统软件生态中的Package、Plugin、Extension有相似之处。于是,一个经典的安全问题重新浮现:供应链攻击。

Bargury在Black Hat上的评价一针见血:”这就是供应链问题,只不过它现在以Skill的形式重新出现。”但Agent Skill带来的风险又与传统软件包略有不同,原因在于:Skill不仅能执行代码,还可能修改Agent未来持续信任的环境。

持久化攻击:修改Agent Memory实现自我重装

Zenity发现的一种攻击方式极具典型性。许多Agent启动时会加载某个Memory文件,其中包含Agent应该做什么、如何执行任务、哪些规则需要遵守等核心指令。恶意Skill可以修改这个Memory文件,例如向其中写入一条指令:”安装某个恶意Skill”。

即使用户之后删除了恶意Skill本身,Memory中的恶意指令仍然存在。于是形成了一个完整的持久化循环:

攻击因此具备了持久化能力,这已经非常接近传统恶意软件中的Persistence机制。只不过过去攻击者修改的是注册表、启动项、Cron、Systemd或浏览器扩展,现在攻击者修改的是Agent Memory。

工具替换:木马化的合法工具

Zenity研究的另一个恶意Skill采用了更加传统但同样有效的方式:工具替换。这个恶意Skill伪装成合法的Anthropic工具,一旦执行就会:

1. 删除真正的工具
2. 安装攻击者修改后的版本
3. 让Agent继续使用替换后的恶意工具

从用户角度看,Agent仍在执行原有功能,工具名称可能没有变化,工作流也可能没有明显异常,但底层运行的代码已被替换。这实际上就是AI Agent版本的木马化工具(Trojanized Tool)。

规模化攻击:170万次下载的恶意Skill

更严重的是,Zenity还发现了一个规模更大的攻击活动。攻击者克隆了一些流行的开源工具,然后秘密植入登录凭证窃取功能。这些恶意Skill在skills.sh平台上的表现甚至超过了它们模仿的合法工具。最终,在攻击活动被中断前,这批恶意Skill累计获得了约170万次下载。

这个数字背后暴露的不仅是”Skill商店审核不严格”,更值得企业安全团队深思的是:Agent供应链的边界可能远远大于传统软件供应链。

重新定义Agent时代的”供应链”

传统软件供应链相对明确,安全团队知道应关注NPM、PyPI、Maven、NuGet、Docker Hub、GitHub Release等主要渠道。而AI Agent的”依赖”可能来自哪里?答案是:任何Agent能够读取并信任的内容。

Bargury给出了一个极具前瞻性的判断:传统软件的供应链大致集中在十几个主要软件包注册中心,但Agent的供应链可能包括:

• 任意文本
• 任意图片
• 任意网站
• 任意CRM对象
• 任意Skill
• 任意MCP Server
• 任意互联网内容

这是一个根本性的变化。传统软件安全将供应链理解为”我的程序依赖了哪些代码?”,而Agent安全需要将问题改为:”我的Agent信任了哪些内容?”

因为对于AI Agent而言,”内容”本身就可能成为指令。一个网页可能不是普通数据,一个PDF可能不是普通文档,一条CRM备注可能不是普通业务记录,一个GitHub Issue也可能不仅仅是一条Issue。如果这些内容进入Agent上下文并能影响后续工具调用,那么它们实际上都可能成为Agent执行链的一部分。

这也是间接提示注入(Indirect Prompt Injection)成为Agent安全核心问题之一的根本原因。攻击者不需要直接攻击Agent,只需控制Agent会读取的某个对象即可。

六、企业如何应对:从资产盘点到系统化防护

第一步:建立Agent/Harness动态资产清单

理解Harness风险后,一个现实问题随之而来:如何管理?Cisco的Omar Santos指出,企业首先需要面对的挑战可能不是修补漏洞,而是:找到Harness。

原因很简单。绝大多数企业的CMDB或资产清单里,并不存在”AI Harness”这个资产类型。在真实组织内部,这些系统可能被称为Agent、Copilot、Workflow Assistant、Automation、AI Bot、Plugin-based Automation或AI Workflow,不同团队甚至使用完全不同的术语描述几乎相同的架构。

于是Harness就隐匿在代码仓库、SaaS平台、业务系统配置页、自动化工作流、云平台和开发者个人项目之中。安全团队可能知道”公司正在使用Claude”,却不知道Claude连接了哪些工具;或者知道”公司部署了内部Agent”,却不知道这个Agent拥有哪些API Token。

Santos建议企业建立一个持续维护的生产Agent清单,并至少回答三个核心问题:

1. 哪些Agent正在生产环境运行?不要只统计采购的大模型账号,真正需要统计的是能够执行动作的Agent系统。
2. 每个Agent使用什么Harness?包括自研框架、SaaS自动化平台、Agent Framework、IDE Agent和云厂商Agent服务。
3. 每个Harness能够访问什么?重点记录文件系统、Shell、数据库、API、SaaS、云资源、Credential、MCP、Skill和Plugin的访问权限,然后对权限进行最小化。

一个重要的现实建议是:不要等待100%可见性。Santos认为,企业可优先从生产系统开始,通过这种方式相对较快获得60%到70%的可见性,之后再逐步覆盖原型项目、实验性Agent和Shadow AI。对于企业安全治理来说,这可能比试图一次性完成所有AI资产盘点更加现实。

第二步:重新审视Agent的权限模型

Harness之所以成为高价值攻击面,根本原因是:Agent正在获得越来越高的权限。Bargury用了一个极为形象的描述:”你实际上是在和Agent共享你的笔记本电脑,而你的电脑上拥有一切——身份、文件和秘密。”

这并非夸张。许多开发类Agent可以访问用户主目录、SSH Key、Git凭证、云CLI配置、浏览器Cookie、环境变量、API Key、源代码和企业内部文档。如果Agent运行在开发者本机,它获得的权限很可能就是开发者本人权限。于是提示注入的后果就不再只是”模型回答错误”,而可能变成攻击者借助Agent执行了开发者能够执行的操作。

因此,对Agent实施最小权限原则尤为重要,包括:

• 不需要Shell时,不开放Shell
• 只读任务不提供写权限
• 不需要访问整个Home目录时,限制工作目录
• 不把长期Credential直接暴露给Agent
• 不允许Agent默认访问所有SaaS
• 高风险工具调用增加独立授权机制

对于暂时没有专门AI安全预算的企业,Bargury至少建议:将Agent运行在隔离环境中。但他同时强调,这不是完整解决方案,只是一种有帮助的缓解措施。

换言之,Sandbox可以降低爆炸半径,却不能从根本上解决Agent信任恶意内容的问题。

第三步:所有Agent输入都应按”不可信内容”处理

传统应用中,我们已经非常熟悉一句安全原则:”Never Trust User Input”(永远不信任用户输入)。到了Agent时代,这句话需要扩展为:Never Trust Agent Input(永远不信任Agent输入)。

因为Agent的输入来源早已不仅是用户,它可能包括网站正文、搜索结果、邮件、PDF、GitHub Issue、GitHub README、CRM记录、API返回值、Slack消息、MCP Server结果和Skill描述等。

从攻击者角度看,这意味着一个新的攻击路径:攻击Agent会读取的内容。例如,攻击者无法直接访问企业Agent,但如果企业Agent会自动读取某个公开网页,那么攻击者可以尝试控制网页内容;攻击者无法直接向企业Agent发送Prompt,但如果Agent会自动分析GitHub Issue,那么Issue本身就可能成为攻击入口。

因此,Agent安全架构需要逐渐建立一个新的信任模型:External Content≠Trusted Instruction\text{External Content} \neq \text{Trusted Instruction}External Content=Trusted Instruction

外部数据应该只是数据,不能因为模型读取到某段内容,就自动将其升级为执行指令。

第四步:将Agent作为完整系统进行红队测试

目前很多企业在做AI安全测试时,测试对象仍然是模型。例如给模型发送几百条提示注入Payload,然后统计成功率。这种测试有价值,但可能远远不够。

因为真实Agent系统不是简单的”Prompt → Model”,而是:

因此,测试对象也应该从Model扩大到整个Agent。例如可以设计这样的攻击链:

真正需要验证的不是”模型有没有识别出提示注入”,而是:整个系统最终有没有发生不应该发生的动作。这才是Agent级安全测试。

第五步:审计默认配置,”Read the defaults, not the documentation”

在攻破三家AI厂商官方自动化系统后,Elad Meged总结了一句极具实践价值的话:”Read the defaults, not the documentation”(审查默认值,而非文档)。

不要只看文档,要看默认配置。因为安全文档描述的是系统理论上应该如何工作,而真正决定攻击面的往往是系统默认实际上如何工作。例如:

• 默认是否允许Shell?
• 默认能访问哪些目录?
• 默认是否共享Workspace?
• 默认是否继承Credential?
• 默认是否信任工具返回值?
• 默认是否自动加载Skill?
• 默认是否允许MCP Server执行高权限动作?
• 默认是否重新验证跨阶段数据?

这些”默认值”往往比产品白皮书里关于AI安全的描述更加重要。Meged在演讲中提到:”产品说它是安全的,而这正是我们开始测试的地方。”对于企业安全团队来说,这也是一个很好的Agent安全测试起点。

七、从三个案例看AI安全边界的根本性转变

回顾这三个案例,我们可以清晰地看到一个共同的结论:

第一个案例:利用GitHub Issue进入官方自动化系统,根因不是模型越狱,而是跨组件信任边界设计错误。

第二个案例:更换Harness后攻击成功率从1%升至24%,根因不是模型变化,而是Harness实现方式改变了安全结果。

第三个案例:恶意Skill窃取凭证、替换合法工具并通过Memory实现持久化,根因不是模型恶意,而是Agent供应链和运行环境遭到污染。

三个研究方向完全不同,但结论高度一致:Securing the model is not the same thing as securing the agent(保护模型不等于保护Agent)。

结语:从”模型安全”走向”系统安全”

过去讨论生成式AI风险时,我们习惯问:模型会不会做坏事?而Agent时代,一个更加现实的问题是:如果模型做了它认为正确的事情,周围的系统会不会因此产生危险?

这两者有本质区别。模型可以完全按照设计运行,攻击者仍然可以污染它读取的信息、利用Harness中的信任边界、替换Agent依赖的Skill、修改Agent Memory或诱导Agent调用它本来就有权限使用的工具。此时,真正的问题不是模型有没有”失控”,而是:我们给了它什么眼睛、什么手脚,以及多大的行动权限。

这也是为什么Harness正在成为一个越来越值得关注的AI安全概念。从安全架构角度看,它甚至不是一个完全新的问题——权限控制、供应链安全、输入验证、信任边界、最小权限、执行隔离,这些都是安全行业研究了几十年的经典原则。

真正变化的是:这些经典安全问题,现在被重新组合进了AI Agent。而Agent又拥有传统软件所不具备的一项特征:它能够读取自然语言,并将自然语言理解成行动意图。于是,文本、网页、图片、Skill、MCP以及各种业务数据,都可能进入它的决策链。

这意味着企业未来建设AI安全体系时,需要完成一次重要的视角转换:从”这个模型安全吗?”走向”这个Agent系统安全吗?”

而在这个系统里,Harness恰恰处在最关键的位置。它连接模型与真实世界,承载权限,维护上下文,调用工具,决定模型输出最终会不会变成现实操作。

因此,对于已经开始大规模部署AI Agent的企业而言,下一阶段AI安全建设的重点,或许不应该只是继续围绕模型增加一层又一层安全护栏,更重要的是重新审视:谁正在给模型装上手脚,以及这些手脚究竟能够碰到什么。

只有当我们真正理解Harness这个新攻击面的本质,建立起完整的Agent级安全防护体系,才能在AI赋能业务创新的同时,确保企业的数字资产和业务安全不会因为这些”眼睛和手脚”而暴露在新的风险之下。

这不仅是技术挑战,更是企业安全战略的一次重要升级。

相关阅读

3.61美元一个PoC，21分钟出利用：微软MSRC内部数据曝光，漏洞响应团队正在失效”

你采购的不是软件，而是一个会”进化”的供应链风险：AI供应商选型实操指南

92%企业栽在同一个坑：AI Agent权限比模型算法致命一万倍

联系我们

合作电话：18610811242

合作微信：aqniu001

联系邮箱：[email protected]

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全牛 《别只盯着LLM越狱了！Harness才是AI Agent的“阿喀琉斯之踵”：换层皮，攻击成功率从1%暴涨到24%》