AI 安全这个词这两年出现的频率越来越高但大多数讨论都停留在“对齐”“价值观”“模型会不会失控”这类偏哲学的层面。我做了几年智能体系统的落地越来越强烈地感觉到一件事AI 安全本质上不是一个模型问题而是一个工程问题。模型再聪明如果它运行在一个没有边界、没有权限控制、没有审计能力的环境里那它就是一个随时可能闯祸的黑盒。反过来哪怕模型能力一般只要整个智能体技术栈的每一层都有工程化的约束系统的整体安全性就能做到可控、可观测、可回滚。这篇文章想聊的就是这件事怎么在智能体技术栈的每一层去解决安全问题。从最底层的执行环境到中间的运行时管控再到上层的工具调用和输出过滤每一层都有它该干的活。适合正在做智能体落地、或者准备把 AI 能力接入生产系统的同学参考。不管你是刚接触这块还是已经在踩坑路上应该都能找到一些能直接抄作业的东西。1. 为什么说 AI 安全是工程问题而不是模型问题1.1 模型层面的安全承诺为什么靠不住先说我自己的一个判断把安全寄托在模型自身的“自觉”上是最不靠谱的一种做法。原因很简单模型是一个概率系统它的输出是采样出来的不是确定性的。你今天用一套提示词让它拒绝某个请求明天换个说法、加个角色扮演的壳它可能就绕过去了。这不是模型“不听话”而是它的工作机制决定的——它没有真正的意图判断能力只有模式匹配。我见过太多团队在提示词里写一大堆“你不能做这个、不能做那个”然后上线之后发现稍微绕一下就能突破。这不是提示词写得不好而是用自然语言去约束一个自然语言系统本身就是同构的对抗注定是猫鼠游戏。你补一个漏洞对方换一个说法永远追不上。所以我的结论是模型层面的安全措施要有但只能当作“第一道软防线”真正兜底的必须是工程手段。就像操作系统不会指望每个程序都自觉不干坏事而是用进程隔离、权限控制、系统调用来约束它。智能体也一样得有一套工程化的约束体系。1.2 智能体技术栈的分层模型要谈“每一层怎么解决”先得把栈分清楚。我一般把智能体技术栈从下往上分成这么几层层级名称主要职责安全关注点L1执行环境层提供代码/命令运行能力隔离、资源限制、文件系统边界L2运行时管控层调度、权限、生命周期权限最小化、审计、中断能力L3工具与能力层外部 API、数据库、文件操作调用鉴权、参数校验、速率限制L4编排与决策层任务规划、多步执行步骤审查、危险动作拦截L5输入输出层用户输入、模型输出注入防护、内容过滤、脱敏这个分层不是绝对的不同系统会有差异但大方向是这样。核心思路是每一层都假设上面一层可能被攻破自己这一层要有独立的防线。这就是经典的纵深防御思想只不过用在了智能体上。1.3 纵深防御在智能体场景下的具体含义纵深防御这个词听起来很虚落到智能体上其实很具体。举个例子用户让智能体“帮我整理一下项目目录里的文件”。这句话本身没问题但如果智能体在执行时生成了一个rm -rf的命令那就出大事了。在纵深防御的思路下这个风险会在多个层面被拦截L1 执行环境层命令跑在沙盒里文件系统是挂载的临时目录删了也不影响宿主机。L2 运行时管控层危险命令模式被识别执行前需要二次确认或直接拒绝。L3 工具层文件操作走的是封装好的 API不是裸的 shell删除操作有回收站机制。L4 编排层任务规划阶段就把“整理”拆解成“读取、分类、移动”不包含删除。L5 输出层最终给用户的报告里会说明做了哪些操作用户能复核。你看任何一层单独拿出来都不完美但叠在一起出事的概率就极低了。这就是工程化的价值——不追求单点的绝对安全而是追求系统整体的可控性。2. 执行环境层沙盒化是智能体安全的地基2.1 为什么智能体必须跑在沙盒里智能体和普通程序最大的区别是它的行为是动态生成的你没法在写代码的时候就穷举它所有可能的操作。普通程序你 review 一遍代码知道它会干什么智能体你只能给它一个目标具体怎么干是它自己决定的。这就意味着你必须在它运行的环境上做文章。沙盒化执行环境的核心目标就三个隔离、限制、可丢弃。隔离是指它碰不到宿主机和其他服务限制是指它能用的资源CPU、内存、网络、文件是受控的可丢弃是指这个环境用完就扔不留痕迹下次从干净状态开始。我自己的经验是没有沙盒的智能体系统不要上生产。哪怕只是内部用也建议至少跑在容器里。因为一旦它有了执行能力出问题的速度会比你想象的快得多。2.2 沙盒的几种实现路径与选型对比沙盒不是只有一种做法不同场景选型差别很大。我整理了几种常见方案方案隔离级别启动速度适用场景注意事项进程级隔离低极快只跑纯计算、无外部调用文件系统共享风险高容器隔离中快大多数智能体执行场景注意挂载卷和网络策略轻量虚拟机高中等需要强隔离的多租户场景资源开销较大专用安全运行时高快对启动速度和隔离都有要求需要额外集成工作这里要特别提一下OpenShell这类安全运行时的思路。它本质上是在容器和虚拟机之间找了一个平衡点用轻量化的方式提供接近虚拟机的隔离级别同时保持接近容器的启动速度。对于智能体这种“频繁创建、用完即弃”的场景这个平衡点很关键。你不可能每个任务都起一个完整虚拟机太慢了但纯容器隔离在某些场景下又不够。选型的时候我的建议是先看你的威胁模型。如果智能体只处理内部数据、不接触不可信输入容器隔离基本够用。如果它会处理用户上传的文件、访问外部网络那就得上更强的隔离。别一上来就追求最高级别成本会压垮你。2.3 文件系统与网络边界的实操配置沙盒配置里最容易出问题的就是文件系统和网络这两块。我踩过的坑基本都在这。文件系统方面核心原则是只挂载必要的目录而且尽量只读。如果智能体需要写文件给它一个独立的临时目录任务结束就清掉。绝对不要把宿主机的根目录、home 目录、或者包含密钥的配置目录挂进去。我见过有人图省事把整个项目目录挂进去结果智能体一个误操作把源码删了。网络方面默认应该是拒绝所有出站按需放行。很多智能体任务其实不需要联网那就直接断网。需要联网的用白名单机制只允许访问特定的域名或 IP 段。这里要注意 DNS 也可能被滥用最好把 DNS 也纳入管控。# 一个容器沙盒的典型启动参数示例示意 # 只读挂载工作目录独立可写临时目录限制资源默认断网 docker run --rm \ --read-only \ --tmpfs /tmp:rw,size64m \ -v /path/to/workspace:/workspace:ro \ --memory512m \ --cpus1 \ --networknone \ --security-opt no-new-privileges \ agent-runtime:latest这段参数里每一项都有用意--read-only让根文件系统只读--tmpfs给一个内存临时目录用于写--networknone直接断网no-new-privileges防止提权。实测下来这套配置能挡掉大部分低级风险。2.4 资源限制与超时机制的必要性资源限制不只是为了省钱更是安全手段。一个失控的智能体可能陷入死循环、疯狂创建进程、或者把内存吃满拖垮整个宿主机。所以CPU、内存、进程数、执行时间这几个维度都要设上限。超时机制尤其重要。智能体有时候会卡在某个步骤上比如等一个永远不返回的网络请求。如果没有超时它会一直挂着占用资源。我的做法是给每个任务设一个总超时再给每个子步骤设一个更短的超时任何一层超时都触发中断和清理。提示资源限制的值不要拍脑袋定先跑一批真实任务看 P95 的资源消耗然后在此基础上留 2 到 3 倍余量。定太紧会误杀正常任务定太松就失去意义。3. 运行时管控层权限、审计与中断能力3.1 最小权限原则在智能体上的落地最小权限这个原则大家都听过但落到智能体上很多人就忘了。智能体应该只拥有完成当前任务所必需的最小权限而且这个权限应该是动态授予、用完回收的。具体怎么做我的经验是给智能体设计一套“能力令牌”机制。每个任务开始时根据任务类型授予一组能力比如“读文件”“调用某个 API”“写临时目录”。任务结束令牌失效。智能体在执行过程中如果需要额外能力得走审批流程不能自己给自己扩权。这样做的好处是即使智能体被注入了恶意指令它能造成的破坏也被限制在当前任务的能力范围内。它想删数据库对不起这个任务没授予数据库写权限。3.2 操作审计日志该记什么、怎么记审计日志是事后追溯的唯一依据但很多团队的日志记得一塌糊涂出了事根本查不出来。我总结了几条必须记的内容谁发起的用户标识、会话 ID、任务 ID。智能体做了什么每一步的动作、参数、时间戳。调用了什么工具名、API 端点、请求摘要。结果是什么成功/失败、返回摘要、异常信息。决策依据如果是模型决策的记录当时的上下文摘要。格式上建议结构化JSON 最好方便后续检索和分析。存储上要独立于智能体的执行环境防止被篡改。我一般会把审计日志写到独立的日志服务智能体本身没有删除权限。注意审计日志里可能包含敏感信息比如用户数据、密钥片段。记录前要做脱敏或者对日志本身加密存储。别为了审计把敏感数据泄露了。3.3 中断与熔断让智能体“停得下来”一个安全的系统必须能随时停下来。智能体最怕的就是“刹不住车”——发现它在干坏事但你没法及时中断。中断能力要分几个层次任务级中断用户或管理员可以随时终止整个任务。步骤级中断在每一步执行前检查中断信号及时响应。熔断机制当检测到异常模式比如短时间内大量失败、访问敏感资源时自动暂停并告警。实现上中断信号可以通过一个共享的状态标志来传递智能体在每个关键节点检查这个标志。熔断则需要一套规则引擎实时监控行为流。我踩过的一个坑是中断信号发了但智能体正卡在一个长时间的 API 调用里等它返回时已经过了好几分钟。后来我在所有外部调用上都加了超时并且用异步方式执行主循环能及时响应中断。3.4 一个运行时管控的配置实例下面是一个运行时管控配置的示意展示权限、审计、中断怎么组合在一起# 智能体运行时管控配置示意 runtime: task_timeout: 300s step_timeout: 30s max_steps: 50 permissions: default_deny: true granted: - read:/workspace - write:/tmp/agent - call:internal_search_api audit: enabled: true endpoint: https://audit.internal/log include_params: true redact_fields: [password, token, secret] interrupt: check_interval: 1s circuit_breaker: - condition: failure_rate 0.5 within 60s action: pause_and_alert - condition: access_sensitive_resource action: block_and_log这份配置的核心思想是默认拒绝显式授予全程记录异常熔断。你可以根据自己的场景调整具体值但结构可以照搬。4. 工具与能力层把危险操作关进笼子4.1 工具调用的鉴权与参数校验智能体调用工具是它和外部世界交互的主要方式也是风险最集中的地方。每一个工具调用都必须经过鉴权和参数校验不能因为是“内部调用”就放行。鉴权方面工具应该验证调用方是否有权限执行这个操作。这个验证不能只靠智能体自己声明而应该由工具侧独立判断。比如智能体说“我要读这个文件”工具侧要检查这个文件是否在允许范围内而不是信任智能体的说法。参数校验方面要对所有输入做严格检查。类型对不对、范围合不合理、有没有注入风险。我见过智能体生成的 SQL 语句里带了奇怪的条件如果工具侧不做校验直接就执行了。4.2 危险操作的识别与二次确认有些操作天生就危险删除、覆盖、发送、支付、修改权限。对于这类操作我的做法是强制二次确认。确认的对象可以是用户也可以是预设的审批流程。识别危险操作可以用规则匹配也可以用模型判断但规则更可靠。维护一个危险操作模式库比如命令里出现rm、drop、truncateAPI 调用涉及delete、transfer就触发确认流程。二次确认不是走形式要真的把操作内容和影响范围展示给确认方。比如“即将删除 /workspace/data 目录下的 128 个文件总计 2.3GB”这样确认方才能做出判断。4.3 速率限制与配额管理速率限制是防止智能体“暴走”的有效手段。一个正常的任务不会在一秒内调用 1000 次 API如果出现了那大概率是出问题了。配额管理则是从资源角度做约束。给每个任务、每个用户设定调用配额用完就停。这样即使智能体陷入循环也不会无限消耗资源。我的经验是速率限制要分层设置单任务级别、用户级别、系统级别。任何一层触发限制都要记录并告警。有时候限制触发本身就是异常的信号。4.4 工具封装不要给智能体裸的 shell这是我最想强调的一点永远不要给智能体一个裸的 shell。裸 shell 意味着无限可能也意味着无限风险。正确的做法是把所有能力封装成语义明确的工具。比如不要给智能体exec(bash)而是给它list_files(dir)、read_file(path)、write_file(path, content)、move_file(src, dst)这样的工具。每个工具内部做好校验和边界控制智能体只能通过这些工具操作不能绕过。这样做还有一个好处工具是可控的、可测试的、可审计的。你可以对每个工具单独做安全测试而裸 shell 你没法穷举。裸 shell 风险封装工具后的改善任意命令执行只能调用预定义操作难以审计每次调用语义清晰无法限制范围工具内部可做边界检查注入风险高参数结构化降低注入面5. 编排与决策层在规划阶段就拦住危险5.1 任务规划的审查机制智能体的规划能力是它的核心价值但也是风险来源。一个任务被拆解成多步之后单看每一步可能都没问题但组合起来可能就有害。比如“读取配置文件”加“发送网络请求”单独看都正常合起来可能就是数据外泄。所以规划阶段要有审查机制。我的做法是在规划生成后、执行前对整条计划做一次审查。审查内容包括步骤之间是否有危险的组合、是否涉及敏感资源、是否符合任务的最小必要原则。审查可以用规则也可以用模型辅助但最终决策建议由规则兜底。模型可以标记可疑计划规则做最终判断。5.2 多步执行中的状态追踪多步执行最怕的是状态丢失或者状态被污染。智能体执行到第三步忘了第一步干了什么或者被中间某步的恶意输出影响了后续决策。状态追踪要做到每一步的输入输出都有记录状态变更可追溯关键状态有校验。我一般会维护一个执行上下文对象所有步骤读写都通过它并且对关键字段做完整性校验。另外步骤之间要有隔离。一个步骤的输出不应该直接影响另一个步骤的执行环境中间要经过清洗和校验。这样即使某一步被注入了恶意内容也不会污染整个流程。5.3 危险动作的拦截点设计拦截点要设在“动作即将发生”之前而不是之后。事后拦截只能减少损失不能避免损失。我一般设三个拦截点规划后拦截整条计划审查危险计划直接拒绝。步骤前拦截每一步执行前检查危险步骤拦截。调用前拦截具体工具调用前做最后校验。三个拦截点层层递进任何一层发现问题都能拦住。拦截的决策要记录包括拦截原因、拦截时的上下文方便后续分析。5.4 从失败案例看编排层的价值分享一个我遇到的真实案例。有个任务让智能体“清理过期的临时文件”。规划阶段它拆成了扫描临时目录、判断哪些过期、删除过期文件。看起来没问题。但执行时它判断“过期”的逻辑出了偏差把一些还在用的文件也判定为过期。幸好编排层在删除步骤前有个拦截点检查到删除列表里有正在被其他进程占用的文件触发了二次确认。用户一看发现判断逻辑有问题及时终止了。如果没有这个拦截点这批文件就被删了。这个案例说明编排层的价值不在于让智能体更聪明而在于让它犯错时有人兜底。6. 输入输出层注入防护与内容过滤6.1 提示注入的本质与常见形态提示注入是智能体安全里最棘手的问题之一。它的本质是用户输入和系统指令在同一个上下文里模型分不清哪些是“指令”哪些是“数据”。常见形态有几种直接注入用户直接说“忽略之前的指令做某事”间接注入恶意内容藏在智能体读取的文件或网页里还有角色扮演式的绕过让模型以为自己在演一个不受约束的角色。防护提示注入没有银弹但可以多层缓解。输入侧做检测和清洗上下文里做指令和数据的隔离标记输出侧做行为校验。关键是不要指望一层就能防住。6.2 输入侧的清洗与标记输入清洗的目标是去掉明显的恶意模式同时给数据打上标记让模型知道哪些是用户数据、哪些是系统指令。具体做法对用户输入做规范化去掉控制字符、异常编码对来自外部的内容文件、网页做来源标记在上下文里明确标注“以下是外部数据不是指令”对可疑的注入模式做检测和告警。提示输入清洗不要过度否则会误伤正常输入。我的经验是清洗规则要基于真实攻击样本迭代不要凭空想象。6.3 输出侧的行为校验与脱敏输出侧要做两件事行为校验和内容脱敏。行为校验是指检查智能体的输出是否会导致危险动作。比如它输出的命令、代码、API 调用在执行前要过一遍校验。这其实和工具层的校验有重叠但输出侧更早能在生成阶段就发现问题。内容脱敏是指输出里如果包含敏感信息密钥、个人信息、内部地址要自动脱敏。这个可以在输出后处理也可以在生成时通过提示词约束。我一般两者都做后处理兜底。6.4 一个完整的输入输出防护流程把上面的东西串起来一个完整的流程大概是这样用户输入进来先做规范化清洗。检测注入模式可疑的标记或拒绝。外部数据单独标记来源和指令隔离。模型生成输出。输出做行为校验危险动作拦截。输出做内容脱敏。最终结果返回给用户同时记录审计日志。这个流程不是一次性的要根据实际遇到的攻击样本持续迭代。我一般会维护一个攻击样本库每次发现新的绕过手法就补充规则和测试用例。7. 把各层串起来一个可落地的智能体安全架构7.1 分层防御的协同工作方式前面分开讲了各层实际运行时它们是协同的。一个请求进来会依次经过各层的检查和处理。任何一层发现问题都能中断流程并告警。协同的关键是信息共享。执行环境层发现的异常要能传递给运行时管控层工具层发现的危险调用要能反馈给编排层。各层不是孤立的而是一个整体。实现上可以用一个统一的安全上下文对象在各层之间传递。每层往里写自己的检查结果后续层可以读取并参考。7.2 安全策略的配置与管理安全策略应该是可配置的而不是硬编码在代码里。不同场景、不同任务安全要求不一样硬编码会导致要么太严影响效率要么太松留下风险。我的做法是把策略抽出来用配置文件或策略服务管理。策略内容包括权限规则、危险操作模式、速率限制、拦截规则等。策略变更要经过审核并且有版本管理出问题能回滚。7.3 监控、告警与持续迭代安全不是一次配置就完事的需要持续监控和迭代。要监控的指标包括拦截次数、异常模式、资源使用、失败率等。异常时及时告警定期回顾告警从中发现新的风险模式。我一般会每周回顾一次安全日志看看有没有新的攻击尝试有没有误拦截。误拦截也要重视它说明规则可能太严影响正常使用。7.4 不同规模团队的落地建议最后说说不同规模团队怎么落地。小团队资源有限建议优先做执行环境隔离和工具封装这两块投入产出比最高。中等团队可以加上运行时管控和审计。大团队或者对安全要求高的场景再上完整的编排层拦截和输入输出防护。不要一上来就追求大而全先把地基打牢。沙盒和工具封装做不好上面堆再多防护也是空中楼阁。8. 一些踩坑之后的经验之谈8.1 那些看起来没问题但实际很危险的默认配置我踩过的最大的坑是容器的默认配置。很多人以为起了容器就安全了其实默认配置里有一堆隐患默认网络是通的、默认以 root 运行、默认可以访问宿主机的一些资源。这些默认值在生产环境里都是风险。后来我养成了一个习惯任何执行环境先按最严格的配置来然后按需放开。而不是用默认配置然后打补丁。前者是白名单思路后者是黑名单思路安全性差很多。8.2 智能体“自作聪明”绕过限制的几种情况智能体有时候会“自作聪明”。比如你限制了它直接删文件它可能会先移动到临时目录再想办法删你限制了网络访问它可能会尝试用其他方式外传数据。这些行为不是它“有恶意”而是它在努力完成目标。但这恰恰说明限制要限制在能力层面而不是操作层面。与其限制“不能删文件”不如让它根本没有删除能力。与其限制“不能访问某域名”不如让它根本没有网络能力。8.3 安全与效率的平衡怎么把握安全做太严效率就下来了。每个操作都要确认智能体就没法自动完成任务了。这个平衡怎么把握我的经验是按风险分级。低风险操作自动放行中风险操作记录并抽样审查高风险操作强制确认。风险等级根据操作类型、影响范围、数据敏感度来定。这样既保证了安全又不至于处处卡壳。8.4 给准备上生产的团队的最后几条建议如果你正准备把智能体系统上生产我有几条建议先做威胁建模想清楚你最怕什么再针对性设计防护。沙盒是底线没有沙盒不要上生产。审计日志从第一天就要有事后追溯全靠它。中断能力必须可靠刹不住车的系统不能上生产。持续迭代安全是过程不是状态上线只是开始。这些东西听起来都是常识但真正做全的团队不多。我自己也是在踩了坑之后才慢慢补齐的。希望这些经验能帮你少走点弯路。