AI Agent 时代的 IAM：AWS 用两门语言解决了一个所有人都在回避的问题

当 Agent 的问题不是”能不能做”，而是”做完这些之后还能不能做”

一个 AI agent 读了你的机密合同，然后请求发一封邮件。

单独看”发邮件”这个动作——完全合法，每个员工每天都在做。但加上前面的”读机密合同”，这就变成了数据外泄。

一个 agent 今天已经批了 4 笔 $1,200 的报销，现在请求批第 5 笔。单独看每一笔都在权限内（$1,500 以下免审批）。但加在一起就是 $6,000——超过了日累计上限。

这类问题有一个共同特征：单次看合法，序列看违规。 传统的授权系统——包括 AWS 自己的 IAM——看的是”此刻这个请求合不合法”。它没有记忆，不知道 agent 上一步做了什么。

2026 年 8 月，AWS 用两个开源项目给出了完整方案：Cedar 管住每一步，Dogwood 管住整条路。

Cedar：AI 时代的基础授权语言

从何而来

Cedar 不是新东西。它是 AWS 2023 年发布的授权策略语言，最初用于 Amazon Verified Permissions 和 AWS Verified Access。2025 年底被捐给 CNCF 作为 sandbox 项目。到 2026 年 3 月，它成为 Amazon Bedrock AgentCore 的原生策略引擎，正式进入 AI agent 授权的核心位置。

但 Cedar 真正独特的地方不是语法——OPA/Rego、Casbin 都能写策略。Cedar 独特的是它从第一天起就为形式化验证设计。

什么是”可验证的策略”

Cedar 的每一条策略都可以被自动推理工具（automated reasoning）数学证明。不是”测了一千个 case 没出 bug”，而是”逻辑上不可能违反”。

Amazon Science 的论文描述了这个设计：

“Cedar is the first policy language built from the ground up to be verified formally by using automated reasoning, and tested rigorously using differential random testing.”

具体能做什么：

证明两组策略是否存在冲突（”策略 A 允许的事情策略 B 是否禁止？”）
证明策略集是否完备（”有没有漏掉某类请求没有覆盖？”）
证明策略变更是否安全（”新加的策略是否意外扩大了权限？”）

在传统 IAM 中，这些问题靠人工 review 和测试。在 agent 场景下——一个系统可能每秒发出数十次工具调用——人工 review 不现实。形式化验证让策略本身变得”可证明正确”。

Cedar 在 Agent 场景中的核心设计

AWS 安全博客在 2026 年 5 月的文章标题直接亮明了定位：“Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows”

核心机制：模型提出一个工具调用 → Cedar 策略引擎在模型外部做出决策（permit 或 forbid）→ 模型永远无法接触或绕过执行层。

这个”模型外部”至关重要。如果你把权限控制放在 prompt 里（”你不可以访问数据库”），模型可能被 jailbreak 或 prompt injection 绕过。Cedar 是确定性代码执行——不管模型”想”做什么，策略引擎是硬门禁。

一条典型的 Cedar agent 策略长这样：

permit(
  principal == User::"john",
  action == Action::"process_refund",
  resource == Tool::"refund_api"
) when {
  context.refund_amount < 500
};

默认拒绝（deny-by-default）：没有匹配的 permit 策略，一律拒绝。forbid 永远覆盖 permit。这跟 AWS IAM 的逻辑一致——在 agent 领域延续了 AWS 安全团队 20 年的设计哲学。

多 Agent 链中的最小权限

2026 年 7 月 AWS 安全博客发布了 “Enforce least-privilege authorization in multi-agent AI chains using Cedar”——直接把 Cedar 应用到多 agent 协作场景：

Agent A 调用 Agent B → Agent B 调用 Agent C → Agent C 调用外部工具。每一跳都有独立的 Cedar 策略约束。Agent A 有权调 B，不代表 A 通过 B 间接获得了 C 的权限。这杜绝了”权限传递”漏洞——agent 通过链式调用逐步获取超出自身权限的能力。

