本文整理自百度智能云云安全架构师林道正在 AICon 大会上的主题演讲《Agent 想用但不敢用？百度智能云企业级 Agent 安全落地实践》。

今天主要与大家分享三部分内容：

• 企业对 Agent 安全的顾虑和真实需求；
• 百度智能云在业务实践中的经验、问题与方法论；
• Agent 安全未来的发展方向

1. 企业在顾虑什么

产品在变，安全需求没变Agent 正在重塑工作方式，但企业迟迟不敢让它深入业务系统，核心顾虑仍然集中在几类问题：数据会不会泄露，Agent 会不会误删数据库，失控后如何追责，大模型 Token 会不会被恶意 Skill 窃取并造成巨额账单，以及如何满足合规要求。

这些问题可归纳为数据泄露、事故责任、权限控制、凭证窃取和合法合规。回看安全需求的演进：2000 年前后防护个人终端，重点是防病毒；2010 年前后防护企业终端，重点是策略、资产与告警；之后扩展到企业资产，形成 EDR、DLP 和跨端响应；今天进一步追求业务不中断，走向 XDR、业务安全与全局治理。载体和执行机制不断变化，但企业对安全的根本需求始终没有改变。

攻击链的四个节点始终一致：不可信输入、获得信任、继承权限、触达资产。

• PC 时代对应可执行程序、用户安装运行、用户或管理员账号、主机与内网；
• Agent 时代则对应 Skill/MCP/Query、AI 检索与主动安装、委托身份、Token 与工具权限、业务数据、代码库和云资源。
  

从软件生态到 Agent 生态

安全目标和基本方法论没有变，剧烈变化的是底层生态：过去分发可执行程序，现在分发 Skill。二者都是可复用的工具、方法和流程；可执行程序能作恶，Skill 同样能作恶。因此，恶意可执行程序与恶意 Skill 在攻击手法、流程和目的上高度相似，都会通过伪装、隐藏等方式控制系统，窃取凭证并滥用权限。

战场变了，但似曾相识：模型上下文相当于当年计算机的内存。 Skill 是 Prompt 与可执行程序的结合体，增加了上下文、模型和工具组合带来的语义级对抗，但传统攻防经验仍然适用。

值得注意的是，攻击演进速度明显加快。Skill 安全检测服务上线后，恶意 Skill 的手法按周、按月变化，已开展至少五轮攻防迭代。当前 Skill 仍是攻击性价比很高的路径。

言行不一：恶意 Skill 的主流手段

恶意行为的共同点是 Skill 的声明与实际行为不一致。例如 Skill 声称帮助查天气，实际却在统计和窃取 Token。对定向采集的黑样本集进行静态分析，在 3,059 个 Skill 中确认恶意 3,026 个；98.1% 缺少知情授权，未获用户明确同意就试图扩大权限；55.1% 未充分披露危害行为。另有 35 个二进制、图片或归档制品采用混淆机制，静态环境难以分析真实意图。

由此可见：声明 ≠ 授权 ≠ 行为。

下面通过三个我们分析过的典型样本，看看言行不一在现实中长什么样。

案例一：FakeGit，AI 搜索刷榜上位

FakeGit 仿冒主流下载站，制作与官方几乎相同的 Skill 仓库，通过刷 Star、投流等方式提高搜索排名。用户搜索并安装同名工具时，正常功能仍可使用，但执行过程中会额外运行攻击者植入的程序。

公开报告显示，恶意 GitHub 仓库约 7,600 个，其中约 1,400 个与 AI 相关，800 多个伪装成 Skill 或 MCP Server，相关 Release 资产下载量超过 1,400 万次，真实官方仓库反而可能排在后面。

Agent 推荐哪个仓库，本身就是一次安全决策。Skill 核验至少应关注四个维度：发布者身份，包括组织域名、邮箱和二步认证；维护历史，包括 commit 时间线和协作者稳定性；Release 一致性，包括资产哈希、签名和来源；依赖来源，包括是否再次指向外部下载程序。

案例二：ClawHavoc，把恶意代码藏在云端

