Kiro 接入核对：账号认证、模型治理与自定义端点限制

Kiro 原创配置示意，非运行截图

不能把 Kiro 当作通用 API 表单

Kiro 的身份与官方文档已确认，但本次读取的认证和模型治理资料没有给出 IDE 接入任意模型 Base URL 的配置。本篇状态为部分核验，只说明官方账号和治理路径，不编造 Provider 菜单、安装包或环境变量。

官方治理页管理的是 Kiro 已支持模型的允许列表。选择列表中有多个供应商名称，并不意味着用户能填任意兼容接口；模型选择、平台认证和外部服务授权应分别核对。

认证文档区分社交账号、AWS Builder ID、IAM Identity Center 和外部组织身份。IDE 的浏览器登录流程与 CLI 自动化凭证并不相同。团队用户先找管理员确认身份入口、目录地区和许可，不借用个人账号补足组织授权。

Kiro 文档里的 API Key 用于 CLI 自动化，账号和订阅存在范围限制；组织管理者还可能需要开启生成权限。这不是可替换为其他平台 Key 的模型调用接口，更不是 IDE 的通用 BYOK 证据。

管理员应核对当前模型允许列表、默认模型与成员许可。官方提醒治理需要客户端版本配合，列表变化也可能要求重新启动会话或重新登录后加载。某位成员看不到模型时，先检查这些条件，而不是尝试改写内部请求。

若单位要求使用自有模型服务，先索取明确支持当前 IDE 版本的官方说明，包括协议、端点范围、凭证类型和计费边界。在得到依据前保持待确认，不安装冒充官方支持的补丁或登录转接组件。

可以把候选服务整理为需求单，而不是写成 Kiro 配置。比如 https://80321.cn/v1、YOUR_API_KEY、YOUR_MODEL_ID 只是占位，并无真实接口，也不代表 Kiro 支持该地址。

需求单还应写明希望替换的是主模型、辅助模型还是工具服务，是否需要流式和工具调用，哪些代码不能外发。由官方或组织管理员确认范围后，才能选择接入实现；不能把 MCP 工具连接误称为主模型后端替换。

账号失败先核对身份提供方与浏览器授权；模型不可用再核对治理和许可。输出错误报告时隐藏登录状态、Token、项目路径和代码内容，不要求用户分享真实 Key。

官方数据保护页按免费、个人订阅和企业身份区分内容使用及保存政策，不宜写成统一的“零留存”。安全资料还明确，Supervised 是审查流程而非沙箱或访问控制，底层仍可读写文件和执行命令。使用隔离工作区和受保护路径，逐项限制可信命令；本文没有访问账号或进行真实调用。