Kiro CLI 基于 AWS 安全基础设施构建，但安全并不只由云厂商负责。开发者和企业管理员需要理解 shared responsibility model，明确本地文件、环境变量、AWS credentials、trusted commands、Autopilot 和远程扩展的边界。

Kiro CLI privacy 与 security：在共享责任模型下安全使用 agentic IDE

Kiro 是 AWS 提供的 agentic IDE 体验，Kiro CLI 则把这种能力带到命令行。它可以读取代码、修改文件、运行命令、调用 MCP tools，因此必须把 privacy 和 security 当作使用前提，而不是上线前的补充检查。

AWS 负责保护云基础设施，你负责保护自己的代码库、凭据、工作区和使用方式。这就是 shared responsibility model 在 Kiro CLI 场景中的核心含义。

Shared responsibility model

AWS 将安全责任分为两部分：

• Security of the cloud：AWS 负责保护运行 AWS 服务的基础设施，包括数据中心、网络和底层服务。第三方审计机构会通过 AWS Compliance Programs 验证相关控制。Kiro 涉及的合规范围可参考 AWS Services in Scope by Compliance Program。
• Security in the cloud：你需要根据所使用的 AWS 服务、数据敏感性、公司要求、法律法规和内部安全政策，配置并管理自己的使用方式。

对 Kiro CLI 来说，第二部分尤其重要，因为 agent 在你的本地环境运行，可能接触代码、配置文件和环境变量。

URL fetching 的责任边界

在 Kiro chat module 中，你可以粘贴 URL，让本机抓取网页内容并作为上下文使用。这里要注意两点：

1. URL 内容由你的设备获取，Kiro 会把它作为任务上下文使用。
2. 你需要确认抓取和使用这些内容符合第三方服务条款、版权要求和适用法律。

企业环境中建议明确规定哪些 URL 可以被引入工作上下文，尤其是客户系统、内部知识库、付费内容和受监管数据源。

Autopilot 与 Supervised mode

Kiro 默认启用 Autopilot。你可以随时在 chat interface 中切换 Autopilot 和 Supervised mode。

Autopilot mode

Autopilot mode 下，Kiro 会更自主地工作：

• 可以连续执行多个步骤，不必每一步都等待确认。
• 会根据对需求的理解做决策。
• 可以创建、修改、搜索、删除代码库中的文件。
• 可以运行影响 filesystem 的命令。
• 你可以随时关闭 Autopilot 或打断它，重新取得手动控制。

适合使用 Autopilot 的场景：独立分支、小范围改动、已有测试保护、可随时回滚的实验任务。

Supervised mode

Supervised mode 更适合安全敏感或高风险环境：

• Kiro 会建议创建、修改或删除文件，但等待你确认。
• 需要信息时会提出澄清问题。
• 你可以逐项审查生成的文档和代码变更。
• 开发过程保持更强的人类控制。

无论使用哪种模式，都可以在 Chat module 中选择 View all changes 查看 agent 的单个或全部文件修改。必要时可以选择 Revert all changes，或回到某个 checkpoint，把本地文件恢复到之前状态。

Trusted commands：谨慎配置自动放行命令

默认情况下，Kiro 运行任何命令前都需要用户批准。你可以在设置中搜索 Kiro Agent: Trusted Commands，创建自己的 trusted commands 列表。

Kiro 使用简单的字符串前缀匹配：

• Exact matching：命令必须完全一致，例如 npm install。
• Wildcard matching：使用 * 信任一类命令，例如 npm * 会信任所有 npm 命令。
• Universal trust：单独使用 * 会信任所有命令，极不推荐。

关键风险在于：系统把整条命令当作一个字符串，只检查是否以 trusted pattern 开头。它不会理解 shell 结构、命令链、管道、重定向或特殊字符。

因此，不要把高风险模式加入 trusted commands，例如：

*
rm *
curl *
bash *
powershell *

更安全的做法是只信任低风险、可预测、幂等的命令，例如固定的格式化或测试命令。

本地资源保护

当你使用 GitHub 或 Google authentication 登录 Kiro 时，Kiro agent 仍在本地环境运行，可能访问：

• 本地文件和 repositories。
• Environment variables。
• 环境中的 AWS credentials。
• 其他包含敏感信息的配置文件。

这意味着登录方式不等于权限边界。本地环境里有什么，agent 理论上就可能在任务中接触到什么。

推荐安全实践

1. 隔离 workspace

把敏感项目放在单独 workspace 中，不要把个人项目、客户项目和生产运维脚本混在同一个目录。使用 .gitignore 排除 secret 文件，也可以结合 IDE 的 workspace trust 功能。

2. 使用干净环境

对高敏感任务，考虑使用专门的用户账号、容器或临时开发环境运行 Kiro CLI。只挂载当前任务需要的 repository 和资源。

3. 谨慎管理 AWS credentials

优先使用临时 credentials 和最小权限策略。可以用 AWS named profiles 隔离 Kiro 的访问范围。处理敏感项目时，如果不需要 AWS 访问，就不要把 AWS credentials 放在当前 shell 环境里。

4. 控制 repository access

使用 GitHub authentication 时，检查 Kiro 可以访问哪些 repositories。能使用 repository-specific access tokens 时，不要给过宽的组织级权限。企业管理员应定期审计访问权限。

Remote extensions security

Kiro 支持 Open VSX extensions，也支持 remote SSH extensions。常见选择包括 Open VSX 上社区维护的 Open Remote - SSH。扩展能提供熟悉的开发体验，但也会扩大本地或远程环境的攻击面。

使用远程扩展时建议：

• 只安装可信来源扩展。
• 为远程开发环境使用最小权限账号。
• 不在远程 session 中暴露不必要的 AWS credentials 或生产 secret。
• 定期审查扩展权限和更新记录。

扩展兼容性可查看 extension compatibility guide。

企业落地建议

企业管理员可以把 Kiro CLI 使用分成三层治理：

1. 身份层：优先使用 IAM Identity Center，明确账号、组织和 subscription 边界。
2. 环境层：规定 workspace、credentials、repository access 和远程环境使用方式。
3. 行为层：限制 trusted commands，规定何时必须使用 Supervised mode，要求重要变更通过 review 和测试。

如果还涉及合规审计，可继续阅读 Compliance validation。

常见问题

Kiro CLI 会自动保护我的本地 secret 吗？

不要这样假设。Kiro CLI 在本地环境中工作，本地文件和环境变量需要你自己隔离、忽略或移除。敏感项目建议使用干净 workspace 或容器。

Autopilot mode 是否适合企业默认开启？

不一定。对低风险开发任务可以开启；对生产运维、敏感数据、关键仓库和合规项目，建议默认使用 Supervised mode，并限制 trusted commands。

trusted commands 可以用 npm * 吗？

可以，但要理解风险。npm * 会信任所有以 npm 开头的命令，不只是 npm test。企业环境更推荐精确匹配固定命令。