市场审核会扫描上传的 Skill，但攻击者可以让 Skill 静态内容保持干净，等真正运行时再从云端拉取恶意代码。某快照中发现 341 个恶意项，其中 335 个属于同一攻击活动；半个月后增至 824 个，而市场规模已超过 10,700 条。样本载荷覆盖 19 类浏览器、150 个浏览器扩展钱包和 17 个桌面钱包。

市场审核只能覆盖审核时可见的内容，无法覆盖动态下载并运行的远程代码。Skill 运行后即使处于沙箱，也可能拥有近乎 Root 的能力，因此必须把运行时风险纳入治理。

案例三：Clawsights，模型拒绝不等于运行前控制

Clawsights 声称分析 Claude Code 统计数据并上传排名，却同时读取并上传 GitHub Token。

Datadog 安全研究团队在受控实验中改进该 Skill，进一步利用 Agent 的动态上下文注入机制，在模型看到内容前，通过自定义脚本藏入并运行恶意二进制。那么敏感命令在模型「看到」内容之前就已经运行了，模型只能阻止下一步，不能撤销已经完成的读取和外发。

这说明威胁不仅来自 Skill，也来自 Agent 自身的执行机制。

单点防护的局限

三个案例共同说明，单层防护无法覆盖完整风险。护栏可能把正常统计行为的 Skill 放行，传统 DLP 也可能把「上传数据参与排名」视为正常，但在上传数据中，可能藏着加密混淆过的 Token。单看任何一层，都发现不了。

一次 Agent 任务可拆为六步：外部内容/Skill → 候选发现 → Agent 规划 → 工具/进程 → 数据/业务 → 执行结果。静态扫描和市场审核主要覆盖最左端，只解决准入。完整治理还需分析五个维度：身份继承（长期 Token 被 Agent 任意复用）、工具与版本/组合（合法能力串成越权路径）、目标/动作漂移（授权目标 A，运行时变成 B）、数据投毒/泄露（入站被污染、出站被盗走）、责任与证据断裂（出了事无法回放到人）。

回看三个案例：ClawHavoc 是外部代码执行借「身份」提权，把恶意代码跑成了合法进程；FakeGit 是「候选发现」被劫持，模型把恶意仓库当成首选工具推荐；Clawsights 是 Skill 正式加载之前，「数据」已经被预执行的恶意代码读走并外发。

所以，想约束一次任务，必须体系化解决。

2. 百度 Agent 安全中心：企业级 Agent 安全实践

百度 Agent 安全中心对 Agent 防御应形成纵深体系：身份安全、工具安全、行为安全、数据安全与审计。

每一步都要回答：谁授权、以谁的身份执行；任务目的是什么；依赖什么工具；访问哪些数据；出了问题谁负责、原因能否回放。所有决策由任务 ID 串联，覆盖完整 Agent Loop。

身份：按任务雇用的临时工
Agent 既不是员工，也不是普通工具，企业原有账号体系需要重新适配。当前常见做法是把员工长期身份和全量权限直接交给 Agent。这样一个查询操作可能因恶意 Skill 或 Bug 变成删除或外发，甚至造成业务资料公开。身份层的首要作用，就是明确它只能在哪些环境中运行、以什么权限访问哪些资源。

第二阶段是数字员工身份：从员工长期身份派生独立 Token，只继承完成工作所需的部分权限，例如拥有约 30% 权限即可完成约 80% 的工作，并支持按天或按小时独立授权和迭代。它与员工身份分离，便于独立审计、撤销和调整。

第三阶段是任务级临时身份：凭据由用户委托、任务目的、最小资源、有效期和可撤销性共同构成，生命周期缩短到分钟或小时。查周报只给相关系统的读权限，排查数据库问题不应拥有写入、删库或发邮件权限。动态授权仍有挑战，但核心是持续收敛 Agent 的行为边界，让权限跟着任务走，而不是跟着智能体长期不变。

工具：准入、持续监测、风险画像

工具治理覆盖候选发现、规划和执行三个环节，形成三步闭环。

第一是提高准入门槛，从发布者身份与组织签名、版本/Commit/哈希锁定、权限声明与参数 Schema、依赖 SBOM 与传递依赖、静态扫描与恶意特征、沙箱行为评测等维度核验。

第二是持续监测。准入安全不代表运行安全，远程恶意代码可能只在极短时间窗口出现，版本声明也可能与实际内容不一致，因此要采集多维运行数据并持续分析。