Cedar 的局限：它看不到时间

Cedar 的设计是无状态的。同一个请求进来两次，结果永远一样，不管之间发生了什么。这是一个刻意的设计选择——无状态让形式化验证成为可能，让审计变得简单，让策略评估变得可预测。

但 agent 的风险往往存在于序列中。”先读机密再发邮件”、”日累计超限”、”没审批就执行”——这些都需要策略系统有”记忆”。

这就是 Dogwood 登场的理由。

Dogwood：给策略系统装上记忆

解决什么问题

Dogwood 于 2026 年 8 月 8 日发布（The New Stack 标题：”Your AI agent’s next tool call may be valid but wrong. AWS’s Dogwood promises to fix that.”），8 月 16 日在 InfoQ 上获得详细技术分析。Apache 2.0 开源。

它在 Cedar 之上增加了一个核心能力：时序条件（temporal conditions）。策略不再只看”此刻的请求”，还能看”agent 过去做了什么”。

四个操作符

操作符	含义	典型场景
`formerly`	过去 N 时间内是否发生过某事	“读了机密后 1 小时内禁止发邮件”
`count_within`	过去 N 时间内某动作发生了几次	“每小时最多调 100 次 API”
`count_distinct_within`	涉及了多少不同的值	“1 小时内不能联系超过 5 个不同的外部 IP”
`sum_within`	累计数值	“日累计转账不超 $5,000”

实现原理

Dogwood 不是重写了 Cedar。它的时序条件在评估前被翻译为 Cedar 的 context 字段——策略引擎从事件历史中填充 context，然后 Cedar 照常决策。这保证了向后兼容：任何合法的 Cedar 策略同时也是合法的 Dogwood 策略。

action schema 直接从 agent 的 MCP 工具清单（tool manifest）生成——每个工具变成一个 action，参数变成条件字段。不需要手动定义。

并发陷阱：AWS 公开展示的”一个单词之差”

InfoQ 文章重点分析了 AWS 在文档中公开的一个正确性陷阱——这可能是整个发布中最有教学价值的部分：

场景：限制日累计转账不超 $5,000。3 笔 $2,000 的转账同时到达。

策略写法 A（看 response 事件）：3 笔同时到达时，没有一笔已完成，response 历史中总额为 $0 → 全部放行 → 合计 $6,000，超限。

策略写法 B（看 request 事件）：第三笔到达时，前两笔的请求已记录，总额 $4,000 → 拒绝第三笔。

一个单词的差别（response vs request），策略从安全变成不安全。这是经典的分布式系统并发问题——在 AI agent 领域重新出现了。

代价：失去形式化验证

Dogwood 时序条件不支持 Cedar 的自动推理分析。这是有意的设计取舍：

“This is why they built a separate language rather than extending Cedar.”（InfoQ）

Cedar 保持无状态 = 可以数学证明正确性。Dogwood 引入状态 = 表达力更强但失去可证明性。

AWS 的建议是：静态规则用 Cedar（可验证），时序规则用 Dogwood（更强但需要测试验证）。两者共存于同一策略集，各司其职。

组合起来看：AI Agent 的完整授权架构

把 Cedar 和 Dogwood 放进 AWS 的完整 agent 基础设施中：

┌─────────────────────────────────────────────┐
│  Kiro Crew（编排层，开源）                      │
│  调度 / 记忆 / 多Agent协作 / 审批流            │
├─────────────────────────────────────────────┤
│  Kiro Harness（运行时，闭源）                   │
│  Agent循环 / 模型通信 / 工具执行               │
├──────────────┬──────────────────────────────┤
│  Cedar       │  Dogwood                      │
│  单次授权     │  序列授权                      │
│  可形式验证   │  有状态 / 事件历史             │
│  无状态       │  并发感知                      │
├──────────────┴──────────────────────────────┤
│  AgentCore Policy（运行时引擎）               │
│  default-deny / forbid > permit             │
├─────────────────────────────────────────────┤
│  MCP（工具通信） / ACP（客户端通信）           │
└─────────────────────────────────────────────┘

