最近圈子里都在聊一件事AI Agent已经开始承担越来越关键的生产任务但安全防线还停留在给模型加Prompt的层面。上海AI Lab的团队公开表达过一个观点和这几年我在实际项目中踩出来的结论完全一样——Agent安全不能只靠Prompt了。这个判断不是随便说说。当一个Agent被赋予工具调用、记忆读写、代码执行这些能力之后攻击者不再需要正面攻破模型只要想办法让Agent自己干坏事就行。这篇文章我想把自己在Agent安全方向上的一些实践和理解整理出来也算是对这条技术路线的一个梳理。先说清楚这篇文章适合谁看。如果你正在做AI Agent应用开发或者你的团队正准备把Agent从Demo推向生产环境又或者你负责公司的AI安全体系规划那这篇文章值得读完。我会从Agent安全为什么不再只是Prompt工程问题讲起聊到上海AI Lab提出的新范式思路再落到一套可以实际执行的分层防护方案最后分享一些我在评估和排查过程中踩过的坑。整个过程不回避细节该给参数给参数该给代码给代码。1. Agent安全环境已经彻底变了1.1 Agent不是“更大的LLM”而是“拿着钥匙的LLM”想搞清楚Agent安全为什么难做先得把Agent和LLM的区别掰扯清楚。很多人以为DeepSeek、GPT这类模型就是Agent其实不是。这些模型是Agent的“大脑”或者说“推理引擎”但Agent本身是一个完整的行为体它由模型、工具调用、记忆系统和循环执行机制组成。我画过一张特别直白的对比表来说明这件事对比维度普通LLMAI Agent输出形式文本/代码文本工具调用指令执行行为空间受限只影响对话窗口可影响真实系统、数据、外部服务记忆能力单轮或多轮上下文短期记忆长期记忆外部知识库存在范围发生在推理服务器里横跨本地、云端、第三方API攻击面提示词注入、幻觉提示词注入工具误用记忆污染权限绕过普通LLM再强它也就是一个“会说话的模型”就算被诱导说出违规内容危害也基本停留在内容层面。Agent就不一样了它手里有钥匙——API密钥可以调邮件、支付、数据库有执行能力可以跑代码、改配置、调服务器。一个被攻破的Agent不只是输出奇怪文本它可能真的发出转账请求、真的删掉生产环境的数据。我在一个内部项目里做过一次测试给一个带邮件发送工具的Agent塞了一封“用户来信”信里藏了一段指令让Agent把通讯录转发到指定邮箱。结果Agent照做了完全没有犹豫。这个测试里我用的还是当时公认最强的模型Prompt也做了加固但一点用都没有。因为那封“用户来信”本身就是数据而模型认定“处理来信”是合法任务它怎么区分“来信内容”和“操作指令”1.2 Prompt注入已经不是“文本攻击”而是“行为劫持”早期大家讲Prompt注入举的例子都还是“绕过系统提示词”“诱导模型说漏内部指令”。这类攻击确实可以通过强化Prompt、加分隔符、做输入过滤来缓解。但现在Agent时代的Prompt注入完全变了攻击者不再需要跟模型对话他们把恶意指令藏在任何Agent会读取的数据里——网页内容、邮件正文、PDF文档、API返回的JSON字段、甚至一张图片里的OCR文字。我把这类攻击称作“行为劫持”。攻击者不关心模型说什么只在乎模型驱动的Agent做什么。这里有个很要命的问题Agent每完成一个任务可能需要读取几十个数据源只要其中一个数据源里藏了恶意指令整条链路就可能被劫持。传统的输入过滤在对话场景还勉强能应付但在Agent的数据密集体质下根本拦不过来你不可能对每个网页、每封邮件、每个API响应都做一轮提示词检验。还有一个被严重低估的入口是记忆系统。Agent的记忆是分层的有会话记忆、长期向量记忆、外部知识库。如果攻击者能在某一个低等级记忆里埋入恶意内容这个Agent后续每次任务都会读到这段“被污染的记忆”就像一台电脑的DNS被污染一样你访问哪里都会被带到钓鱼网站去。这种攻击最难防的地方在于Agent自己读取记忆是正常动作从系统视角看一切都在合法执行。2. 新范式把安全从“提示词层”搬到“行为层”2.1 上海AI Lab与行业共识Prompt加固已经到天花板上海AI Lab的团队在公开讨论里提出过一个观点大意是“Agent安全不应该只依赖模型层面的对抗而需要在系统架构层面建立行为约束机制”这个思路和目前安全圈的技术共识是一致的。很多人会问为什么不能在Prompt层面继续加码比如让模型“绝不执行任何未经授权的操作”“禁止读取可疑内容”。我试过效果非常有限原因有三层。第一模型的安全指令本质上是一段“文本建议”它没有强制性。Agent在执行任务时模型每次推理都是一次独立的决策过程系统提示词里的安全条款很难在所有上下文中保持100%的约束力。就像你给员工发了一本《安全手册》但员工在具体场景里是否遵守取决于他当时的判断而模型在复杂上下文里的判断并不稳定。第二Prompt长度和复杂度是有限制的。安全规则越写越多系统提示词越来越长模型真正执行任务时注意力会被稀释。我见过一个生产项目系统提示词里安全规则占了一半内容结果Agent在执行复杂任务时频繁“忘掉”前置规则或者为了满足安全约束而拒绝执行原本合法的操作业务没法跑了。第三针对Prompt的攻防本身就是一个“猫鼠游戏”。攻击者可以使用编码、拆词、翻译、语义混淆等方式绕过关键词过滤也可以在工具返回的合法数据里夹带指令。文本层面的对抗永远存在信息不对称防守方不可能穷举所有攻击模式。所以与其在文本层面反复加固不如直接把防线提升到行为层在Agent拥有“手”和“脚”的地方建立物理约束。2.2 行为层防护的五个核心维度新的安全范式本质上是把“让模型变安全”改成“让系统约束模型”。我从上海AI Lab相关讨论和我自己的工程经验里提炼出了五个核心维度这五个维度缺一不可权限边界Agent能访问什么数据、能调用什么工具、能执行什么级别的操作必须有明确的最小权限边界权限不是给模型看的文本而是系统层面的硬约束。工具治理每个工具调用都应该经过独立于模型推理的鉴权层。工具的参数需要校验工具的执行结果需要审计工具本身需要版本管理和下线机制。记忆隔离区分可信知识库、不可信上下文、长期记忆、短期记忆不同来源的数据在不同信任级别下处理恶意内容不能跨级污染。运行时监控对Agent的每一次行为做实时监测遇到高风险操作要有自动熔断机制不依赖模型“自觉”判断风险。可追溯审计全链路日志包括模型输入、模型推理记录、工具调用参数、执行结果出了问题能事后复盘不是黑盒。这五个维度里最关键的是第一个“权限边界”。我见过太多团队把所有防御都压在模型身上认为只要提示词写得好Agent就不会乱来。但实际上真正的安全防线应该是在Agent的模型层之外操作系统、工具层、数据层每一层都应该是独立的防护单元。2.3 Agent安全评测框架用“攻击模拟”代替“拍脑袋”范式转变的另一个重要动作是建立Agent安全评测框架。过去我们评测一个模型是否安全主要看它在面对恶意提示词时的回应质量——是否拒绝、是否道歉、是否能解释原因。但Agent的安全评测完全不能这么简单因为Agent的问题往往不是“说说而已”而是“做出来了”。我在实际评估Agent安全性时会从这几个层面去构建测试集评测层面典型测试场景通过标准输入鲁棒性恶意网页内容、恶意邮件、恶意API响应Agent不执行隐藏指令不泄露敏感信息权限合理性请求读取无关数据、调用无关工具Agent拒绝或提示越权不突破权限边界行为一致性多步任务中是否偏离原始目标Agent全程只完成用户授权范围内的操作记忆安全性记忆库中预先注入恶意内容注入内容不影响后续行为决策可解释性能否回溯判断依据和数据来源每次关键操作都有可检查的决策链这个评测框架的核心逻辑不是“测试模型有没有被骗”而是“测试系统能不能兜住底”。就算模型被骗了只要权限边界够紧工具治理够严攻击者能造成的破坏也有限。上海AI Lab提出的Agent安全评测方向用的也是类似的思路——不把模型当成唯一的防线而是把整个Agent运行环境当作被测对象。3. 实操落地给Agent配置一套分层安全方案3.1 第一步给Agent做“最小权限设计”权限设计是所有Agent安全方案的起点也是最容易出问题的地方。很多人给Agent配置权限时喜欢图省事直接把一个大而全的权限模型甩给Agent比如让Agent能访问所有数据库、所有API端点美其名曰“为了提高灵活性”。但这样做等于给攻击者铺了一条高速公路。我的建议是按照“任务最小化”原则来设计权限。具体操作是列出Agent需要完成的每一个任务然后为每个任务单独配置权限范围。比如一个“查询天气”的Agent它的权限就是“调用天气API”“读取用户所在城市信息”仅此而已。一个“客服助手”Agent它的权限可能是“读取订单状态”“发送预设回复模板”但绝不能有“修改订单金额”“删除用户数据”的权限。这里有一个很实用的做法把权限配置独立于Prompt和模型放在一个JSON配置文件里由执行环境的鉴权层去读取和强制实施。模型本身不需要也不应该知道权限的完整边界它只需要在发起某个操作时由外部系统去校验这个操作是否在授权范围内。3.2 第二步工具调用“风险分级二次确认”不是所有操作都需要审批但也绝不能所有操作都自动执行。我给Agent的工具调用分为三个风险等级低风险只读类操作如搜索、查看日历、读取公开信息。这类操作允许Agent自动执行。中风险写入类操作如发送消息、创建文档、修改配置。这类操作需要记录日志且最好通过一个确认接口交给人来确认。高风险影响类操作如删除数据、转账、修改权限、执行外部代码。这类操作必须走独立审批流程Agent只能发起申请不能直接执行。工具调用还可以增加一个“操作白名单参数校验”机制。Agent调用工具前执行环境会先检查这个工具是否在白名单里再检查传入参数是否符合预期格式任何异常都会被拦截。比如一个Agent被配置了发送邮件的权限但参数校验发现收件人Email格式不对、正文内容长度异常系统可以直接拒绝连人都不用惊动。3.3 第三步记忆系统分级隔离防止“慢性污染”前面提到记忆污染是Agent安全里非常隐蔽的问题这里讲一下具体怎么防。我采用的方法是把记忆分成三个信任级别每个级别之间禁止互相写入。第一级是“可信知识库”也就是团队维护的、经过人工审核的制度化知识这些数据优先级最高Agent可以放心引用。第二级是“上下文临时记忆”也就是当前任务会话里的内容只在这个任务周期内有效任务结束后自动清理。第三级是“外部不可信数据”比如从网页抓取的内容、陌生人发来的文件解析结果这些数据在进入Agent上下文之前要经过一道独立的“隔离层”。隔离层的具体操作是外部数据用特殊标记包裹在传递给模型之前先用一个独立的轻量模型做一次“危险指令扫描”同时给模型注入一条明确指令——被标记为“data”的内容不具有执行权限。这只是第一步真正的保障还是权限边界——就算模型被骗了外部数据里的指令也无法触发工具调用因为工具调用需要经过鉴权层。3.4 第四步全链路日志与行为审计Agent安全不能只靠事中拦截事后审计同等重要。很多Agent事故在发生时没有被发现事后追查又因为日志不完整而找不到根因。我给Agent设计的日志体系至少包含四类记录模型推理日志记录每一次模型调用的完整输入和输出包括Prompt版本信息方便复现。工具调用日志记录工具名称、调用时间、入参、出参、调用者身份哪个任务触发的。权限决策日志记录每一次权限校验的结果允许了哪些操作、拦截了哪些操作、为什么拦截。数据访问日志记录Agent读取了哪些数据源、访问了哪些文件、查询了哪些数据库表。有了这四类日志出问题时才能快速定位。我在一次真实事故排查里就是靠工具调用日志发现了异常——Agent连续调用了某个不在任务范围内的工具日志显示它是在读了某个网页内容后被诱导的这就是典型的污染链路。如果没有日志这种问题几乎没法排查。3.5 实操配置示例一个简化版的Agent安全配置文件给你一个我项目里的简化配置示例用JSON格式展示了Agent权限和安全策略的核心字段。生产环境的配置会比这个复杂很多但核心结构完全可以照搬{ agent: { name: support-assistant-v1, model: deepseek-v3, permission_boundary: { allowed_data_sources: [ internal:orders:{customer_id}, internal:ticket:read, knowledge:public_faq ], allowed_tools: [ tool:search_public, tool:read_ticket, tool:reply_template ], denied_tools: [ tool:delete_record, tool:modify_order, tool:send_email_external ] }, memory_policy: { trusted_kb: [company_faq_v3], session_memory_ttl_minutes: 30, external_data_sanitization: true, cross_level_write: false }, tool_risk_policy: { low_risk: {action: auto}, medium_risk: {action: confirm, confirm_channel: human_operator}, high_risk: {action: block} }, audit_log: { enabled: true, log_level: debug, persist_to: collection:agent_audit_2025 } } }这个文件的核心在于模型根本不知道这些规则的具体内容。它只能看到自己是“support-assistant-v1”然后按照正常逻辑推理发起操作请求时由执行环境读取配置并进行强制校验。这样的架构保证了即使模型被诱导它也没办法突破权限边界。4. 常见问题与排查技巧实录4.1 场景一明明配置了安全规则Agent还是被诱导执行了工具调用这是我在网上和线下被问得最多的一个问题。排查思路其实很简单按顺序检查三层第一层检查是否真的在“执行层”配置了安全规则还是在Prompt里写了“不要调用”就算是配置了。很多人所谓的“安全配置”全部集中在Prompt里模型一旦被骗什么配置都没用。第二层检查配置文件是否被正确加载并生效。有些框架的权限配置是静态加载的修改后需要重启Agent才能生效如果Agent一直在跑旧配置新规则自然不生效。第三层检查是否误把高风险工具放进了白名单。很多Agent事故的根因是权限给大了工具调用并不在“denied_tools”里模型行为又无法被完全控制自然就出事了。4.2 场景二Agent记忆被污染后的“慢性中毒”记忆污染是最隐蔽的Agent安全问题因为它的症状不是“立刻出事”而是Agent任务正确率逐渐下降。我排查这种问题的经验是回看Agent决策链看它最近在做判断时引用了哪些记忆片段。如果发现Agent引用了某些“来源不明”的记忆内容而这些内容跟当前任务逻辑上不相关就要高度怀疑记忆已经被污染了。修复思路是把可疑记忆数据隔离出来重建该Agent的记忆索引同时检查污染入口。如果是外部数据源被利用还要加固第三级数据的隔离策略防止再次污染。另外建议你给长期记忆加一个“可信白名单”只有通过审核的知识才能进入长期记忆库未经审核的内容最多只能活在会话级临时记忆里。4.3 场景三Agent安全评测框架怎么做很多人看了评测框架的理论之后还是不知道怎么落地。我的建议是分三步走。第一步找评测集不要自己凭空想象测试用例直接基于真实的攻击案例库和研究机构公开的Agent安全测试集来搭基础数据。第二步搭自动化测试环境把Agent放到一个隔离的沙箱环境里通过模拟工具和Mock数据来执行测试注意不要直接在真实环境上跑攻击测试。第三步把评测接入CI/CD流程Agent每次更新模型或工具配置后自动跑一遍安全评测不通过的版本不允许上线。评测标准里个人最看重“权限合理性”这一项。一个Agent如果经常请求权限之外的资源说明它的任务设计和权限配置不匹配这种Agent上线后迟早出事。4.4 我踩过的几个坑希望你避开第一个坑把安全配置埋在业务代码里。安全策略应该是显式的、可维护的不应该跟业务逻辑混在一起。我在早期一个项目里把权限校验写在了业务函数内部后来想调整权限得翻遍整个代码库每次改动都提心吊胆。现在我会把安全策略独立成配置文件修改权限只改配置不用动代码。第二个坑过于信任“模型自身的安全能力”。模型的安全对齐确实越来越强但安全对齐解决的是“模型不生成有害内容”的问题不是“Agent不执行有害操作”的问题。最典型的就是Benign Tool UsageAgent在没有任何恶意意图的情况下因为工具使用不当而对系统造成破坏。这类问题不靠权限设计和工具治理光靠模型根本防不住。第三个坑安全评测一次就完事。Agent安全是动态的攻击者在持续更新攻击方式模型的版本在升级工具集合在变化安全评测必须持续运行。我已经把Agent安全评测做成每周自动执行的例行任务任何配置变更、模型升级都会触发一轮全量回归测试。结尾做Agent安全这一年多我最大的体会是安全设计不能等着“出事再补”一定要在产品规划的早期就介入。Prompt加固仍然是好的安全实践但它是这个体系里的最后一块砖不是地基。地基应该是权限边界、工具治理、记忆隔离、运行时监控、审计日志这一整套系统级防线。最后再分享一个小技巧给Agent加一个“可解释性”按钮在每次关键操作前记录一个“决策理由”字段具体到“调用了什么工具、基于什么数据、符合哪条业务规则”。这个字段平时好像没什么用但一旦出问题它能帮你节省至少一半的排查时间。安全这东西平时没有存在感才是最大的成功可万一出了事每一份记录都会变成保命符。
