1. Agent 的记忆层为什么突然成了安全焦点
接触过 LangGraph 的人应该都有印象：它把 Agent 的整个状态流转管理得明明白白，节点、边、状态快照、持久化，一套组合拳下来，多轮对话和断点续跑都变得很自然。但很多人把注意力全放在 Prompt 注入、工具权限、模型幻觉这些地方，恰恰忽略了最底层的那层存储——也就是 Checkpointer。简单说，Checkpointer 是 LangGraph 里负责把状态快照持久化下来的组件，Agent 跑一步，它存一步；下次恢复时，再从某个时间点把状态捞回来。记忆、会话历史、中间变量、甚至是用户输入的原始消息，全都经过这一层。这个位置一旦出问题，攻击者看到的就不再是某个节点能不能被诱导，而是整个 Agent 的记忆层都暴露在面前。安全圈有句话叫“存储即攻击面”，放在这里再合适不过。
这次要聊的问题，是 LangGraph Checkpointer 在特定配置下，把 SQL 注入、msgpack 反序列化、最终代码执行三个洞串成了一条链。你可以把它理解成：攻击者先找到一个能往 SQL 语句里塞东西的入口，然后让数据库返回一段精心构造过的 msgpack 数据，再靠反序列化过程里隐含的行为触发代码执行。三个洞单个看都能修复，但组合在一起，就成了一个从存储层直接打到 RCE 的完整武器。这个过程不是纯理论，在很多真实项目里，因为开发默认“记忆层就是内部数据”，反而更容易放松警惕。
为什么记忆层会成为攻击面？一个很直接的原因是：它保存的东西太全了。用户输入、系统消息、工具返回值、中间状态、序列化后的 payload，全都在里面。更关键的是，Checkpointer 的数据既要写进去又要读出来，读写过程中会经过 SQL 语句拼接、数据反序列化、对象恢复等环节。只要任何一个环节存在信任边界模糊的问题，攻击者就能把“看起来只是普通聊天记录”的内容，变成真正可执行的恶意东西。这就好比你把存档文件直接暴露给玩家，玩家改一个数值，游戏角色就无敌了；如果存档解析器本身还有漏洞，玩家甚至能让游戏进程执行任意代码。
我见过不少团队做 Agent 安全评审时，针对 Prompt 注入做了各种拦截，却对 Checkpointer 的存储操作不做任何审计。一问原因，回答基本是“数据都是我们自己序列化的，不会有问题”。这种默认信任，往往就是问题最开始的地方。这篇内容我会把漏洞链路拆开，聊清楚入口在哪、载荷怎么构造、为什么最终能 RCE，再给出实际可用的复现和加固方案。无论你是 LangGraph 的用户、自研 Agent 框架的开发者，还是安全工程师，都应该把这条链路放进自己的威胁模型里。
2. 三个漏洞逐一定位：从 SQL 注入入口到 msgpack 反序列化出口
整条攻击链能成立，靠的是三个漏洞的串联。分开看，每个都是很经典的问题；合在一起，才构成了从存储层打到命令执行的完整路径。先把三个洞逐个说清楚。
2.1 第一洞：SQL 注入入口，构造查询位置
LangGraph Checkpointer 支持多种持久化后端，常见的有 SQLite、PostgreSQL 等。在实现里，保存状态和恢复状态通常都会涉及对thread_id、checkpoint_id这类字段的查询。问题出在哪里？如果框架或业务方在自定义 Checkpointer 时使用了字符串拼接的方式来构造 SQL，那么这些从外部消息、请求头、元数据里带入的字段，就可能直接变成 SQL 语句的一部分。
用一段伪代码来说明这个问题的典型形态：
def get_checkpoint(thread_id: str): query = f"SELECT payload FROM checkpoints WHERE thread_id = '{thread_id}' LIMIT 1" cursor.execute(query) row = cursor.fetchone() return row这段代码里，thread_id如果来自用户可控的输入，且没有做参数化处理，那么一个类似' OR '1'='1的输入就能改写查询逻辑。更危险的是，在某些数据库配置里，SQL 注入还能用来执行 UNION 查询、写文件、调用数据库扩展函数。对于 Checkpointer 来说，注入点往往不是 Web 层那个经典的登录框，而是 Agent 的会话恢复接口、任务续跑接口、或者消息队列里携带的元数据字段。
可能有人会问：LangGraph 官方不是已经做好了参数化吗？没错，官方内置的 Checkpointer 实现是走参数化查询的。但问题是，很多项目会为了扩展而重写、包装 Checkpointer，或者在官方实现外层再加一层自定义的查询逻辑。比如为了兼容旧系统，用自己的数据访问层去接管 checkpoint 存储，这时候就很容易把参数校验和 SQL 语句构造混在一起。我在代码评审里见过不止一次类似写法，有些甚至直接把前端传过来的thread_id当作表名或字段名的一部分去拼接，这种就属于给攻击者开了一扇大门。
2.2 第二洞：msgpack 不透明序列化载荷
SQL 注入之后，能拿到什么？这就要说到 LangGraph Checkpointer 的一个实现细节：状态数据在存储时，并不是直接存 Python 对象，而是先序列化成一种二进制格式，其中常见的就是 msgpack。msgpack 是一种高效的二进制序列化协议，类似 JSON 但是更紧凑，支持嵌套结构、二进制字符串、扩展类型，性能也更好。Agent 的状态里如果有自定义对象，还会配合 pickle 或自定义 hook 一起处理。
msgpack 本身只是数据格式，本身不“危险”。但问题在于它的扩展类型（ext type）机制。序列化方可以写入任意扩展类型 ID 和对应的二进制内容，反序列化方则需要根据扩展类型 ID 决定如何处理这段二进制。如果处理逻辑里存在“把这个二进制反序列化成某个 Python 对象并执行某些方法”的代码，那攻击者就可以通过构造特殊的 msgpack 载荷来触发这些行为。这跟经典的 pickle 反序列化攻击在原理上有相似之处，但因为 msgpack 看起来更像“数据”而非“代码”，很多人在排查时根本不会往那方面想。
还有个关键点：msgpack 对很多人来说是不透明的。你用msgpack.packb()打出来的东西，肉眼看不到结构；用msgpack.unpackb()读回来，也只是一个普通的嵌套字典和列表。于是安全审计时就容易跳过它。攻击者恰恰喜欢这种“没人看”的角落，因为他们知道，越是看起来像随机字节的数据，越容易逃过人工审查和简单的规则检测。
2.3 第三洞：反序列化后置处理或写操作导致的 RCE
SQL 注入拿到的是数据库里的数据，这些数据在正常情况下是 Agent 自己存进去的序列化状态。但攻击者如果先通过 SQL 注入写入或者修改了一条 checkpoint 记录，把原本合法的 msgpack 载荷替换成恶意构造的版本，那后续所有恢复该 checkpoint 的请求都会把这个恶意载荷反序列化出来。
反序列化本身不等于命令执行，关键在于反序列化之后框架做了什么。LangGraph Checkpointer 恢复状态时，会把 payload 解析成完整的状态快照，然后用于恢复图执行。某些自定义实现为了兼容旧版本，会注册自定义消息类型；还有一些扩展会动态加载状态中引用的类或模块。如果这些过程中存在对扩展类型数据的无条件信任，那恶意载荷里指定的“类名”和“参数”就可能被实例化、方法被调用，甚至通过危险函数执行系统命令。
我用一个更生活的类比来解释这条链：你把一个存档文件交给游戏程序加载，游戏程序不仅读了存档数据，还会根据存档里的“mod 插件 ID”去加载对应的 mod 脚本。正常情况下，mod ID 是合法的；但如果攻击者能通过某种方式改掉存档里的 mod ID，让它指向一个恶意的“插件”，那游戏加载存档时就会执行这个恶意插件里的代码。Checkpointer 的恢复过程就类似这个“加载存档”，而 msgpack 扩展类型就是那个“mod ID”。
因此，第三个洞的本质不是 msgpack 反序列化“本身危险”，而是“反序列化后处理流程”里缺少对可信来源的验证，错误地把载荷中未受信的内容当成了可执行配置。前两个洞负责把攻击者带进存储层，第三个洞负责把存储层的数据变成真正的权限落地。
3. 完整攻击链推演：攻击者如何从一条 SQL 注入打到 RCE
把三个洞串起来，完整的攻击链其实是一条非常清晰的路径。先明确攻击者能够控制的输入面，再看每一步如何衔接。
3.1 攻击前提和初始暴露面
攻击链要成立，需要满足几个前提条件。第一，Checkpointer 使用的数据库查询存在 SQL 注入点，且该注入点是可通过外部输入触达的。这个外部输入不一定是 HTTP 请求参数，也可能是消息队列的消息头、文件导入的字段、甚至别的 Agent 节点的输出。第二，数据库用户具备读和写 checkpoint 表的权限。很多部署为了省事，直接用最高权限账号连接数据库，这会让攻击者更轻松。第三，反序列化恢复的代码路径存在对 msgpack 扩展类型的“不安全解析”，比如自动加载模块、实例化类、调用可执行方法。
这三个前提在真实环境里并不是罕见配置。尤其是很多 Agent 项目还处于原型验证阶段，数据库权限不收敛、接口不做鉴权、反序列化直接沿用老代码，比比皆是。攻击者的初始暴露面，就是 Agent 暴露出来的会话恢复或任务续跑接口，往往只需要一个合法的会话 ID，甚至连鉴权都不需要。
3.2 逐步构造：从注入点到 msgpack 载荷
攻击流程第一步，探测 SQL 注入点。假设有一个恢复会话的接口，参数是thread_id。攻击者先输入一个单引号，如果接口返回数据库错误，说明语句可能被拼接过。再输入' OR '1'='1' --，如果恢复了不是自己创建的那个会话状态，就基本确认注入存在。
第二步，利用注入点读取当前 checkpoint 表的结构和数据。攻击者可以用UNION SELECT把数据逐个字段拖出来，也可以利用报错信息带出数据内容。关键目标有两个：一是了解当前 checkpoint 的 payload 列存储的 msgpack 结构，二是确认数据库写入权限。很多情况下，攻击者不需要完整理解 payload 的所有字段，只需要拿到一条合法记录的二进制内容，然后复制下来做修改。
第三步，构造恶意 msgpack 载荷。这一步需要攻击者对目标 Agent 的反序列化处理逻辑有一定了解。最理想的情况是：目标使用了一个已知的、存在反序列化 gadget 的扩展类型，比如某个自定义消息类型在恢复时会调用os.system或subprocess.Popen。攻击者将原本合法载荷里的某个扩展类型值替换为恶意对象，再重新打包成 msgpack 二进制。
第四步，通过 SQL 注入把恶意载荷写回数据库。可以是一条UPDATE语句，把某个 checkpoint 的payload更新为新构造的恶意数据，也可以是INSERT一条新的高权限会话记录。关键在于，更新后的记录必须能通过后续的反序列化流程，且能影响某个正在进行的 Agent 会话。
3.3 执行与影响范围
当攻击者完成载荷覆盖后，接下来要做的就是等待触发。受害者恢复会话、管理员查看历史会话、定时任务加载状态，任何一个会触发该 checkpoint 恢复的操作，都会把恶意 msgpack 解析出来，进而进入反序列化后处理逻辑，最终执行攻击者预设的命令。
在实践测试中，这种攻击的影响范围通常取决于 Agent 运行进程的权限。如果 Agent 服务是 root 或管理员权限运行，RCE 后直接拿到整台机器的控制权；如果运行在容器里，且容器配置过共享宿主机 Docker Socket 或挂载了敏感目录，还能进一步逃逸到宿主机。即使权限收敛，攻击者也可以通过 Agent 进程掌握的 API Key、数据库凭据、内部服务地址做横向移动。
需要特别强调一点：这个攻击链里最容易被忽略的环节，是“SQL 注入写数据”和“反序列化触发”之间的时间差。攻击者可能在一个月前就把恶意载荷写进了数据库，一个月后才被某个定时任务自动恢复时触发。传统入侵检测通常只关注请求阶段的异常，对于潜伏在存储层的数据却很难发现。这也是为什么记忆层攻击面比想象中更隐蔽、更危险。
4. 复现与验证：自己搭一个最小 PoC 环境
聊理论总是有点飘，我建议你自己动手搭一个最小环境，把这条链跑通，感受一下每个环节是怎么衔接的。下面是我实际测试时用的方案，所有内容都在本地 Docker 环境里完成。
4.1 最小环境准备
我在本地用 Docker 起了两个容器，一个跑 PostgreSQL，一个跑 Python 应用。Python 版本 3.11，依赖装langgraph、psycopg2-binary、msgpack、flask。为了模拟真实业务里“自定义 Checkpointer”的场景，我写了一个简化的恢复接口，故意使用字符串拼接构造 SQL，并注册了一个危险的 msgpack 扩展类型。
提醒：所有复现操作请限定在本地或授权测试环境。不要对未授权目标执行任何类似测试，安全研究和破坏性行为之间有明确界限。
Docker Compose 的简化配置大概是这样的：
version: "3.9" services: db: image: postgres:15 environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: agent_store ports: - "5432:5432" app: build: . ports: - "8000:8000" depends_on: - db应用的数据库初始化脚本里，我建了一张checkpoints表，字段包括thread_id、payload、created_at，其中payload用BYTEA类型存储 msgpack 序列化后的二进制。
4.2 复现 SQL 注入触发点
应用里我写了两个接口。一个是正常的保存状态接口/save，入参是thread_id和state；另一个是模拟的恢复接口/load，入参是thread_id。/load接口的代码长这样：
@app.route("/load") def load_checkpoint(): thread_id = request.args.get("thread_id") query = f"SELECT payload FROM checkpoints WHERE thread_id = '{thread_id}' LIMIT 1" cur.execute(query) row = cur.fetchone() if row is None: return {"error": "not found"} payload = msgpack.unpackb(row[0], ext_hook=ext_hook) return {"state": payload}正常情况下，访问/load?thread_id=abc能拿到对应状态。但访问/load?thread_id=abc' OR '1'='1' --时，因为拼接了恶意条件，查询会返回表里的第一行数据。这就是典型的 SQL 注入触发点。
利用这个注入点，攻击者还可以执行UNION SELECT来构造任意返回内容，甚至可以执行UPDATE语句把恶意数据写进去。在 PostgreSQL 下，如果当前数据库用户有写入权限，直接构造一个嵌套的子查询就能完成写入：
/load?thread_id=abc' ; UPDATE checkpoints SET payload = CAST('...' AS BYTEA) WHERE thread_id = 'victim' --4.3 构造 msgpack 载荷并触发反序列化
接下来是构造恶意 msgpack 载荷。为了让反序列化过程产生命令执行效果，我在 ext_hook 里注册了扩展类型 ID 88，对应的处理函数是这样的：
class EvilMessage: def __init__(self, command): self.command = command def ext_hook(code, data): if code == 88: obj = pickle.loads(data) if isinstance(obj, EvilMessage): os.system(obj.command) return obj return msgpack.ExtType(code, data)攻击者构造载荷时，只需要生成一个包含EvilMessage实例的 msgpack 二进制：
import msgpack import pickle class EvilMessage: def __init__(self, command): self.command = command evil = EvilMessage("touch /tmp/pwned") payload = msgpack.packb( {"type": "checkpoint", "data": msgpack.ExtType(88, pickle.dumps(evil))}, use_bin_type=True )把这段二进制写入数据库对应的 record，然后用/load?thread_id=victim触发恢复。只要反序列化走到 ext_hook，就会实例化EvilMessage并执行os.system命令。我在本地测试时，在容器里执行touch /tmp/pwned，随后在宿主机docker exec查看文件确实生成了。
4.4 验证 RCE 与排查记录
命令执行成功后，可以通过各种方式进一步验证权限边界。我建议你至少做三件事：第一，执行id、whoami、env看进程身份和环境变量；第二，检查数据库连接字符串、API Key 等敏感信息是否可读；第三，尝试访问内网其他服务，确认是否存在横向移动的可能。
排查时要注意：这类攻击在日志里留下的痕迹非常少。SQL 注入的 URL 可能被 WAF 记录，但如果攻击者用的是 POST 请求或者走了消息队列，日志就不一定覆盖。msgpack 载荷写入数据库后，本质上是二进制数据，常规日志系统不会打印完整内容。所以如果怀疑被打了，重点要查数据库表的变更记录和 Agent 服务的进程行为，而不是只翻访问日志。
5. 为什么这块容易被忽略：记忆层安全的三个认知误区
技术细节聊完了，想再展开讲讲为什么这么多团队会漏掉这类问题。不只是因为代码写得不严谨，更深层的原因是对“记忆层到底算不算攻击面”存在认知偏差。我总结了三个最常见的误区。
5.1 误区一：以为 SQL 注入是传统 Web 问题，跟 Agent 无关
很多人一听到 SQL 注入，脑子里浮现的是十几年前的登录框和 URL 参数，觉得现在框架都自带了 ORM 和参数化查询，这个问题早该绝迹了。但在 Agent 场景里，SQL 注入的入口早就不是传统 Web 页面了，而是各种看似无害的元数据字段。比如从消息队列消费的事件里带了一个session_id，或者从上游服务的回调请求里带了一个user_id，这些字段如果直接被拼接到存储层的查询里，就会产生注入。
更重要的是，Agent 系统的数据流是图式流转的。一个节点的输出会变成另一个节点的输入，节点之间的状态传递往往经过 Checkpointer。攻击者不一定直接打存储接口，他可能先诱导模型生成一个包含恶意字段的回复，再由后续节点把它写入存储。这种间接的数据通路，在传统 Web 安全里并不常见，所以安全团队很难用传统手段去审计。
5.2 误区二：以为反序列化必须要有 eval/exec，忽略了数据格式解析时的隐式行为
反序列化漏洞最迷惑人的地方在于，它不需要出现eval或exec这类显眼的危险函数。以 msgpack 为例，解析过程看起来就是把字节变成字典，但如果扩展类型处理函数里注册了类加载、方法调用或者文件操作，攻击者就能在没有eval的情况下实现相同效果。pickle反序列化也是一样的原理，它会在加载数据时隐式调用__reduce__、__setstate__等方法，这些方法内部可能携带危险操作。
在实际代码评审中，我发现很多开发者对“不安全反序列化”的理解还停留在“代码里出现了pickle.loads”这个层面。看到msgpack.unpackb就觉得安全，因为“它只是解析数据格式”。这种认知会直接导致安全审计盲区。判断反序列化是否危险，不能只看格式名称，要看解析之后有没有隐式行为、有没有扩展 hook、有没有根据载荷内容动态加载类或模块。
5.3 误区三：以为记忆层数据是“自己人”写的，不会成为攻击输入
这个误区是最致命的。很多团队认为 Checkpointer 存储的内容都是 Agent 自己序列化后写入的，格式固定、来源可信，所以没必要把存储数据当作不可信输入来处理。但现实是，记忆层的数据来源非常复杂：一部分来自模型输出，一部分来自外部工具返回值，还有一部分来自用户消息。模型输出可以被注入攻击诱导，工具返回值可能被上游恶意服务控制，用户消息更是天然的不可信输入。
一旦某个环节的数据被污染，污染后的数据会经 Checkpointer 持久化，并在后续会话恢复时被反序列化。这个时候，数据已经不是“自己人”了，而是攻击者精心构造的恶意载荷。安全界常说“永远不要信任序列化数据”，在这里应该扩展成“永远不要信任记忆层数据”。不管数据是怎么进来的，存储层在解析它的时候都必须当作不可信输入处理。
6. 修复与加固：从三个漏洞分别入手
针对上面这条攻击链，修复不能只靠一个补丁，因为三个漏洞分布在不同的代码层，每一层都需要单独加固。下面是我建议的修复方案，按漏洞点逐一展开。
6.1 入口加固：参数化查询与输入约束
第一洞的修复最直接：所有涉及 Checkpointer 存储的 SQL 操作，一律使用参数化查询或 ORM，禁止字符串拼接。以之前的示例代码为例，修复后应该长这样：
@app.route("/load") def load_checkpoint(): thread_id = request.args.get("thread_id") query = "SELECT payload FROM checkpoints WHERE thread_id = %s LIMIT 1" cur.execute(query, (thread_id,)) row = cur.fetchone() ...除了参数化，还要对输入做严格的类型和格式约束。thread_id如果预期是 UUID，那就按 UUID 格式校验；如果预期是字符串，就限定长度和字符集。不要觉得这是多此一举，输入约束能把很多绕过手法拦截在注入发生之前。
此外，数据库账号的权限也需要收敛。Checkpointer 理论上只需要对 checkpoint 表做SELECT、INSERT、UPDATE，不应该具备DDL权限，也不应该能访问其他业务表。把数据库账号的最小权限做好，即使注入存在，攻击者也很难利用它写出恶意载荷。
6.2 载荷加固：msgpack 安全解码与白名单
第二、三洞的修复要更深入。对于 msgpack 反序列化，核心原则是“能不解扩展类型就不解扩展类型”。如果业务上确实需要扩展类型，那就必须为扩展类型建立白名单机制，只允许已知安全类型的代码执行，其他类型一律拒绝。
这里有一个更稳妥的替代方案：不要把自定义 Python 对象直接塞进 msgpack，而是只存储可恢复的纯数据。比如状态快照里的业务数据，存成字典、列表、字符串、数字这些基本类型；真正需要类实例化的对象，单独用一个白名单注册表去重建，而不是依赖反序列化机制自动实例化。这样即使攻击者修改了载荷，也无法指定任意的类来实例化。
示例的安全 ext_hook 可以这样实现：
SAFE_CLASSES = { "UserState": UserState, "ConversationMeta": ConversationMeta, } def safe_ext_hook(code, data): if code != 88: return msgpack.ExtType(code, data) cls_name, state = pickle.loads(data) if cls_name not in SAFE_CLASSES: raise ValueError(f"disallowed class: {cls_name}") return SAFE_CLASSES[cls_name].from_state(state)在这个实现里，即使攻击者通过 SQL 注入写入了恶意载荷，反序列化时也会因为类名不在白名单里而被拒绝执行。
6.3 纵深防御：最小权限、隔离、审计
单点修复只是第一步，更重要的是建立纵深防御。我建议所有使用 LangGraph Checkpointer 的项目都做以下四件事：第一，Agent 服务的运行进程使用低权限系统账号，避免 RCE 后直接获得高权限；第二，数据库和 Agent 服务之间设置独立账号，且账号只开放必需的读写权限；第三，Checkpointer 的存储内容启用完整性校验，比如在写入时附带 HMAC 签名，恢复时验签，这样即使数据库被改写，恶意载荷也无法通过校验；第四，所有对 checkpoint 表的读写操作都要审计日志，记录操作时间、调用方、涉及字段，方便事后追踪。
这里要特别说一下 HMAC 完整性校验。它是防止“SQL 注入写入恶意数据”最有效的兜底手段，因为攻击者即使能构造 SQL 语句，也没有签名密钥，无法生成合法的消息认证码。恢复端验签失败后直接拒绝加载，恶意载荷就永远不会进入反序列化流程。这个方案比单纯依赖白名单更底层，建议优先部署。
7. 复盘与延伸：Agent 记忆层安全的设计清单
聊到这里，整条攻击链已经很清楚：从 SQL 注入入口，经过 msgpack 载荷篡改，再到反序列化后处理引发 RCE，每一环都是经典问题，但组合起来就变成了 Agent 记忆层的真实威胁。最后想给出一份可以直接落地使用的设计清单，以及一些延伸思考。
7.1 记忆层安全设计清单
每个使用 LangGraph Checkpointer 或类似记忆组件的项目，都建议对照清单自查一遍：
- 是否所有存储查询都使用参数化或 ORM，不存在字符串拼接？
- 外部传入的
thread_id、session_id、user_id等字段，是否做了格式和长度校验？ - Checkpointer 的存储数据是否经过序列化？序列化过程中是否使用扩展类型？扩展类型是否有白名单？
- 反序列化的 hook 里是否存在类实例化、方法调用、命令执行等危险行为？
- 存储数据是否有完整性签名机制，能抵御数据库被直接篡改的情况？
- 数据库账号是否为最小权限，能否区分 checkpoint 表和其他业务表？
- Agent 运行进程是否为低权限账号，能否限制 RCE 后的影响范围？
- 对 checkpoint 表的读写是否记录审计日志，并纳入监控告警体系？
这些问题如果有一条不满足，就说明记忆层还存在攻击面。不要等项目上线后再补，记忆层的问题通常越早修复成本越低。
7.2 延伸：序列化漏洞不只有 msgpack
Msgpack 只是前面提到的其中一种格式，类似的威胁还有 pickle、PyYAML、Jackson、Java 原生序列化、PHP 反序列化等。每一个都有对应的 gadget 链和安全编码规范。基本原则是共通的：不要反序列化不可信数据，不要动态加载载荷中指定的任意类，不要依赖黑名单过滤恶意类。
在 Agent 生态里，除了 Checkpointer，还有向量数据库中的 embeddings、RAG 检索结果、工具调用的返回值，这些都可能成为恶意载荷的载体。模型本身可以被注入攻击，模型输出的内容也可能被用来构造恶意序列化数据。所以安全团队在做 Agent 威胁建模时，不能只看某一个组件，要从“数据流”的视角去看，所有可能被攻击者影响的输入，都必须当作不可信输入来处理。
7.3 在实际项目中的落地建议
根据我的经验，防御这类攻击最有效的方式是把“记忆层即攻击面”作为设计原则，而不是事后补救。架构阶段就应该明确：Checkpointer 存储的数据虽然是内部数据，但经过数据库、网络、反序列化多个环节，等价于不可信输入；任何对存储数据的解析行为都要走安全解码路径。
如果项目已经上线，建议优先部署 HMAC 完整性和参数化查询这两个修复，因为覆盖面广、侵入性小。然后逐步补上白名单机制和审计日志。安全加固不是一次性的工作，而是一个持续迭代的过程；Agent 的记忆层作为核心组件，值得和业务逻辑一样被认真对待。有一点我感触很深：真正能挡住这类攻击的，往往不是某个花哨的防护系统，而是开发团队的默认假设。把“我的存储是可信的”换成“我的存储随时可能被污染”，很多问题就会在设计阶段被暴露出来，也就能少走很多弯路。