每一层解决不同的问题：

MCP 定义 agent 能调用什么工具
Cedar 定义每次调用的权限边界（谁、对什么资源、什么条件下）
Dogwood 定义序列约束（做了 X 之后还能不能做 Y、累计不超过 Z）
AgentCore Policy 是运行时引擎，执行上述所有策略
Kiro Harness 是 agent 本体的执行环境
Kiro Crew 是管理多个 agent 的编排层

学术界的响应：自动生成策略

Cedar + Agent 的组合已经引起学术界关注。两篇 2026 年的论文值得注意：

“Autoformalization of Agent Instructions into Policy-as-Code”（arXiv:2606.26649）：用 LLM 自动把 agent 的自然语言指令（prompt）和 MCP 工具描述翻译成 Cedar 策略，然后进行形式化验证。目标是让非技术人员用自然语言描述”agent 不能做什么”，系统自动生成可验证的策略代码。

“AutoCedar: An Agentic Framework for Verifier-Guided Access Control Policy Synthesis”（arXiv:2607.03656）：更进一步——用 agent 来写 agent 的权限策略。系统将自然语言需求分解为可审查的”intent atoms”，生成候选策略后由验证器检查，失败则反馈修正。在 221 个授权任务上全部收敛。

这意味着未来的 agent 授权可能是这样的闭环：人类用自然语言描述约束 → LLM 翻译成 Cedar/Dogwood 策略 → 形式化验证器证明正确性 → 运行时强制执行。 全链路中人类不需要写一行策略代码。

为什么这是 AWS 的”IAM 时刻”

2006 年，AWS IAM 的发布定义了”谁能访问云上什么资源”的行业标准。此后 20 年，IAM 成了每个云平台的标配，但 AWS 作为先行者始终在这个领域拥有最强的话语权和最深的实践积累。

2026 年，Cedar + Dogwood + AgentCore Policy 的组合正在做同样的事——但这次管的不是人类对云资源的访问，而是 AI agent 对工具和数据的访问。

类比：

	云计算时代	AI Agent 时代
核心问题	谁能访问什么资源	Agent 能调用什么工具
基础语言	IAM Policy JSON	Cedar
序列控制	无（人类操作通常是单次的）	Dogwood
验证方式	测试 + 人工审计	形式化自动推理
默认策略	Deny-by-default	Deny-by-default
运行时	IAM evaluator	AgentCore Policy

AWS 的赌注是：谁定义了 AI agent 的授权标准，谁就在 agent 时代拥有类似 IAM 在云时代的地位。

Marc Brooker 的信号

Dogwood 的核心作者之一是 Marc Brooker——AWS VP / Distinguished Engineer，此前负责 Aurora DSQL（AWS 的分布式 SQL 数据库）。

让一个做数据库系统的人来设计 agent 策略语言，说明 AWS 将 Dogwood 视为基础设施问题而非产品问题。它需要分布式系统领域的严谨度——事件排序、并发控制、状态一致性——而不是 AI 领域的花哨功能。

另一位作者 Joseph Tassarotti 来自 Automated Reasoning Group（AWS 的形式化验证团队，同一个团队做了 s2n-tls 的安全证明和 Zelkova 的 IAM 策略分析）。第三位 Jean-Baptiste Tristan 来自 AWS Agentic AI 团队。

三人组合 = 分布式系统 + 形式化验证 + Agent AI。这不是临时拼凑的项目，这是跨领域的顶级人才协作。

对开发者意味着什么

如果你在用 Bedrock AgentCore：Cedar 策略今天就可以用（GA since 2026-03）。Dogwood 时序策略已经在 AgentCore Policy 中支持。你可以从最简单的开始——给 agent 的每个工具写一条 permit 策略，然后逐步加时序约束。

