AWS 新近发布的 TOLAP 项目，最值得关注的并不是这个缩写，而是它把安全控制放在了哪里。

安全的 AI 代理工具通过对象级访问控制层过滤数据库和 API 数据，然后才将其送入代理上下文。

AWS Labs 已将 TOLAP（Tool-Object Level Access Protocol，工具—对象级访问协议）作为 AI 代理工具的开源安全层发布。这个项目的目标，是在代理调用工具之后，决定哪些数据可以离开工具：哪些行可见，哪些字段必须隐藏或脱敏，哪些端点可以调用，可以返回多少结果，以及请求的动作是否符合委托目的。它的首个公开版本说明，代理安全正在从一个相对简单的问题——“这个身份能否调用该 API？”——转向更棘手的问题：“这一次具体调用究竟可以披露或改变什么？”

对于构建数据库、内部 API、知识库、对象存储和 MCP 服务器上层代理的团队来说，这个区别很重要。普通的权限检查可以授权建立连接，却仍可能让工具返回远超用户或工作流实际需要的数据。TOLAP 的思路，是在真正读取或改变数据的函数外包一层策略包装器，并在结果进入代理上下文之前执行策略。

该项目并不替代身份管理、网络控制、数据库权限或人工审批。它是一个范围更窄的控制，用来弥合“能够访问工具”和“暴露具体对象”之间的空隙。

AWS 发布了什么

AWS Open Source 将 TOLAP 描述为源点执行层。代码仓库采用 Apache 2.0 许可证，包含策略模式、面向 .NET、Python 和 TypeScript 的执行库、参考策略服务器、示例、文档，以及与常见代理和工具框架的集成。

它的核心模型是声明式的。一项策略可以识别允许访问的对象和动作，隐藏指定字段、遮盖数值、过滤行、限制存储前缀或 API 方法、设置结果上限，并附加审计信息。示例使用了医疗健康风格的数据集：代理可能被允许查询患者记录，却不能收到社会安全号码；电子邮件地址可以以哈希值形式返回；行也可以限制在指定区域。

这与给代理一个拥有广泛读取权限的数据库凭据，然后要求模型自觉行事，并不是一回事。在 TOLAP 模型中，代理仍可通过工具构造查询，但包装器会把有效策略应用到结果上。被策略拒绝的数据会在进入模型上下文之前被移除。

AWS 表示，各语言 SDK 共用带版本的策略模式和通用测试夹具，因此不同实现的目标是保持一致行为。代码仓库还包含面向 MCP SDK、Strands、LangChain、LangChain.js、Vercel AI SDK、Mastra、OpenAI Agents、Pydantic AI、Semantic Kernel 和 Bedrock Agents 的集成。这些集成不会把 TOLAP 变成 MCP 服务器。项目包装的是工具层所调用的函数，数据读取仍由应用程序负责。

面向生产使用，仓库还包括一个由 PostgreSQL 支撑的策略服务器、不可变策略版本、发布与回滚操作、审计轨迹、通过 Cognito 认证的管理功能，以及带重叠窗口的签名密钥轮换。这些组件属于参考基础设施，并不意味着每个组织都应该部署完整技术栈。

为什么普通的工具授权还不够

大多数代理架构已经存在多层权限。用户向应用认证，应用为代理提供服务身份或委托令牌，网关检查令牌，工具再调用数据库或 API。每一层都有价值，但没有哪一层会自动回答对象级问题。

设想一个拥有查询客户表权限的内部支持代理。角色检查或许能够正确判断支持应用可以调用客户搜索工具，但它未必能回答以下问题：

  • 发起请求的员工可以查看哪些客户；
  • 哪些列应该被省略；
  • 结果是否可能包含员工所属区域之外的客户；
  • 地址能否完整返回；
  • 查询是否允许返回 5,000 行；
  • 一次读取操作是否悄然变成了导出操作。

网关可以授权端点，数据库可以执行授权，应用也可以过滤响应。但如果这些决定散落在定制代码中，有效边界就很难盘点和测试。组织加入的框架、连接器和代理运行时越多，就越容易出现某条路径遗漏检查的情况。

TOLAP 的架构论点是：工具是阻止数据进入代理上下文的最后一个可靠位置。提示词指令不是安全边界。模型可能误解规则，可能遵循检索内容中嵌入的恶意指令，也可能把各自获准的结果组合成设计者没有预料到的披露。如果敏感字段从未穿过包装器，模型就无法从上下文中恢复它。

