Kiro CLI 安全建议聚焦 AI agent 的工具权限和上下文边界。Kiro 可以修改系统文件和 AWS 资源，因此使用 /tools trust-all、/acceptall 或自动化工作流时，需要控制 read、aws、shell 权限并避免暴露敏感数据。

Kiro CLI 安全建议：控制工具权限和敏感上下文

Kiro CLI 能读写文件、执行命令，也可能操作 AWS 资源。这些能力让 AI 编程更高效，但也意味着你需要认真管理权限边界。

尤其是在生产环境、包含私钥和 tokens 的项目、或有 AWS 权限的终端里，不要把 Kiro 当成“只会建议文本”的聊天工具。它可能真的执行系统级动作。

主要安全风险

使用 Kiro 时要注意这些风险：

• 意外系统修改：Kiro 可能误解你的需求，修改不该修改的文件。
• AWS 资源变更：可能创建、修改或删除资源，影响生产环境或产生费用。
• 数据丢失：删除或覆盖命令可能导致重要文件丢失。
• 安全漏洞：未经审查的命令可能改变权限或暴露敏感数据。

这些风险在使用 /tools trust-all 或旧的 /acceptall 时会显著上升，因为确认提示被绕过了。

典型例子：

• “清理旧文件”可能误删配置文件。
• “优化 EC2 实例”可能终止正在运行的实例。
• “修复安全问题”可能把权限改得过宽，反而暴露数据。

限制文件访问

默认情况下，Kiro 对当前工作目录的 read 通常是 trusted。敏感环境中可以取消 read 信任：

/tools untrust read

这样 Kiro 每次读取文件前都需要你明确批准。代价是确认次数会增加，但你能知道它到底要读哪些文件。

额外安全措施

如果项目里有私钥、tokens、客户数据或生产配置，建议：

• 在专门的开发环境中使用 Kiro，不要混入生产凭据。
• 把敏感文件放在项目目录外，或使用更严格的文件权限。
• 用环境变量或 secret manager 存储敏感值，不要硬编码到文件里。
• 对 AWS 操作使用 /tools untrust aws，每次 API 调用都要求确认。
• 用 steering 定义安全规则和限制，减少 agent 误操作。

谨慎使用 trust-all

如果必须临时使用 /tools trust-all 或 /acceptall，建议遵守这些规则：

• 只在开发或测试环境使用，不要在生产环境使用。
• 只针对具体任务短时间开启，任务结束后立即执行 /tools reset。
• 开启前备份重要数据。
• AWS credentials 使用最小权限。
• 过程中持续观察 Kiro 执行了哪些动作。

恢复默认权限：

/tools reset

它会把 tools 恢复到默认权限状态，通常只有 read 默认 trusted。

相关配置入口

安全相关的几个入口：

• Tool Permissions：管理 read、write、shell、aws 等工具权限。
• Context Management：控制哪些数据进入模型上下文。
• Kiro CLI 身份认证：了解登录方式和账号安全。

常见问题

Q: Kiro CLI 的 /tools trust-all 有什么风险？

A: 它会减少确认提示，让 Kiro 更容易直接执行文件、shell 或 AWS 操作。只建议在可回滚的开发环境中短时间使用。

Q: 敏感项目里可以用 Kiro CLI 吗？

A: 可以，但应限制 read、shell、aws 权限，避免把 secrets 和客户数据加入 context，并认真审查每个高风险操作。

Q: 用完 trust-all 后怎么恢复？

A: 运行 /tools reset，恢复默认工具权限。