若想避免人工智能代理成为巨大的新型攻击面，我们必须像对待数据库一样对待代理记忆：部署防火墙、实施审计并严格管控访问权限。
大型语言模型的发展速度快得令人难以跟上。例如，艾莉·米勒近期发布了针对不同任务的法学硕士排名，但同时指出：“我相信下周就会改变。”为何如此？因为总会有模型在特定领域取得更快进展或获得强化训练。然而，不变的是这些LLM运行所依赖的高价值企业数据基础。因此，真正的关键并非追赶LLM的进步，而是弄清楚如何为人工智能构建和管理“记忆”。
如果说LLM是中央处理器，那么记忆便是硬盘、上下文和积累的智慧，使代理能够有效运作。如果剥夺代理的记忆，它不过是一个非常昂贵的随机数生成器。但与此同时，为这些日益智能的代理系统注入记忆，也创造了一个全新的大规模攻击面。
大多数组织将代理记忆视为代码中的暂存器或SDK背后的简单功能。我们需要开始将其视为一个数据库——而且不仅仅是任何数据库，它可能是你拥有的最危险（也最具潜力）的数据库。
人工智能代理的安全软肋
不久前，我曾认为不起眼的数据库正在成为AI的“海马体”，即赋予无状态模型长期记忆的外部记忆体。那是在当前这波代理系统浪潮真正兴起之前。如今，赌注更高了。
正如我的同事里士满·阿拉克在他正在进行的“代理记忆”研究中所指出的，LLM记忆与代理记忆存在关键区别。LLM记忆本质上只是参数权重和一个短暂的上下文窗口。会话结束，记忆也随之消失。代理记忆则不同。它是一个持久的认知架构，允许代理积累知识、保持上下文感知，并根据历史交互调整行为。
阿拉克将这一新兴学科称为“记忆工程”，并将其视为提示工程或上下文工程的进阶。你不再只是将更多令牌塞入上下文窗口，而是构建一条从数据到记忆的管道，有意识地将原始数据转换为结构化、持久化的记忆：短期记忆、长期记忆、共享记忆等。
这听起来或许像AI术语，但这实际上是一个伪装下的数据库问题。一旦代理能够写回自己的记忆，每次交互都可能导致系统状态潜在变化，而这些状态将被用于未来的决策。此时，你调整的不再是提示，而是在运行一个实时、持续更新的数据库，其中存储着代理对世界的认知。
如果这个数据库出错，你的代理将深信错误的信息。如果这个数据库被入侵，你的代理将持续处于危险之中。威胁通常可分为三类：
记忆中毒：攻击者并非试图突破你的防火墙，而是通过正常交互向代理“灌输”错误信息。开放全球应用程序安全项目将记忆中毒定义为破坏存储的数据，导致代理后续做出有缺陷的决策。像Promptfoo这样的工具现在已配备专门的红色团队插件，专门测试代理是否会被诱骗用恶意记忆覆盖有效记忆。一旦发生，此后每一个参考中毒记忆的行动都将被扭曲。
工具滥用：代理越来越多地获得工具访问权限：SQL端点、Shell命令、CRM API、部署系统等。当攻击者能诱使代理在错误上下文中调用正确工具时，其结果与内部人员“胖手指”误操作命令难以区分。OWASP将此类问题归类为工具滥用和代理劫持：代理并非绕过其权限，而是在为攻击者的利益使用这些权限。
权限扩散与泄露：随着时间的推移，代理会积累包含敏感数据的角色、密钥和心理快照。如果今天让代理协助首席财务官，明天又让协助初级分析师，你必须假设代理现在“记住”了它本不该在下游共享的信息。代理人工智能的安全分类已明确指出，权限泄露和访问权限扩散是新兴风险，尤其是在涉及动态角色或审计策略不严的情况下。
新词汇，老问题
关键不在于这些威胁的存在，而在于它们本质上都是数据问题。如果剥离AI的外壳，这正是你的数据治理团队多年来一直在努力应对的挑战。
我一直建议，企业正从“快速搭建”转向将“快速获得数据治理能力”作为选择AI平台的核心标准。对于代理系统而言，这一点更为重要。代理以机器速度与人机数据交互。如果数据错误、过时或标签不当，代理将以远超人类处理能力的速度犯错、过时和行为失常。
没有“治理”的“快速”，只是高速的疏忽。
陷阱在于，大多数代理框架都自带小型记忆存储：默认的向量数据库、JSON文件、临时的内存缓存，这些后来常常悄无声息地变成生产系统。从数据治理的角度看，这些都是影子数据库。它们通常没有模式、没有访问控制列表，也没有严肃的审计跟踪。
实际上，我们专门为代理人堆叠了第二个数据栈，然后却疑惑为何安全团队无人敢让这些代理靠近任何重要数据。我们不应如此。如果你的代理持有能影响真实决策的记忆，那么这些记忆应当归属于处理你的客户记录、人力资源数据和财务信息的同一套受控数据基础设施。代理是“新成员”，但保护它们的方法并不新。
现有架构的“回归”
行业正逐渐意识到，“代理记忆”不过是“持久化存储”的重新包装。仔细看，大型云提供商的做法已经很像数据库设计了。例如，亚马逊的Bedrock AgentCore引入了作为逻辑容器的“记忆资源”。它明确定义了保留期、安全边界以及如何将原始交互转化为持久见解。这就是数据库的语言，即使披着AI品牌的外衣。
将向量嵌入视为核心数据库之外某种独立的、不同的数据类别是毫无意义的。如果你的核心事务引擎能够原生处理向量搜索、JSON和图形查询，为何还要分离？通过将记忆收敛到已经存储客户记录的数据库中，你可以免费继承数十年积累的安全强化。正如布里吉·潘迪所指出的，数据库多年来一直是应用程序架构的中心，代理人工智能并未改变这种引力——反而加强了它。
然而，许多开发者仍在绕过这一体系。他们启动独立的向量数据库，或使用LangChain等框架的默认存储，创建出无模式、无审计跟踪、不受管理的嵌入堆栈。这就是我提到的“高速疏忽”。解决方案很简单：将代理记忆视为一等公民的数据库。在实践中，这意味着：
定义思维模式：通常将记忆视为非结构化文本是一个错误。代理记忆需要结构。谁说的？何时说的？置信度如何？正如你不会将财务记录转储到文本文件，你也不应将代理记忆转储到通用向量存储中。你需要元数据来管理“思想”的生命周期。
建立记忆防火墙：将每次写入长期记忆视为不可信的输入。你需要一个“防火墙”逻辑层，在允许代理记住某些内容之前，强制执行模式、验证约束并运行数据丢失预防检查。你甚至可以使用专用的安全模型在数据落盘前扫描提示注入或记忆中毒的迹象。
将访问控制置于数据库层，而非提示层：这涉及为代理的“大脑”实现行级安全性。在代理帮助拥有“1级”权限（初级分析师）的用户之前，它必须有效“切除”该会话中所有“2级”记忆（首席财务官）的访问。这一点必须由数据库层强制执行，而非提示。如果代理试图查询不应访问的记忆，数据库应返回零结果。
审计“思维链”：在传统安全中，我们审计谁访问了表格。在代理安全中，我们必须审计“为何”访问。我们需要将代理在现实世界中的行动，追溯到触发它的特定记忆谱系。如果代理泄露了数据，你需要能够调试其记忆，找到中毒记录，并对其进行“外科手术式”切除。
内置的信任
我们倾向于用抽象术语讨论AI信任：伦理、一致性、透明度。这些概念很重要。但对于在真实企业中运行的代理系统而言，信任是具体而微的。
我们正处于炒作周期的这样一个阶段：每个人都想构建能在幕后“自行处理一切”的代理。这可以理解。代理确实可以自动化过去需要整个团队才能完成的工作流和应用。但在每个令人印象深刻的演示背后，都是一个不断增长、充满事实、印象、中间计划和缓存工具结果的记忆存储。这个存储要么被当作一流的数据库来对待，要么就没有。
随着我们步入这个代理时代，那些早已知道如何管理数据谱系、访问控制、保留策略和审计的企业，拥有结构性的优势。他们无需重塑治理体系，只需将其扩展到新的工作负载上。
如果你今天正在设计代理系统，请从记忆层开始。决定它是什么、存放在哪里、如何构建以及如何治理。然后，并且只有在那之后，再让代理开始运作。