如果你在构建多 agent 系统：认真看 AWS 安全博客的”least-privilege in multi-agent chains”文章。权限传递是多 agent 系统最容易忽视的安全洞——Agent A 通过链式调用 Agent B/C 间接获取超出自身权限的能力。Cedar 的 scope 机制天然解决这个问题。

如果你关心合规：Cedar 的形式化验证能力意味着你可以向审计员证明”这组策略在数学上不可能允许 X”——这比”我们测了一千个 case 没发现问题”强得多。对金融、医疗等强监管行业，这可能是决定性优势。

如果你不在 AWS 生态：Cedar 是 CNCF 项目，Dogwood 是 Apache 2.0 开源。你可以在任何 agent 框架中使用它们——只是 AgentCore Policy 的托管服务目前只在 AWS 上。参考解释器可以自己部署。

结语：从”让 Agent 能做事”到”确保 Agent 只做对的事”

2024 年是”让 agent 能工作”的年代——大家兴奋于 agent 能自主写代码、调 API、完成复杂任务。

2025 年是”让 agent 工作得更好”的年代——更快、更准、更便宜。

2026 年正在变成“确保 agent 只做被允许的事”的年代。

这不是因为热情消退了。恰恰相反——正是因为 agent 能力越来越强、自主性越来越高、部署规模越来越大，”控制”才成为了最紧迫的工程问题。当一个 agent 每秒发出数十次工具调用，遍历整个代码库，连接内部和外部系统时——你需要的不是 prompt 里写的”请不要做坏事”，你需要的是不管它想做什么，物理上做不到。

Cedar 让你定义边界。Dogwood 让你定义路径。两者结合，是 AI agent 时代的第一套完整授权基础设施。

AWS 正在用它管理 Kiro、管理 Bedrock、管理内部 39,000 人使用的 agent 编排系统。这不是论文里的理论——这是生产系统中每天执行数十亿次的策略评估。

Agent 的下一个十年，不会被”谁的模型最聪明”定义，而会被”谁的治理最可靠”定义。 在这条赛道上，AWS 用 Cedar + Dogwood 打出了第一枪。

参考资料

InfoQ — “AWS Open-Sources Dogwood, Extending Cedar to Govern Sequences of Agent Tool Calls”（2026-08-16） https://infoq.com/news/2026/08/aws-dogwood-agent-policy/
AWS Security Blog — “Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows”（2026-05） https://aws.amazon.com/blogs/security/why-policy-in-amazon-bedrock-agentcore-chose-cedar-for-securing-agentic-workflows/
AWS Security Blog — “Enforce least-privilege authorization in multi-agent AI chains using Cedar”（2026-07） https://aws.amazon.com/blogs/security/enforce-least-privilege-authorization-in-multi-agent-ai-chains-using-cedar/
The New Stack — “Your AI agent’s next tool call may be valid but wrong. AWS’s Dogwood promises to fix that.”（2026-08-06） https://thenewstack.io/aws-dogwood-agent-policies/
Amazon Science — “How we built Cedar with automated reasoning and differential testing”（2024） https://www.amazon.science/blog/how-we-built-cedar-with-automated-reasoning-and-differential-testing
CNCF Blog — “Cedar: A new approach to policy management for Kubernetes”（2025-03） https://www.cncf.io/blog/2025/03/28/cedar-a-new-approach-to-policy-management-for-kubernetes/
arXiv — “Autoformalization of Agent Instructions into Policy-as-Code”（2606.26649） https://arxiv.org/abs/2606.26649
arXiv — “AutoCedar: An Agentic Framework for Verifier-Guided Access Control Policy Synthesis”（2607.03656） https://arxiv.org/abs/2607.03656
GitHub — Dogwood 参考解释器（Apache 2.0） https://github.com/dogwood-policy/dogwood
AWS 官方文档 — “Policy in Amazon Bedrock AgentCore” https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html