Agent安全，该内生还是外挂？- 大数跨境

AI与安全

2026-10-18

导读：AI Agent 能力越来越强，风险也越来越大，问题不断出现。安全，是AI Agent不得不面对的问题。

引言

IT系统发展几十年，最初安全问题考虑得比较少，后来不得不在系统里增加防火墙，入侵检测，防病毒，主机安全这些东西，我们称之为安全外挂。后来，云计算、智能手机发展，很多安全的内容，被整合进系统，比如云的隔离能力，手机里的运行砂箱，我们称之为安全内生（有时也叫design in).

AI Agent 正在从「会聊天」走向「会干活」。它读写文件、执行脚本、调用工具，替你处理邮件、整理账单、操作云端资源。能力跃迁的同时，风险也被同比例放大：过去一年里，提示词注入、敏感数据泄露、越权操作等事故接连出现。安全，是AI Agent不得不面对的问题。

今天的Agent安全，内生和外挂的思路在同步发展。

一、Agent 的安全风险

Agent 与传统应用的差别，在于它「理解」指令、「自行」决策、「主动」调用工具。这三点既是能力，也是攻击面。

第一，提示词注入（Prompt Injection）。攻击者把恶意指令藏进网页、文档、邮件甚至搜索结果里，诱导 Agent 越权执行。这是目前最难根治的一类威胁，因为它发生在模型「理解」的层面，很难用传统规则拦截。

第二，数据泄露。 Agent 天然要接触密钥、凭证、客户资料等敏感信息，一旦在输出或对外调用时被「带出去」，损失往往无法追回。

第三，权限滥用与误操作。 Agent 通常被赋予较大权限，一次理解偏差就可能删库、覆盖配置、批量删除文件。

第四，工具与供应链风险。 MCP 插件、第三方工具、自定义脚本，本身可能被植入后门，或成为注入攻击的跳板。

第五，自主性失控。长时运行的 Agent 一旦跑偏边界，如果缺乏实时兜底，伤害会持续累积，事后才发现。

二、两条路线：内生 vs 外挂

路线 A：内生——把安全做进 Agent 里

典型代表是 WorkBuddy、DeepSeek Harness（DSH）这类个人助理。它们把一部分安全能力直接内嵌进产品：工作空间沙箱、默认权限确认、敏感信息检测、删除保护与自动备份、工具/MCP 管控、审计日志，甚至「受限模式」和工作区信任机制。以 WorkBuddy 为例，它在「默认权限」下以工作空间为边界，普通操作直接放行，遇到删除、越界写入、执行脚本、网络访问等高风险动作才停下来让用户确认，背后还有沙箱、备份、敏感识别多层兜底。

这条路最大的优点是开箱即用、配置简单。普通用户不需要懂容器、配策略，默认设置就能挡住大部分误操作，安全和体验几乎无感地融合在一起。

但它的短板同样明显：这层能力更像「护栏」，而不是「硬隔离」。模型和 Agent 框架跑在同一个进程里，应用层控制本身就可能被绕过。此前已有安全研究披露，个别 Agent 能被诱导「关闭自身的沙箱限制」；NVIDIA 在发布 OpenShell 时也直言，多起事故的共性是「Agent 绕过了应用层的安全控制」。换句话说，靠 Agent「自律」的内生防护，天生存在一个盲区——它拦不住一个铁了心要越界的 Agent。

路线 B：外挂——把控制点放到 Agent 之外

典型代表是 NVIDIA 的 OpenShell。它的思路一句话概括：安全控制点不在 Agent 里，而在它外面，用操作系统内核兜底，而不是靠 Agent 自觉。

openshell 架构图

OpenShell可以按Gateway、Supervisor和Sandbox三类核心组件理解，底层还依靠计算驱动建立隔离环境。Gateway是控制面，负责访问认证、沙箱生命周期协调、策略版本及Provider配置管理，并提供交互连接入口；容器或虚拟机由计算驱动实际创建和清理。Supervisor位于Agent工作负载的信任边界之外，负责网络策略检查、DNS解析、连接代理和托管凭据的使用。Sandbox组件与Agent一起运行，管理其进程、识别请求来源，并通过受控通道把TCP和DNS请求交给Supervisor。

