1. 多Agent协同系统的风险本质
当多个智能体（Agent）开始协同工作时，系统复杂度会呈指数级增长。我在实际项目中见过最典型的案例是：一个看似简单的客服工单处理系统，当引入5个不同功能的Agent后，安全事件响应时间从原来的2小时激增到3天。这不是因为防护措施变弱了，而是攻击路径变得难以追踪。
多Agent系统的风险核心在于三个叠加效应：
- 角色叠加：调度、执行、审计等不同职能Agent同时运作
- 状态叠加：短期上下文、长期记忆、外部知识库并行影响决策
- 权限叠加：凭证共享和权限继承形成的隐式通道
这三个叠加效应使得传统的单点防护完全失效。去年我们团队处理过一个典型案例：攻击者通过修改检索Agent返回的JSON格式说明（看似无害的格式调整），最终导致执行Agent误删生产数据库。整个攻击链涉及4个Agent的11次消息传递，常规的输入检测完全无法发现。
2. 威胁建模的四重边界定义
很多团队一上来就急着找漏洞，这完全是本末倒置。我们首先需要明确系统的"作战地图"——也就是四个关键边界：
2.1 任务边界
在电商客服系统中，我们明确规定：
- 订单查询Agent只能处理3个月内的记录
- 退货Agent不得修改支付信息
- 促销Agent不能访问用户身份证号
这些限制必须写成机器可读的策略语言，例如：
{ "agent": "refund_handler", "forbidden_actions": ["payment_modify"], "data_access": { "user_info": "masked", "payment_details": "deny" } }2.2 数据边界
我们采用数据标签化分级：
- P0（核心资产）：支付凭证、生物特征
- P1（敏感数据）：地址、联系方式
- P2（业务数据）：订单记录、浏览历史
- P3（公开数据）：商品描述、评价内容
每个Agent的数据访问权限必须精确到字段级。曾经有个物流Agent因为能读取完整的用户地址，被攻击者利用来构建用户画像库。
2.3 工具边界
在金融场景中，我们给不同Agent的工具调用设置熔断机制：
- 风控Agent：每5分钟最多调用1次征信接口
- 支付Agent：单日转账金额不超过5000元
- 客服Agent：禁止直接执行SQL语句
2.4 权限边界
我们设计了三层权限沙箱：
- 基础层：仅读取权限
- 操作层：可调用特定API
- 特权层：需要人工二次确认
3. 六类核心资产识别方法
3.1 动态资产清单
我们开发了实时资产图谱工具，可以自动发现Agent系统中的关键资产：
| 资产类型 | 识别方法 | 保护措施 |
|---|---|---|
| 任务目标 | 解析工作流定义文件 | 数字签名+版本控制 |
| 身份凭证 | 监控凭证缓存区 | 自动轮换+使用审计 |
| 敏感数据 | 数据流追踪 | 动态脱敏+最小化暴露 |
| 工具权限 | 分析API调用日志 | 熔断机制+异常检测 |
| 中间状态 | 上下文存储分析 | 加密存储+完整性校验 |
| 审计记录 | 日志系统元数据分析 | 防篡改设计+多副本存储 |
3.2 信任边界绘制
我们使用可视化工具绘制信任边界图，不同颜色代表不同信任等级：
- 红色边界：用户直接输入
- 黄色边界：Agent间通信
- 绿色边界：内部知识库
- 蓝色边界：第三方服务调用
4. 角色模型与权限继承风险
4.1 五类核心角色防护
在医疗问诊系统中，我们这样设计角色隔离：
调度Agent：
- 只能转发不能修改消息
- 消息大小限制在1KB以内
- 必须携带数字签名
执行Agent：
- 操作前必须验证任务哈希
- 关键操作需要延迟执行
- 结果输出前做敏感性扫描
验证Agent：
- 独立运行环境
- 黑白名单双校验机制
- 决策过程可解释性输出
4.2 权限继承控制
我们采用"染色法"跟踪权限流转：
class PermissionTracker: def __init__(self): self.tag_stack = [] def add_tag(self, source, permission): tag = f"{source}:{permission}:{time.time()}" self.tag_stack.append(tag) def check_permission(self, target_action): current_tags = self.get_current_tags() return Validator.validate(target_action, current_tags)5. 三层攻击面防御体系
5.1 入口层检测
我们在所有输入点部署异构检测引擎：
- 语法分析器：检测异常结构
- 语义校验器：识别矛盾陈述
- 意图分析器：评估请求合理性
5.2 传播层监控
采用消息染色技术，每个Agent处理后的消息都会携带处理轨迹：
原始输入 -> [ParserAgent] -> [ValidatorAgent] -> [ExecutorAgent] (添加签名) (附加校验结果) (记录执行环境)5.3 执行层防护
关键操作实施"慢动作"机制：
- 预演阶段：模拟执行并评估影响
- 确认阶段：生成人类可读说明
- 执行阶段：限制速率并监控资源
6. 五跳传播阻断实践
在电商推荐系统项目中，我们这样阻断恶意传播：
载荷进入：用户评论中的隐藏指令
- 防御：输入规范化+意图分析
调度复述：被摘要成看似合理的任务
- 防御：保留原始输入指纹
执行采信：触发商品价格修改
- 防御：操作前价格波动检查
工具调用：调用库存API
- 防御：API调用频率限制
结果回写：污染商品数据
- 防御：写入前差异比对
7. 记忆污染防护方案
7.1 三层过滤机制
写入过滤：
- 来源验证
- 异常模式检测
- 上下文一致性检查
存储管理：
- 版本快照
- 生存时间(TTL)
- 冷热分离
召回验证：
- 使用场景校验
- 敏感性重评估
- 动态脱敏
7.2 缓存治理
我们设计了缓存消毒策略：
- 元数据标记：记录缓存来源和用途
- 动态过期：根据敏感度调整TTL
- 访问监控：异常模式实时告警
8. 工具调用防护实践
在IT运维系统中，我们实施以下控制：
8.1 调用前检查
def pre_check(tool_call): validate_signature(tool_call.request) check_rate_limit(tool_call.source) verify_parameter_schema(tool_call.params) assess_impact(tool_call.target)8.2 调用后验证
- 结果真实性验证
- 输出敏感性扫描
- 操作影响评估
9. 数据外泄防护体系
9.1 数据流追踪
我们开发了轻量级数据标记方案：
message DataTag { string origin = 1; // 数据来源 repeated string handlers = 2; // 经手Agent列表 uint32 sensitivity = 3; // 敏感等级 bytes integrity_hash = 4; // 完整性校验值 }9.2 动态脱敏策略
根据上下文智能调整脱敏程度：
- 内部处理：保留完整数据
- 跨Agent传递：部分字段脱敏
- 最终输出：深度脱敏
10. 指令优先级实现方案
我们开发了约束求解模块，工作流程如下：
策略加载：
class PolicyEngine: def __init__(self): self.policies = { 'ORG': load_org_policies(), 'TASK': parse_task_constraints(), 'USER': get_user_preferences() }冲突检测：
def detect_conflict(self, action): for level in ['ORG', 'TASK', 'USER']: if not self.check_compliance(action, level): return level return None裁决执行：
- 组织策略优先
- 任务约束次之
- 用户偏好最后
在实际项目中，这套机制成功拦截了92%的越权操作尝试，同时保证了业务流畅性。关键是要建立持续优化的策略库，我们每月都会更新策略规则以应对新的攻击模式。
