fix(architect-for-startups): clarify AgentCore Memory access control

[leon1418]

AgentCore Memory guidance previously described Gateway + Cedar without explaining how caller identity is bound to Memory access or which operations are covered. This update makes those boundaries explicit for startup architecture recommendations.

Changes

• Expand fine-grained access control (FGAC) on first use.
• Explain that JWT-claim-based user or tenant isolation requires OAuth (JWT) authentication and enforced Cedar policies that bind actor or namespace access to verified claims.
• Preserve the documented IAM path: Cedar can also govern IAM-authenticated callers using their IAM identity.
• State that BatchCreateMemoryRecords, BatchUpdateMemoryRecords, and BatchDeleteMemoryRecords are outside Cedar FGAC. IAM policies can allow or deny each batch operation as a whole.
• Link the official documentation and record the verification date, 2026-09-16.

Sources and scope

• Fine-grained access control for Memory, particularly "What you can enforce" and "Memory action ids".
• Original AWS announcement.

Only the existing adoption-guidance item in architect-for-startups/references/agentcore.md changes. There is no corresponding architect-for-startups skill in the migrate plugin.

Validation

• Targeted dprint check passed.
• Markdown lint passed: 868 files, zero errors.
• Cross-plugin drift check passed: 270 identical, 25 allowlisted.
• git diff --check passed.

[herosjourney]

Reviewed for factual correctness against current AWS docs (via AWS Knowledge MCP) and the repo's other AgentCore references.

Core claim checks out. FGAC for Amazon Bedrock AgentCore Memory is real and GA (Aug 2026): front Memory with a Gateway using OAuth/JWT auth, attach a Cedar policy engine, and Memory operations become Cedar actions with context.input request attributes available for policy conditions. The "12 Memory operations" figure is correct — verified against the action-id table in the Fine-grained access control for Memory dev guide (ListEvents, CreateEvent, GetEvent, DeleteEvent, ListSessions, ListActors, RetrieveMemoryRecords, ListMemoryRecords, GetMemoryRecord, DeleteMemoryRecord, ListMemoryExtractionJobs, StartMemoryExtractionJob).

One omission worth flagging (not a blocker): the batch Memory operations (BatchCreateMemoryRecords, BatchUpdateMemoryRecords, BatchDeleteMemoryRecords) are not exposed as Cedar actions and can't be governed by FGAC — only allowed/denied as a whole via IAM, with no per-record granularity. The proposed wording ("Cedar policy enforcement on tool calls and Memory access ... or per-memory-operation") reads as full coverage. For an audience deciding whether AgentCore's Cedar model replaces custom authorization code, this gap matters if their memory access pattern relies on batch writes. Suggested tweak:

- 1. **Cedar policy enforcement on tool calls and Memory access** — building authorization logic per-tool (or per-memory-operation) is error-prone; AgentCore now also supports FGAC for Memory via Gateway + Cedar policies
+ 1. **Cedar policy enforcement on tool calls and Memory access** — building authorization logic per-tool (or per-memory-operation) is error-prone; AgentCore now also supports FGAC for Memory via Gateway + Cedar policies (batch Memory operations are IAM-only, not Cedar-governed)

Cross-checked other AgentCore reference files for consistency:

• migrate/plugins/migration-to-aws/skills/agent-advisor/references/decision-refs/agentcore.md already frames Cedar as a Policy/guardrails capability — consistent, no conflict.
• migrate/plugins/migration-to-aws/skills/gcp-to-aws/references/design-refs/design-ref-agentic-to-agentcore.md was correctly filtered out as a false positive — it's about Strands framework migration mapping, not authorization architecture.

Mirror-skip claim verified: migrate/plugins/migration-to-aws/skills has no architect-for-startups skill directory at all (only agent-advisor, gcp-to-aws, heroku-to-aws, llm-to-bedrock, tf-best-practices, shared), so "file not found" for the mirrored edit is accurate.

Net: approve, with the optional batch-operations caveat above for completeness.

[leon1418]

@herosjourney Addressed the batch-operation caveat from your review comment in 43e7b81.

The guidance now explicitly names BatchCreateMemoryRecords, BatchUpdateMemoryRecords, and BatchDeleteMemoryRecords as outside Cedar FGAC, and states that IAM policies can allow or deny each batch operation as a whole. This avoids implying per-record authorization coverage for batch requests. The text links the official Memory action reference and includes the verification date.

Targeted formatting, Markdown lint, cross-plugin drift, and whitespace checks passed.