DynamoDB 表不该直接交给 Agent：用 DynoTable 的本地 MCP、分档授权与暂存区收紧写入边界
让 Claude Code、Codex 之类的编程 Agent 查一张 DynamoDB 表，常见做法是把 AWS 凭据或一段查询结果直接塞进对话。前者把权限边界交给了模型会话，后者则让上下文很快过期。更实际的目标应当是：让 Agent 能理解表结构、提出查询和修改建议，但不能越过人直接写入生产表。
DynoTable 是面向 DynamoDB 的桌面工作台。它读取本机已有的 ~/.aws 配置，支持 IAM Identity Center（SSO）、角色链、MFA 与 credential_process；文档明确说明凭据解析与交互式登录在本地桌面应用中完成，不会被复制到其服务端。它还提供本地 MCP server，把这一套受控能力暴露给外部 Agent。这个组合更适合把“能否访问数据”和“能否提交改动”拆成独立决策。
先区分两种写入路径
这里有一个容易被忽略的边界：DynoTable 的普通编辑器和 AI/MCP 工具会进入暂存区，但 PartiQL 编辑器中的 INSERT、UPDATE、DELETE 会直接写 DynamoDB，并不经过暂存区。因此，不应把“应用有暂存区”误解为所有操作天然可回滚。
对需要控制变更的团队，建议将 Agent 的职责限定在读取、分析和提出改动，实际提交通过受审阅的暂存变更完成；同时把直接 PartiQL 写入视为单独的高风险入口，仅授予少数人工运维账号。
用一个 Profile 对应一个数据边界
DynoTable 中的 Profile 绑定一个 AWS profile 与一个默认 Region。MCP server 虽然由桌面应用统一启动，但连接必须绑定到你已暴露的某个 Profile；一条连接只能看到被批准的那一个 Profile 的数据与 Region，不能横向访问其他 Profile。
这很适合把开发与生产分开：例如只给日常编码 Agent 暴露 dynotable-dev，将 dynotable-prod 留给需要人工确认的排障会话。Profile slug 出现在 MCP 地址中只是预选提示，真正的边界仍来自应用内的批准流程。
claude mcp add --transport http dynotable-dev \ "http://127.0.0.1:/mcp?profile=dev"
服务绑定在 127.0.0.1，不是可被局域网直接访问的端口。首次连接时，DynoTable 会在应用内显示同意框；即使客户端自报了名称，也应以你选择的 Profile 和 Scope 为准，而不是以名称判断可信度。
Scope 只给当前任务所需的最小集合
MCP 连接有三级累积范围：Read only 可读 schema、执行查询和读取单个 item；Read & stage 在此前基础上可把修改放入暂存区；Full access 再增加打开视图、设置筛选和导出。值得注意的是，即使是 Full access，写入仍要经过 staging，Agent 不能直接把暂存改动提交到 DynamoDB。
因此，一次“帮我找出订单状态异常”的任务通常从 Read only 开始即可。只有当你需要 Agent 根据规则准备修复时，才临时升级到 Read & stage。Full access 也不是“生产写权限”，它只是扩大了工作台操作和导出能力；对含敏感字段的表，导出本身就应被视为需要额外审批的动作。
DynoTable 的内置 AI 将读操作分为静默的本地信息读取与会消耗 DynamoDB 容量的受控读取。前者例如 schema、索引和已保存视图；后者例如实际查询、按 key 读取和全表聚合。后者会按 Profile 的权限模式请求批准，并在本地审计日志中记录决定。把这条规则延续到 MCP，能避免 Agent 因一个“顺便统计一下”的请求把扫描成本隐藏在对话背后。
把修改变成可审阅的 diff
通过 staging 产生的创建、更新、删除，不会立即触及远端表。每张表有自己的暂存区，修改会显示为按属性划分的差异：新增、移除和变更字段可逐项拒绝。提交时，DynoTable 使用带乐观锁条件的 TransactWriteItems 批次；若有人在你暂存后修改了同一条记录，界面会报告漂移，而不是静默覆盖。
一个稳妥的人工闭环可以是：
- Agent 用只读 Scope 识别异常 key、索引和候选修复条件；
- 人工确认查询范围后，将连接提升为 Read & stage；
- Agent 仅准备暂存变更；操作者逐项检查 diff、拒绝不必要字段；
- 由拥有业务判断的人提交，并处理乐观锁冲突。
这比让 Agent 直接得到一把能写生产表的 AWS key 多了一层摩擦，却也把高风险决定从自然语言提示转成了明确、可见、可拒绝的变更集合。
将权限设计成“默认收紧、按需放开”
实际落地时，可以把 Profile、Scope 与 AWS 身份一起放进一张简单的权限矩阵。开发 Profile 对应测试 Region，只向日常 Agent 暴露 Read only；需要生成修复草案的值班会话才临时使用 Read & stage。生产 Profile 即使启用了 MCP，也应由单独的人工会话批准连接，避免开发环境里的 Agent 因配置错误碰到生产资源。
还有两个常见失败模式值得提前写进团队约定。第一，Profile 不是审计替代品：它把一条 MCP 连接钉在一个 AWS profile 和 Region 上，却不会自动校验你的 IAM 策略是否过宽。仍应在 AWS 侧限制允许访问的表、读写操作与条件。第二，暂存不是事务回滚：提交前的 diff 易于拒绝，提交后的真实写入则要按业务流程处理；乐观锁只能阻止覆盖已变化的记录，不能替你判断错误的业务规则。
建议在每次生产排障前明确三件事：本次连接绑定哪个 Profile、允许的 Scope 是什么、哪些表或分区键属于查询范围。把这些约束写进值班记录，能让下一位接手的人知道 Agent 看过什么、准备过什么，而不是只留下模糊的聊天总结。
对大表与敏感数据，先限制“读”的形状
很多事故并非来自写错，而是来自不受控制的读取。没有分区键谓词的查询可能退化为 scan；全表聚合会读取所有匹配项，并消耗读容量。让 Agent 先解释它准备使用的 key condition、目标索引和预期数据范围，再由人批准实际查询，通常比事后追查成本更有效。
对于包含个人信息、令牌或业务机密的表，导出应被单列为敏感动作。即便 Agent 只是在本地 MCP 连接上工作，导出的文件仍会成为新的数据副本。可以把“读取少量记录用于诊断”和“导出完整结果集”设成不同的审批标准，并在完成排障后撤销不再需要的 MCP 连接或关闭 Profile 的 Expose via MCP。
查询能力的边界也要说清楚
DynoTable 支持 DynamoDB PartiQL。对读查询，带分区键条件更可能走 query；没有 key predicate 的 SELECT * 则是全表 scan。PartiQL 并不是完整 SQL：JOIN、GROUP BY、聚合、子查询、UNION 和 CTE 不属于这一路径，文档建议转到 Workbench。不要让 Agent 将熟悉的关系型 SQL 直接改写后就运行，尤其不能把“看起来合理”的查询当成成本可控的查询。
如果你的主要痛点是让 Agent 帮忙理解 DynamoDB 数据，而不是让它自动执行修复，DynoTable 的价值在于把本地凭据、Profile 隔离、每连接批准、Scope 与 staging 串成一条可操作的边界。它不能替代 IAM、表级权限或变更流程，但能让 Agent 接入落在这些既有控制之内，而不是绕过去。
一份可执行的接入检查表
首次接入前，先在 AWS CLI 中确认目标 Profile 能以最小权限完成需要的读操作，再在 DynoTable 中检查 Region 是否正确。不要为了让 Agent 少报一次权限错误而把 Profile 换成管理员身份。启用 MCP 后，确认服务只显示本地 loopback 地址；连接时选择 Read only，并用一条低风险、带分区键条件的查询验证数据范围。只有在审阅过 Agent 的修复计划后，才改用 Read & stage。
任务结束后，检查暂存区是否为空：不再需要的草案应被明确拒绝或提交，而不是留在下一次会话里。对于临时生产排障，撤销已批准的连接，必要时关闭该 Profile 的 MCP 暴露。这样即使后续某个本地 Agent 配置发生变化，它也不会继承一次事故处理期间留下的访问通道。
这套流程看似比“给工具一串 key”多了几个点击，但每一次点击都对应一个可解释的授权转换：从本地凭据到 Profile、从 Profile 到连接、从连接到 Scope、从建议到暂存、从暂存到提交。对同时使用多种 Agent 的团队而言，能够说明这些转换往往比让一次查询更快完成更重要。