理念确立之后,方法至关重要。智能体的安全防御不能再依赖于单点工具,而必须贯穿其行为链条。本文从一线工程防御视角出发,将抽象风险分解为输入、依赖、权限、通信等多个具体战场,并逐一给出了清晰、可落地的防护方案与设计原则。这是一份面向高校信息化管理者的、扎实的智能体安全防御实战手册。
随着大模型能力的不断提升,AI Agent(AI智能体)正从之前的问答工具变成一个真正意义上的运行系统。它能自主规划任务、调用工具、访问数据库、触发外部API,甚至与其他智能体协作。这种能力的跃升带来了一个不可回避的问题:高校传统的安全思路根本跟不上。
过去,高校防的是“输入是否合法”—过滤敏感词、校验格式、做权限控制。但智能体的行为不是开发者写死的,而是模型在运行时动态生成的。输入来源不再局限于用户一人,而可能来自网页、数据库、第三方的API或者是插件,输出也可能直接变成一封邮件、一条SQL、一段被执行的代码。这代表着对智能体安全的防线从单一的输入口,变成了贯穿整个执行链的每一个节点。
四类高发风险
在落地的工程实践中,智能体的安全问题很少是由单一漏洞引起的。更常见的情况是多个维度的失控同时发生、相互放大,最终造成真实影响。几位谷歌DeepMind研究员在近期发布的论文《AI Agent Traps》中,把“互联网如何攻击AI Agent”进行了系统分类,参考该论文中针对AI Agent攻击面的完整分类框架,本文总结出了工程实践中智能体最容易出问题的四个方向。
1.敏感信息外泄风险
智能体处理的内容不只是用户说的话。网页抓取、RAG检索、API返回中,外部数据都会进入模型的推理上下文,而这些内容往往没有经过充分验证就被纳入推理过程。
攻击者可以在网页里埋一句指令,让智能体忽略之前所有规则并输出系统配置,而智能体读到之后可能照单全收。不仅如此,模型自己有时也会“过度回答”,如在没有受到任何攻击的情况下,把不该说的东西说出来。这并非模型问题,而是系统设计时没有设定明确的输出边界。
2.供应链风险
智能体对插件、第三方API和外部数据源具有强依赖性。部分组件虽然扩展了智能体的能力,但也引入了不确定性。一个有漏洞的工具、一个权限过大的API、一份被污染的RAG数据源都可能成为攻击的入口。
在多智能体协同的场景下,此类风险还可能在系统内部传播。而当一个智能体的上下文被污染,便有可能会成为下一个智能体的输入。传导的链条越长,产生的问题也越难追根溯源。
3.权限边界失控风险
智能体的价值核心在于其具备自主的执行能力,但自主执行往往也是最危险的环节。许多系统在初始化时就授予了智能体数据库读写、API调用、代码执行等极高的权限,一旦推理出现偏差,或者受到提示词注入干扰,就可能触发高风险的操作。
从用户“查一条记录”的指令到最后智能体“删整张表”的输出行为,中间可能只差一个被注入的恶意指令。问题不在于攻击多复杂,而在于系统缺乏对权限的分级与约束,最终导致低风险甚至是正常输入触发高风险的行为。
4.安全事件难定位风险
智能体的决策是多步骤的、动态的。如果没有完整的行为记录和调用链追踪,出现问题往往难以定位原因。是输入被污染?模型推理出现偏差?还是某个工具调用返回了异常数据?排查成本极高,且影响后续的策略优化。
针对智能体的典型攻击场景
随着AI智能体能力的增强,其攻击面也相应扩大。智能体不仅继承了大语言模型自身的漏洞,也因与外部环境频繁交互而暴露出新的攻击路径。攻击者通常不会直接攻击模型本身,而是利用其与外界交互的链路。参考OWASP 2026年发布的智能体十大安全风险,开发中需重点关注以下几类攻击场景:
首先,提示词注入是核心攻击手段之一。攻击者可通过操控输入,包括用户对话、网页内容或工具返回结果,来篡改智能体的原有目标,诱导其执行恶意指令。其中,间接注入尤为隐蔽,如将恶意指令隐藏在外部数据源中,模型难以区分内容与指令,极易被诱导执行不当行为。
其次,工具滥用与代码注入同样危险。若智能体集成了Python、Shell等执行工具,攻击者可通过注入提示词或污染上下文,诱导模型生成恶意代码并直接执行。此类攻击往往表现为“正常任务执行”,难以被常规防御机制察觉。
第三,过度代理权风险源于系统赋予智能体较高权限却缺乏有效约束。智能体自主规划执行的过程中,往往只优化表面目标,却难以理解隐含的约束条件,最终引发非意图的破坏行为。此外,推理链中的逻辑偏差也可能在多次迭代中被不断放大,导致决策严重偏离初衷。
最后,智能体间通信被劫持是另一维度的高危场景。在多智能体系统中,若通信链路缺乏加密、身份认证与完整性校验,攻击者便能窃听、篡改或伪造消息,实施中间人攻击或重放攻击,误导下游智能体执行非法操作,甚至造成系统性数据泄露。
这些风险表明,智能体的安全防护必须覆盖从输入、工具调用、权限控制到通信链路的全流程,建立起系统性的安全约束与监测机制。
工程视角的防御思路
对于智能体的安全防护不是堆砌规则或使用某一单一组件就能解决的。真正有效的防御需要贯穿整条执行链—从输入、到权限控制、到工具调用、到智能体间通信,再到最后的行为审计,在系统层面构建一整套可控执行的防御体系,确保智能体的行为始终在可约束、可解释的范围内。
1.输入端:阻断恶意输入,不盲信外部内容
对输入进行分层处理。在实际运行的系统中,用户输入、系统指令、外部数据三类内容的可信等级应是完全不同的。系统指令属于最高优先级的控制信息,应保持稳定且不允许被覆盖;用户输入则属于业务请求,响应要经过校验;类似于网页内容、数据库结果和第三方接口返回值等外部数据则应视为低信任输入,在进入推理流程之前进行额外处理:进行内容清洗和来源校验,可疑内容则打标或直接拦截。
重视系统提示词的结构设计。应将指令区和数据区明确区分,让模型清楚哪些内容是行为约束,哪些只是参考信息,降低模型把外部数据当成指令执行的概率。在输出侧,因模型存在过度回答的倾向,易在上下文中补充超出授权范围的信息,因此需增加对输出内容的控制:敏感字段脱敏、高风险内容过滤、内部标识隐藏等,避免模型随意补充导致信息泄露。
2.治理外部依赖:约束组件,防范供应链风险
在治理外部依赖时,需增加“只接入可信组件”“只开放必要”的能力。所有插件、API、数据源都应建立准入机制,只允许通过安全评估的组件接入生产环境,并明确每个组件的用途、权限范围、数据访问边界和风险等级,未通过安全审计的组件不得上线使用。
对于RAG数据源,应对数据内容进行定期巡检,检查是否有异常内容、失真信息、诱导文本或异常更新。同时,要保留版本记录和来源记录,一旦发现问题则快速溯源并定位污染源。
对于工具接口也应分级管理,普通的查询类工具可以自动调用,而一旦涉及写入、删除、对外发送或更改系统配置等高风险能力时应增加额外的校验流程或二次人工确认,绝不可依赖模型的自主判断。
3.权限控制:管控权限边界,按需授权
遵循最小权限原则,智能体启动时不应拿到全部权限,而是根据任务内容动态申请所需权限。任务需要什么,就申请什么,任务结束即回收权限。同时,应严格控制给予权限的程度,如访问数据库时限制到特定表、特定字段;访问文件系统时限制目录范围;对外部接口的调用则需限制频次与目标地址,通过细粒度的授权将潜在的损害控制在最小范围内。
应将复杂任务拆成多个步骤,每个关键节点都进行校验,而不是一次性把控制权全交给智能体。在执行前要先自检:智能体在触发操作前先自我评估当前操作是否偏离了原始目标、是否涉及敏感资源以及是否存在异常上下文,若有异常则暂停执行并请求人工确认。
4.通信安全:加密和认证,阻断链路攻击
智能体间通信应默认走加密通道,如HTTPS或TLS,这并非可选项,而是底线要求。每个智能体都应有唯一身份标识,通信前进行双向验证。并非所有内部组件都可互相调用,而应基于授权来建立连接,同时明确限定可访问的对象以及调用范围。
消息层面需要增加唯一ID和时间戳,使用签名或哈希做完整性校验,以验证消息是否被篡改、是否超时或者重复发送。若识别到被篡改的内容则立即拒绝执行,对于重复ID的消息应直接丢弃,以此来防御中间人攻击与重放攻击。
5.审计与溯源:让行为“可见、可查、可复盘”
智能体的每一个关键动作都应被保留记录,包括输入来源、模型输出、工具调用、权限申请、执行结果以及异常中断原因。这些日志并非只用于排查问题,也是理解系统行为模式、发现潜在异常的基础。日志本身应有完善的防篡改和加密存储能力,避免关键证据在最需要的时候丢失。
当日志积累到一定程度,可进一步建立行为基线。随后,系统即可知晓某类智能体在正常情况下如何决策、会调用哪些工具、执行路径一般多长;一旦其出现异常模式,比如在非预期场景中调用了高权限工具,或执行路径明显偏离目标、频繁访问敏感资源,就应实时警告,必要时自动终止执行。
总结
总结而言,智能体安全应该围绕“决策是否可信、执行是否受控、行为是否可追溯”进行全链路的控制:输入要过滤、外部依赖要管控、实现细粒度权限分级、建立安全通信机制以及全链路的审计溯源。只有将这些能力嵌入智能体运行的全过程,才能让系统在复杂的环境中保持稳定可控。
作者:刘金阳 杨望(东南大学网络空间安全学院)