这并不意味着工具会因此自动变得可信。包装器必须是通往受保护数据源的唯一通道，应用也必须阻止其他凭据或未包装代码路径访问同一数据。只有当源点确实受到控制时，源点执行才有意义。

这次发布不只有行和字段过滤

首个版本中的对象级控制最容易理解。较新的材料还介绍了围绕代理动作目的和顺序的控制。

TOLAP 策略可以包含目的配置文件，用来缩小某个请求适用的策略范围。随后，动作验证会检查工具调用是否属于允许的动作集合。如果出现被禁止的动作，调用会被拒绝；如果存在允许动作列表，而请求动作不在其中，同样会被拒绝。

项目还描述了委托链验证。当一个代理调用另一个代理，或者工作流经过多个服务传递权限时，这项能力尤其重要。下游组件不应悄悄获得比上游授权更宽的权限。在设计良好的链路中，每一次委托都会保持或缩小范围，并且最终决定仍能追溯到最初的授权主体。

顺序很关键。目的过滤先选择适用策略；动作验证检查工具被要求执行什么；对象级执行随后控制哪些数据可以返回或被修改。每个阶段都被描述为默认失败关闭，并且可以独立测试。

AWS 还记录了一个可选的语义对齐层，使用 LLM 评审器。这是设计中最需要谨慎对待的部分。确定性规则可以检查表、字段、行过滤器、动作或端点，却不总能判断一系列各自有效的查询是否符合声明的目的。评审器可以查看目的描述、当前工具调用和近期历史窗口，再根据置信度阈值决定允许、阻止或升级处理。

项目把评审器放在确定性执行之后，而不是之前。这个顺序是合理的：如果结构化策略已经禁止某个字段，模型就不应有机会说服另一个模型把它披露出来。评审器被描述为可选功能，默认关闭；其提示词由管理员控制，代理无法编辑。

组织应把评审器视为额外信号，而不是确定性访问控制的替代品。它的输出具有概率性，配置需要评估，含糊不清的情况也应该有明确的人工审查路径。这个版本最强的边界仍是传统而直接的那条：策略禁止返回的数据，就不要返回。

这对 MCP 和代理工具团队意味着什么

对那些扩展工具的速度快于扩展授权设计的团队来说，实际影响最大。

MCP 让向模型暴露能力变得相对容易。安全问题不只是服务器是否要求认证，还包括每个工具是否拥有狭窄的数据契约，以及服务器是否在客户端或模型看到结果之前完成过滤。即使 MCP 连接使用短期令牌，一个返回不受限制数据库结果的工具仍然过于宽泛。

MCP 之外也有同样的问题。OpenAI Agents 工具、LangChain 检索器、Bedrock Agent 动作组、函数调用端点，或自定义 Python 包装器，都可能意外成为数据披露边界。TOLAP 的方法刻意位于模型框架之下：把策略放在与数据源通信的函数外部，然后在更换编排层时继续使用同一种执行模型。

这种分离带来一个运维好处。团队可以在不测试模型是否会遵循指令的情况下，测试安全行为。策略测试可以断言：被禁止的列不存在，行过滤器已经应用，结果上限得到遵守，禁止的动作会失败。这些都是普通的软件和安全测试。之后，再针对缩减后的结果集评估模型是否有用。

代价也很明确。工具边界上的包装器能看到工具返回的内容，却未必理解数据中的所有业务含义。策略可以隐藏字段、过滤区域，但要表达“这五个获准查询合起来产生了被禁止的推断”可能更困难，除非维护历史记录或增加语义审查步骤。因此，这次发布中的确定性层和语义层应被看作互补，而不是可以相互替换。

仍然属于应用程序的边界

TOLAP 并不会消除传统安全控制的必要性。

身份仍然重要。策略需要可靠的主体、群组、角色、服务账户或委托主体。如果每个请求都以同一个权限过大的服务身份到达，对象级规则可能缺少足够上下文，无法作出有意义的决定。

凭据设计仍然重要。被包装的工具不应拥有能够绕过包装器、直接访问数据源的凭据。短期凭据、范围受限的角色、网络限制、密钥轮换，以及开发和生产环境分离的身份，仍是基本控制。

