DynamoDB AI 助手的凭据与操作边界测试

给 DynamoDB 管理工具接上 AI，能列出模型、收到回复，只能说明部分链路可用。真正需要验证的是：凭证有没有泄露，AWS 权限有没有被正确执行，Agent 会不会把一句自然语言直接变成删表操作。

作者在实习第 8 周测试了 Tables by ServerlessCreed 的 Amazon Bedrock 集成。文章最有价值的地方，是把「看到了什么」和「据此能证明什么」分开。对正在做 AI 数据库助手、内部管理工具的开发者，这是一份值得借鉴的测试思路，但还算不上完整的安全评估。

能发现模型，不代表能调用模型

Tables 是操作 Amazon DynamoDB 的桌面 GUI，Amazon Bedrock 则通过 AWS API 提供基础模型访问能力。把两者接起来，应用除了发送提示词，还需要处理 AWS 凭证和 IAM 授权。

原文给出的典型请求路径是：

桌面应用 → AWS 凭证解析 → IAM 授权 → Amazon Bedrock API → 模型响应。

这里要区分认证与授权。认证解决「当前使用哪个 AWS 身份」，授权决定「这个身份可以执行什么操作」。拿到有效凭证，并不代表可以调用所有模型，更不代表可以修改所有 DynamoDB 资源。

模型发现和模型调用也要分开测试。某个身份能列出可用模型，不代表它有权限调用列表里的每一个模型。配置页能展示模型列表，只验证了其中一段链路。

作者检查了 provider 配置、模型发现、连接行为、配置持久化，以及无效或不可用凭证下的反馈。

不过，原文没有列出具体模型、IAM 策略、逐项调用结果，也没有给出完整测试记录。因此，可以据此了解测试范围，不能进一步推断所有模型调用都已通过验证。

对接入方来说，这个区别很实用：连接测试应尽量告诉用户究竟验证了哪一步。「凭证可用」「能发现模型」「能调用目标模型」是不同的结果，不宜合并成一个含糊的「连接成功」。

凭证显示成星号，只证明界面做了遮挡

作者对凭证安全的拆分，是全文最值得保留的部分。它至少包含三个独立问题：

• 界面遮挡：普通输入框和设置页是否直接显示敏感值。
• 存储保护：凭证保存到设备后，是否得到适当保护。
• 诊断脱敏：日志、错误消息和支持材料是否可能带出凭证或令牌。

这三项需要分别找证据。

作者看到的测试页面展示了凭证脱敏行为，但没有完成对全部存储方式和诊断输出的验证。

输入框里看不到明文，不能证明凭证在整个生命周期里都安全。

要判断存储保护，需要检查实际存储或实现；要判断诊断脱敏，需要在受控条件下触发错误并检查输出。仅凭一张设置页截图，无法回答这些问题。

配置失败后的恢复同样属于集成质量。原文列出了几种可能原因：会话过期、缺少 IAM 权限、Region 配置错误、模型访问不可用，以及凭证配置无效。

这些错误不该都显示成「连接失败」。例如，AccessDeniedException 通常指向授权问题，过期的安全令牌则说明需要有效凭证。错误分类清楚，用户才知道该检查权限，还是更新登录状态。

作者还测试了移除已配置的 provider，检查用户是否有明确的断开入口。

但「移除了配置」和「彻底清除了所有凭证副本」仍是两个结论。原文确认了前者，没有提供足够证据证明后者。配置持久化虽然被列入测试范围，具体保存方式和恢复结果也没有展开。

Agent 拒绝删表后，还要检查表是否存在

AI 数据库工具最敏感的一步，是从解释操作进入实际执行。

「解释如何删除 DynamoDB 表」是在索取信息；「删除这张 DynamoDB 表」会影响数据和服务可用性。模型理解了后一条指令，也不应获得不受限制的执行权。

作者向 Workspace Agent 提出了涉及破坏性表操作的请求。在所测试的流程中，Agent 没有执行未经授权的删除。

这个观察支持一条工程原则：模型负责提出动作，应用仍要检查权限与审批条件，底层 AWS 操作还要接受 IAM 授权。用户在应用里点了确认，也不会因此获得 AWS 身份原本没有的权限。

不过，原文没有展示完整调用链，无法据此确定这次拒绝具体由哪一层触发，更无法证明所有 Agent 执行路径都受到同样保护。

作者随后通过 AWS CLI 独立检查资源状态。下面的命令用于查询指定表，辅助确认被拒绝的删表请求没有让目标表消失：

aws dynamodb describe-table \
  --table-name YOUR_TEST_TABLE \
  --region ap-south-1

要注意 --table-name YOUR_TEST_TABLE 和 --region ap-south-1：前者需要替换为测试表名，后者必须对应目标资源所在的 Region。

成功返回 DescribeTable 结果，可以帮助确认这张表仍然存在。但它不能单独证明表内项目、表属性或其他配置完全没变。

验证手段必须对应被测试的后果。

如果测试的是删表边界，查询表是否存在有意义；如果测试的是数据修改，就需要检查相关数据。Agent 显示「已拒绝」是应用层证据，资源状态则提供另一条验证路径，两者结合才更有说服力。

我的判断

我认可作者的证据意识。文章没有把界面脱敏包装成完整凭证安全，也明确承认没有覆盖全部诊断输出和 Agent 授权路径。这种克制，比单纯展示一次「成功连接」更有参考价值。

但它提供的是一次范围有限的测试记录。原文没有给出完整用例、重复执行结果、实现审查结论，也没有与其他工具比较。因此，不能据此认定 Tables 已经具备全面的安全保障，或优于其他 DynamoDB GUI。

错误信息能减少排障时间、独立验证能增强可信度，这些判断有合理的工程依据，但作者没有提供对照数据，仍应按经验之谈理解。

和只在提示词里要求「危险操作先确认」相比，把权限与审批放进实际执行链路，更容易形成可检查的边界。提示词可以影响模型选择，却不能替代应用控制和 IAM。反过来，IAM 也不能替代产品里的操作说明与确认流程：一个身份拥有删表权限，并不代表每次自然语言请求都应该直接执行。

这篇文章适合拿来设计验收清单。要判断具体产品是否安全，还得补齐存储检查、诊断测试，以及不同权限条件下的执行证据。

能拿来做什么

• 给 AI provider 配置页拆分验证结果，分别呈现凭证解析、模型发现和目标模型调用的状态，并针对权限不足、令牌过期和 Region 错误提供可操作的反馈。
• 在桌面端或 Node 工具中接入 AWS 凭证时，分别检查界面展示、本地存储和日志输出，同时明确 provider 移除后究竟清除了哪些内容。
• 给数据库 Agent 建立明确的执行入口，在调用底层 AWS 操作前检查应用权限和审批条件，并保留 IAM 这层独立授权。
• 测试删表等高影响操作时，使用专门的测试资源，再通过 AWS CLI 核对实际状态；测试涉及项目或属性变更时，把核对范围扩展到对应数据。