本文要点
- AgentCore Memory FGAC 通过 OAuth/JWT、AgentCore Gateway 和 Cedar，把每用户、每租户隔离从应用代码移到基础设施层。
- Memory connector 暴露 12 项 Memory 操作为 Cedar actions；策略可按调用者身份、actor 数据、namespace 和具体操作允许或拒绝。
- Cedar 默认拒绝，且 forbid 优先于 permit；403 不等于网络故障，也不能靠扩大 IAM 权限盲修。
- actorId 与 namespace 仍要由可信身份字段稳定派生；8 月 28 日同步上线的 flexible namespace variables 可按组织、租户、团队或环境定义最多 5 个 key。
- 上线应先做正向、跨租户、缺 claim、错 namespace 和敏感操作五组测试，任何越权或不可解释拒绝都应停止扩量。
具体场景：聊天正常，接入 FGAC 后 Memory 请求却 403
团队把 AgentCore Memory 放到 AgentCore Gateway 后，聊天推理仍正常，但读取长期记忆或写入事件返回拒绝；另一种更危险的症状是应用层只校验登录，却让客户端提交 actorId 或 namespace，导致测试租户能构造别人的路径。失败成本包括个性化失效、工单积压，以及跨租户记忆暴露带来的权限和合规责任。
错误直觉是先给执行角色更大的 IAM 权限，或把 403 当作出口网络不稳定。正确第一步是保存一次请求的认证主体、脱敏后的 token claim、actorId、namespace、操作名、Gateway target 和策略决策日志；只用一条确定样本复现，再判断失败在认证、映射还是 Cedar 评估。
旧做法与新能力：应用内 if 判断变成 Gateway 强制执行
旧做法通常由应用读取用户身份，再自行检查 actorId、拼 namespace 并调用 Memory。任何遗漏的路由、后台任务或新接口都可能绕过同一套判断。2026 年 8 月 28 日，AWS 宣布 AgentCore Memory 支持 FGAC：Memory resource 可置于使用 OAuth JWT 认证的 Gateway 后，由 Cedar 根据已认证调用者限制 actor 数据、token claim 派生的 namespace 和具体 Memory 操作。
这不是把 IAM、Memory 数据模型和业务授权全部替换掉。IAM 仍控制谁能管理或调用 AWS 资源；actorId 与 namespace 仍决定数据组织；FGAC 在 Gateway 边界对每次 connector 操作再做确定性判断。官方说明 connector 暴露 12 项 Memory 操作为 Cedar actions，因此策略必须覆盖实际调用的 action，而不是只写一个泛化的 read 或 write 名称。
先画清身份到数据路径，再写 Cedar
先确定唯一可信身份来源，例如 JWT 的 subject 与 tenant claim；再定义 actorId 是否等于用户、设备或服务主体，以及 namespace 是否形如 /tenant/{tenantId}/user/{sub}/。不要把可由客户端随意修改的字段当作授权依据，也不要用邮箱显示名等会变化的属性作为长期键。
同日上线的 flexible namespace variables 解决了内置 actorId、strategyId、sessionId 不足以表达组织、租户、团队或环境的问题。先在 Memory resource 上定义 namespace key，在 strategy 的 namespace template 中引用，再由 CreateEvent 在运行时传值；每个 Memory resource 最多 5 个 key，同一个 key 可跨多个 strategy 使用。该能力已在 AgentCore Memory 正式可用的全部 AWS 区域提供且不额外收费，但它只负责组织和作用域，不会替你验证客户端传入的 tenant 值。
策略采用默认拒绝与最小操作集：先只允许测试主体调用一个必要 action 和一个精确 namespace，再逐项增加。Cedar 的 forbid 会覆盖 permit；没有任何匹配 permit 也会拒绝。自然语言生成的候选策略必须阅读生成结果、校验 schema，并在非生产环境验证，不能把生成成功当作授权正确。
五组验证：证明能访问，也证明不能越权
第一组用合法用户读写自己的 actor 与 namespace。第二组只替换 tenant 或 actorId，必须拒绝。第三组删除或篡改关键 claim，必须在认证或策略层拒绝。第四组保持用户不变但换到未授权 namespace，必须拒绝。第五组对 12 项 connector actions 做允许矩阵，确认只开放业务真正需要的创建、读取、检索或删除操作。
每组记录期望结果、实际状态、Gateway 与策略版本、CloudWatch 决策线索和数据是否产生副作用。验收标准不是“主流程 200”，而是正向样本稳定通过、所有跨租户与缺 claim 样本稳定拒绝，并且拒绝原因能由团队复盘。
403 排错树与停止条件
先看请求是否到达 Gateway：DNS、TLS 或连接超时发生在策略评估前；已产生明确授权拒绝则继续查 JWT audience/issuer/过期时间和必需 claim。认证通过后，核主体标签、action 名、Gateway resource 与 namespace 条件；最后查是否有更高优先级 forbid、拼写错误、类型不匹配或根本没有 permit。一次只改一个变量并重放固定样本。
出现任何跨租户成功访问、日志缺失、策略无法解释的允许、删除类操作范围过宽，或测试环境与生产身份映射不一致时立即停止扩量。回滚应恢复上一版已验证策略和 Gateway 配置，而不是关闭 FGAC；若只能通过全局 permit 恢复业务，应保持停机或降级到不读写长期记忆，并交安全负责人复核。
适用边界、常见误区与网络关系
该能力适合多用户、多租户或不同调用者需要不同 Memory 操作的 AgentCore 应用。单租户原型也可采用，但要权衡 Gateway、策略和审计维护成本。不要把 AgentCore Policy 对工具调用的通用能力与本次 Memory connector FGAC 混成同一对象，也不要推断官方未说明的地区、定价或套餐范围；上线前应在目标区域实际核服务与文档可用性。
误区包括：actorId 天然等于已认证用户、IAM Allow 会覆盖 Cedar Deny、permit 能抵消 forbid、换出口 IP 能修复授权拒绝。只有请求未到 Gateway 且出现 DNS、TLS、连接超时等独立证据时，才参考<a href="/resources/proxy-connection-troubleshooting-checklist">代理连接排查清单</a>；PuppyIP 不能修正 JWT、Cedar 或租户映射。
资料来源
常见问题
AgentCore Memory FGAC 是什么时候发布的？
AWS What's New 于 2026 年 8 月 28 日发布，官方措辞为 AgentCore Memory now supports fine-grained access control；页面未列逐地区和额外套餐范围，目标区域仍需上线前核验。
FGAC 会替代 IAM 吗？
不会。IAM 继续控制 AWS 资源和管理面权限；FGAC 通过 Gateway 与 Cedar，按已认证调用者、namespace、actor 数据和具体 Memory 操作增加数据面授权。
为什么写了 permit 仍然返回 403？
可能 action、principal、resource 或条件不匹配，也可能存在命中的 forbid。Cedar 默认拒绝且 forbid 优先；应对照实际 connector action 与决策日志逐项核验。
actorId 或自定义 namespace 变量可以直接使用客户端传入值吗？
不应把未验证的客户端字段直接当授权主体。自定义 namespace 变量可表达组织、租户、团队或环境，但仍应从已验证 JWT claim 等可信身份稳定派生或严格绑定，并用跨租户负向测试证明无法伪造。
策略上线前至少要测试什么？
至少测试本人访问、跨租户访问、缺失或篡改 claim、错误 namespace，以及每项实际使用的 Memory action；负向样本必须稳定拒绝。
更换 IP 能解决 AgentCore Memory 403 吗？
不能解决已到达 Gateway 的认证或 Cedar 拒绝。只有 DNS、TLS、连接超时等传输证据存在时，网络排查才是独立步骤。