第三是风险画像。将准入和监测数据打通，为每个工具、Skill 和 MCP 建立来源可信度、历史行为等画像，作为规划阶段的决策依据，优先选择低风险工具并拦截高风险组合。

行为：规划和执行都要监测

行为安全包括思考层和执行层：前者是提示词进入模型后的规划及工具选择，由护栏防护；后者是规划结果由二进制或脚本实施时的 Runtime 行为。两层监控必须关联并汇聚到统一中心，才能发现跨层攻击和 Skill 的言行不一。

工程落地有四点经验：沙箱行为观测比一味阻断更重要，在最小权限下先保留完整观测。防护策略总要在业务、性能和成本之间权衡；在阻断与观测冲突时，宁可先保证观测，因为沙箱和最小权限已经压缩了风险，准确、全面的行为证据更有利于后续处置。重新设计 Runtime 生命周期，适配沙箱五到二十分钟的短生命周期。极致的最小资源占用，极度压缩探针的内存和 CPU 占用，以适应一虚五十、一虚一百的部署密度；同时联动身份和数据网关，将数据汇入威胁分析平台，形成检测与阻断闭环。

数据：入站防投毒，处理中限目的，出站防泄露

数据安全不能只关注敏感数据出域，也要防止恶意数据入站。网页、邮件、RAG 结果以及开放 Issue 都可能携带提示词注入，污染模型上下文。例如 Agent 修复开源组件 Bug 时，攻击者可在 Issue 评论中诱导其发送 API Token。入站数据应默认不可信，经过清洗、分级、脱敏和上下文隔离后才能进入模型。

完整防护是三段链、三次独立授权：入站默认不可信；处理中按任务目的最小读取；出站绑定接收方、字段、目的、协议和时限，并配合 DLP、目的回查和去标识化。可读取 ≠ 可组合 ≠ 可发送。

审计：责任到人，证据可回放
审计要回答谁发起、谁审批、依据哪版策略、发生了什么以及谁处置。执行证据包应包括发起与委托、任务目标与风险等级、审批范围、策略/模型/Skill/工具版本快照、计划与调用轨迹、数据流和结果，以及阻断、撤销和处置记录，由此形成事前定责、事中决策阻断、事后回放处置的闭环。

实践中最大的难点是系统间日志不相通，轨迹串联复杂，因此审计能力必须自上而下一体化设计。一次任务不仅要记录最终结果，还要保留模型规划、工具调用、数据流向和策略版本，否则出了问题只能看到结果，无法判断偏离发生在哪一步。未来需要面向 Agent 的日志审计系统整体解决可审计、可回溯问题。

3. 安全向何方

百度 Agent 安全中心将进一步细化颗粒度，让每一步执行都可视、可管、可审计。

身份从长期凭据走向任务级身份。 生命周期缩短，权限颗粒度变小。企业应按业务重要性权衡：重要场景严格管控，非重要场景采用性价比更高的策略，优先做好关键的少数场景。

行为从单端检测走向全局联动。 数据将跨层、跨 Agent、跨业务汇聚，安全视角从单一病毒或攻击扩大到业务失控；由于 Agent 天然跨越多个系统，单端检测必然走向全局检测。

工具治理趋同于应用商店。 参考手机应用生态，建设权威 Skill 市场，配合严格准入、签名分发、沙箱动态监测、评分和标签，提高恶意 Skill 的传播与作恶成本。

数据从规则过滤走向语义对抗。 间接提示词注入和数据投毒会进入更深的对抗阶段，敏感数据出站与恶意数据入站的语义识别将成为必备能力。

审计从日志留存走向证据闭环。 通过顶层设计打通日志、串联轨迹，形成可回放、可追责、可巡检和可运营的数据闭环。

Agent 发展迅速，黑产攻防迭代更快，但攻击思路仍延续了过去十多年甚至更久的安全实践。企业可以基于既有防守体系，搭建立体化防御，缓解 Agent 落地风险。

百度 Agent 安全中心从单点防控走向全局治理，围绕身份、行为、工具、数据和审计五个维度，以任务为主线形成「授权、执行、处置、追溯」的安全闭环，帮助企业在 Agent 落地过程中做到可视、可管、可审计。