AWS 为 Amazon Bedrock AgentCore Memory 添加了细粒度的访问控制，为开发人员提供了一种托管方式，让用户或租户通过 AgentCore Gateway 隔离代理内存。 8 月 28 日发布的版本将代理设计的敏感部分转移到基础设施策略中：谁可以读取、写入、检索或修改 AI 代理跨会话使用的内存。

据 AWS 称，该功能使用 OAuth JWT 身份验证和 Cedar 策略。托管内存连接器将 12 个内存操作公开为 Cedar 操作，因此团队可以表达围绕内存操作的访问规则，而不是仅依赖应用程序代码在每次调用之前或之后过滤记录。

这听起来像是一个小的授权更新。它不是。持久内存是简单聊天界面和长时间运行的代理产品之间的主要区别之一。一旦代理记住用户首选项、帐户上下文、项目历史记录、先前决策、支持案例或业务流程状态，内存就成为安全边界。 AWS 现在正在以这种方式对待它。

发生了什么变化

Amazon Bedrock AgentCore 内存是 AWS 代理基础设施堆栈的一部分。它旨在帮助代理跨交互存储和检索上下文，而不是强迫每个应用程序团队从头开始构建自己的内存层。

新的访问控制功能使构建者可以通过 AgentCore Gateway 强制执行每个用户和每个租户的隔离。 AWS 表示，该功能可与 OAuth JWT 身份验证和 Cedar（其他 AWS 授权系统中也使用的策略语言）配合使用。 AgentCore 文档将 AgentCore 中的策略描述为基于 Cedar 的机制，用于控制对网关工具的访问。

实际的转变是内存授权现在可以更靠近网关和工具层。团队可以定义策略来控制哪个调用者可以在哪个命名空间或租户上下文中执行哪个内存操作，而不是围绕应用程序内的每个内存调用编写自定义检查。

对于多租户软件来说，这是一个有意义的架构更改。律师事务所、代理机构、支持团队或企业部门的人工智能助手可以通过相同的代理代码为许多用户提供服务。危险的失效模式不仅仅在于模型给出了错误的答案。一个租户的内存被检索到另一个租户的会话中，或者代理将敏感状态写入错误的范围。细粒度的策略执行旨在减少此类错误。

为什么内存隔离现在很重要

代理内存为 AI 平台带来了新的持久性问题。提示日志、检索到的文档、工具输出、用户偏好和工作流程状态都可以成为未来推理的一部分。这使得内存变得有用，但也使得推理数据边界变得更加困难。

传统的 API 授权通常集中在一个请求上：该调用者现在可以访问该资源吗？特工记忆将问题延伸到不同的时间。在一个会话期间存储的记录可能会在几周后通过不同的工具调用、不同的模型或不同版本的代理来检索。如果平台不将身份和授权上下文携带到这些内存操作中，内存层可能会成为跨用户泄漏的安静来源。

AWS 对 Cedar 的使用也很重要，因为它指向代理系统的策略即基础设施。代理构建者越来越需要涵盖工具、内存、执行环境、API 密钥和审核日志的控制。将这些控件放置在网关层中，为平台团队提供了一致执行策略的地方，即使应用程序团队尝试不同的模型或代理框架也是如此。

这与 AI API 网关设计直接相关。仅将提示路由到模型的网关对于严格的代理部署来说已不再足够。控制平面必须了解身份、租户、工具、内存范围、速率限制和审计跟踪。 Model Gate 和类似平台面临相同的发展方向：统一访问只有在具有可执行边界时才有用。

谁受到影响

直接受众是在 Bedrock AgentCore 上构建代理的 AWS 客户，特别是从事 SaaS 产品、内部企业助理、客户支持自动化、研究代理和面向合作伙伴的工作流程的团队。任何通过共享基础设施为多个组织或团队提供服务的产品都必须回答同一个问题：代理如何知道允许使用哪些内存？

开发人员可能会受益，因为他们可以依赖托管策略检查，而不是通过应用程序代码分散授权逻辑。这并不能消除仔细设计的需要，但它可以减少错误可能暴露错误数据的地方的数量。

安全和平台团队也会受到影响。现在需要像数据库、文档索引或秘密存储一样审查代理内存。访问模型应该是明确的。审计跟踪应显示哪个身份访问了哪个内存操作。租户隔离应直接测试，而不是从应用程序路由推断。

对于购买或构建代理系统的企业，该版本提高了供应商问题的基线。仅仅询问助手是否有记忆已经不够了。买家应该询问内存是如何分区的、是否在模型外部强制执行授权、如何更新策略以及内存访问如何在日志中显示。

对构建者的实际后果

最明显的后果是架构。构建长期代理的团队应该将模型功能路由与执行和内存权限分开。可以允许强大的模型对任务进行推理，但这并不意味着每个工具调用或内存查找都应该继承广泛的访问权限。

其次，网关和代理平台应该将内存操作视为一流事件。读取、写入、搜索、删除和更新都有不同的风险状况。使用情况分析不应停留在令牌计数上。对于代理工作负载，分析越来越需要显示工具使用情况、内存访问、租户范围、用户身份和策略结果。

第三，多租户产品应避免依赖提示指令来强制执行数据分离。可以告诉模型不要检索另一个客户的上下文，但必须在模型下强制实施持久隔离。这意味着范围凭证、网关策略、命名空间设计以及证明跨租户访问失败的测试。

最后，合作伙伴和经销商平台应该注意。如果机构的 AI API 或合作伙伴 API 自动化层允许下游客户构建代理，那么内存治理就成为产品合同的一部分。该平台需要为合作伙伴提供足够的灵活性来创建有用的自动化，而不让他们在客户端之间创建不可见的数据共享路径。

仍然不确定的内容

AWS 描述了控制模型及其对 OAuth JWT、Cedar 策略、AgentCore Gateway 和托管内存操作的使用。公开声明中尚不清楚的是，团队将如何在复杂的生产部署中设计这些策略、策略调试有多容易，以及默认情况下客户将在日志中获取多少操作详细信息。

然而，更广泛的方向是明确的。代理内存正在成为基础设施。当这种情况发生时，授权、可观察性和计费必须跟随它进入网关层。构建可靠代理平台的公司将能够在一个地方使模型访问、工具权限和内存状态可见和可管理。