2 篇博文 含有标签「policy-as-code」

你的 API 网关验证了用户身份。你的工具端点会检查用户是否有权删除该行。在这两次检查之间，存在一个并不存在的层：即决定模型在此次对话中是否被允许以这些特定参数请求 delete_user 的那一层。

在大多数智能体（agent）技术栈中，那一层就是系统提示词（system prompt）。它会说“小心执行破坏性操作”和“只删除用户明确要求你删除的记录”之类的话。这句话并不是访问控制。它只是对一个非确定性过程的礼貌请求，而评估该请求的组件，恰恰是攻击者试图操纵的那个。

当监管机构第一次要求你证明你的支持代理在 3 月 14 日没有访问某位二级客户的账单记录时，你会发现关于你的鉴权架构的一个令人不悦的事实：系统提示词说“不要访问二级客户的账单”，YAML 工具清单说 tools: [search_orders, refund_order, get_billing]，而在两者之间，模型做出了决定。由于不存在决策点，因此没有决策记录。代理是否做了正确的事是无法审计的，只能从发生的日志中推断。

这是智能体工程中没人画在架构图上的部分。如今的工具权限仍然存在于由创建智能体的人编辑的 YAML 文件中，通过描述意图的系统提示词呈现给模型，并由包裹每个工具调用的应用代码强制执行（如果真的执行了的话），例如 if user.tier == "premium" 检查。随着工具目录超过 50 个条目，且条件在租户、数据类别和用户角色之间成倍增加，这种手动构建的网格便不再具备扩展性，而系统提示词也不再是一个可靠的执行面。模型不是你的鉴权层，即使它的表现看起来像是一个鉴权层。

取而代之的是策略即代码（policy-as-code）：一个专门的策略引擎 —— OPA 配合 Rego、AWS Cedar 或类似的声明式工具 —— 作为策略决策点（Policy Decision Point）位于每个工具调用之前。引擎在每次调用时只回答一个问题：给定这个主体（principal）、这个工具、这些参数和这个上下文，该操作是否被允许？智能体运行时（agent runtime）从未参与投票。这篇文章将探讨这种架构在实践中的样子，以及它所解决的四个即使是提示词工程也无法解决的问题。