在当前Linux执行后端中，Agent使用非root身份且不持有Linux capabilities，文件访问由Landlock约束，危险系统调用由seccomp限制。严格要求文件规则不可降级时，应使用hard_requirement配置。外层网络隔离阻止工作负载绕过Supervisor直接访问外部服务；Kubernetes部署还要求CNI正确执行NetworkPolicy。

在此基础上，OpenShell提供三类值得关注的能力。

一是协议级的精细管控。 Supervisor 不只是放行或掐断一条连接，还能解析 HTTP、GraphQL、MCP 流量，做到「同一个 API，允许读、禁止写」——比如只给 Agent 开一个 GitHub 只读接口，POST 写操作照样被拦下。

二是凭据与 Agent 彻底隔离。真实的密钥、云凭据根本不进入 Agent 工作负载，Agent 手里只有一个占位符；Supervisor 在确认目标端点是授权端点后，才在外面代换出真实凭据。一处授权不等于处处可用，凭据被绑定到授权请求上，还能叠加「只读」约束。

三是策略可证明、可审计。权限用声明式 YAML 描述、编译成 OPA/Rego，每个出站请求都过一遍；所有决策落成 OCSF 审计日志。更关键的是它带一个形式化验证器：用形式逻辑证明「这套策略授予的权限仍落在边界内」，或直接指出某个动作越界。因为结论来自策略模型而非 Agent 的说辞，Agent 无法靠话术蒙混——在对抗实验中，前沿 Agent 花了两个多小时试图说服 AI 审核员放权，形式化分析让审核员看清这些权限意味着什么，最终没有发生受保护仓库的写操作。

Openshell使用配置都比较复杂：Agent 必须跑在 OpenShell 的沙箱/容器里，依赖 Docker、Podman、MicroVM 或 Kubernetes 这类计算驱动，等于让 Agent「迁就」安全边界。功能完善，但部署更重、迁移更难，个人和小团队用起来门槛不低——这正是外挂方案「强而重」的由来。若要再硬一层，NVIDIA 还提供了基于 DPU 硬件的带外看门狗 Sentry，越界可毫秒级隔离，但那已经是重资产企业的选择了。

三、未来：不是二选一，而是并行

我认为，未来会走向「内生与外挂并行」。

其一，大的 AI Agent 会逐步完善自己的安全能力。逻辑是「先跑业务、再补安全」：业务规模起来之前，安全不是第一优先级；等它成为生产力工具、触达企业核心资产时，安全就成了竞争力和卖点，厂商自然会持续内嵌，从「护栏」进化成更完整的治理体系。

其二，大量小 Agent 没有能力在安全上投入。它们可能就是一个开源框架加几个插件，既缺团队也缺资源，指望它们自建安全不现实。这类 Agent 最现实的选择，就是直接采用 OpenShell 这类外挂方案，把安全「外包」给成熟的边界。

其三，即使是内生，也不可能包打天下。比如身份管理（IAM）、密钥管理、企业级合规审计，天然需要对接第三方基础设施和统一策略，Agent 自己「内嵌」不了，也不该内嵌——它们必须借助外部的身份与治理平台。

所以结论不是谁取代谁，而是分层：Agent 内部做「业务态」安全——权限确认、敏感识别、工具管控，追求开箱即用；外部做「强制态」安全——隔离、审计、身份、密钥，追求不可绕过。两者各管一段，互相补位。

结语

安全没有银弹。对 Agent 而言，最好的未来也许不是把安全「装」进某一个位置，而是让内生与外挂各司其职、并行不悖——大 Agent 自己长肌肉，小 Agent 借外力穿上铠甲，再把身份等能力交给专业的第三方，它最终会融入整个系统。

【声明】内容源于网络

AI与安全

理清逻辑，找到规律，看清趋势。作者前华为云高级安全专家。

内容 156

粉丝 0

AI与安全理清逻辑，找到规律，看清趋势。作者前华为云高级安全专家。

总阅读3.7k

粉丝0

内容156