源系统仍然重要。数据库行级安全、API 授权、存储策略和应用级业务规则，都应继续执行各自的边界。TOLAP 可以减少代理收到的数据，但不应成为关键数据库或不可逆操作周围唯一的保护。

审批设计仍然重要。隐藏字段并不会让破坏性动作变得安全。删除记录、修改付款、轮换密钥或部署代码，可能需要人工审批、双人规则、事务预览或可回滚工作流。TOLAP 的动作验证可以拒绝超出范围的调用，但一个被允许的动作仍可能重要到不适合自动执行。

可观测性仍然重要。有用的审计事件不应只有“工具已调用”。它还应连接授予权限的人或服务、代理身份、目的、工具、有效策略版本、数据范围、结果大小、决定以及任何审批信息。缺少这些上下文时，事件响应人员或许知道查询执行过，却不知道它为何获准。

最后，治理仍然重要。策略需要负责人、失效日期、审查触发条件、版本控制、回滚，以及在连接器变化时运行的测试。如果没有人检查底层工具是否新增参数，或是否出现绕过执行函数的新路径，策略包装器就可能制造虚假的安全感。

一套合理的评估计划

团队不必采用完整的 TOLAP 技术栈，也能从这次发布中获得启发。它的设计可以转化为对现有代理工具的一次实际审查。

先盘点真实的数据路径。对每个代理工具，找出读取或修改数据源的函数、它使用的凭据、其他访问路径，以及结果变得对模型可见的节点。画出从用户请求到工具调用，再到数据源响应的路径。如果团队说不清执行点在哪里，通常也就无法证明边界在哪里。

接着，把能力授权与数据授权分开。“代理可以使用客户搜索”是能力声明；“代理可以查看分配给该员工的客户，不得查看出生日期，且电子邮件必须脱敏”才是数据策略。两者都应转化为可测试的形式。

然后建立负面测试。检查包装器是否会阻止被禁止的表，移除受限字段，过滤范围之外的行，遮盖敏感值，限制异常宽泛的响应，拒绝未经批准的动作，并在策略解析或签名失败时默认关闭。既要测试正常代理路径，也要使用工具凭据测试直接访问。

测试组合行为，而不只是单次调用。模型可能通过几次看似无害的查询取得敏感信息，也可能让一个代理把权限传给另一个代理。记录并审查调用序列、委托变化和重复导出。如果业务目的很重要，应定义哪些序列需要人工审查，而不是试图把每一种解释都编码进提示词。

最后，衡量开发者摩擦。安全层如果难以集成，就可能被绕开。正确的问题不是包装器能否表达所有想象得到的策略，而是组织能否让安全路径成为每个受支持连接器和框架最容易采用的路径。

为什么值得关注这次发布

TOLAP 是对一个问题的早期开源回答：许多代理部署目前仍依赖零散的中间件和约定来解决这个问题。它最有价值的贡献在于概念上的清晰化：能够访问一个工具，不等于被授权访问该工具能够触及的每个对象。

随着代理从对话式搜索进入查询生产系统、概括私密记录、调用 API 和委托其他代理执行任务的工作流，这种区别变得更紧迫。现有身份平台仍然必不可少，服务提供商也在增加代理身份、条件访问和策略控制。但外层身份并不会自动限制内层结果的形状。

应把这个项目当作基础设施来评估，而不是一枚可直接授予的安全徽章。阅读威胁模型，确认每一条数据源路径都经过包装，审查策略模式和失败行为，用具有代表性的数据运行示例，并检查许可证、依赖项、支持的运行时和运维模式是否适合组织。可选的 LLM 评审器应被视为需要单独验证的审查辅助工具。

对平台和安全团队来说，眼下的建议很直接：凡是接触敏感数据的代理工具，都应在模型看到数据之前定义最小而有用的结果。在数据边界用代码执行这一定义，确保凭据无法绕过它，并记录作出决定时使用的策略。AWS 的 TOLAP 发布提供了一个具体的开源项目，方便团队检查，也让这种架构更容易被讨论。

真正发生变化的是：AI 代理的安全边界不只由启动请求的身份决定，也由那个决定什么可以进入代理上下文的函数决定。

来源

本文事实依据包括 AWS Open Source Blog 发布的《Introducing TOLAP: object-level access control for AI agent tools》以及 AWS Labs 的 TOLAP 代码仓库和架构文档；相关背景还参考 Microsoft Learn、NIST NCCoE、arXiv 论文和 Reddit 讨论。