AI无法给自己松绑：Kiro Crew两级Policy ∩ Profile治理上限完全解析

AI无法给自己松绑Kiro Crew两级Policy ∩ Profile治理上限完全解析【免费下载链接】KiroCrewA persistent workspace for development work that self-improves and continues beyond one session.项目地址: https://gitcode.com/gh_mirrors/ki/KiroCrewKiro Crew 是一个可跨会话持续工作、并能自我改进的 AI 开发工作台它用两级「Policy ∩ Profile」治理模型给 AI Agent 上权限天花板第一级 POLICY 是企业级安全上限第二级 PROFILE 只能按场景把权限收窄两者取交集、最严格者优先——这正是「AI 无法给自己松绑」的核心机制。一、Kiro Crew 是什么一个会持续工作的 AI 开发工作台Kiro Crew 的定位一句话概括A persistent workspace for development work that self-improves and continues beyond one session.一个能自我改进、并延续到单次会话之外的开发工作持久工作区它不只是聊天机器人AI 成员可以读写代码仓库、执行 shell 命令、接入 Slack 等聊天频道、创建定时任务甚至跨会话记住项目上下文。能力越大「围栏」越重要——Kiro Crew 的答案就是这套两级 Policy ∩ Profile 权限治理。二、设计第一原则AI 不能修改自己的权限天花板Kiro Crew 的威胁模型建立在三个前提上见 security-deep-dive.md模型是不可信输入不是可信调用方。最大威胁是提示注入Agent 读到的网页、文件、聊天历史对操作者是「数据」对模型却可能是「指令」。操作者可信Agent 不可信。操作者可以放宽自己的策略Agent 永远不能替他放宽。任何单一层都不假设能守住。OS 沙箱、路径门、命令门、输出脱敏各自以不同方式失败、彼此不相关。由此推出的第一设计问题是如何让权限天花板本身对 AI 不可触碰答案是「keystone基石路径保护」机制治理文件security_policy.json、profiles/目录、admission_policy.json全部位于敏感路径读写双重封锁之下所有工具调用先经过 Kiro Crew 自己的 PreToolUse 门门属于宿主不属于 Agent敏感路径检查先于任何自动批准快车道执行效果Agent 连自己被套了哪些「紧箍咒」都读不到更无法改写——一个能被替换的上限不算上限。三、两级治理模型详解Policy ∩ Profile最严格者胜完整规范见 governance.md核心是一个公式effective POLICY ∩ PROFILEtightest-wins最严格边界胜出第一级POLICY —— 企业安全天花板GovernanceCeiling在启动时从信任根路径如~/.kiro/crew/security_policy.json一次性加载加载完成后应用与 Agent 都无法弱化它来源有严格优先级中心化下发文档 环境变量路径 版本内置文件 本地家目录文件 无策略安全默认值低层文件只能收紧高层绝不能放宽——下位文件想「推翻」上位策略是行不通的。第二级PROFILE —— 场景化收窄只能更紧Profile绑定到具体surfacecron / slack / dashboard / subagent / host、app或task解析顺序app 绑定 → task/agent 绑定 → surface 绑定最具体的优先按文件修改时间热重载改完即生效、无需重启失败关闭Profile 文件损坏或不可读时该场景降级为「全部拒绝」而不是退回宽松上限。权限判定怎么合成所有受管控制项归入 4 种原型ScopedRuleset、OrdinalControl、CapabilityGate、ScopedMap求交规则统一allow 取交集、deny 取并集、序级如沙箱等级 off standard cc strict取最严、能力开关取 AND。四、实战示例一份企业 Policy 能锁住什么仓库提供了开箱即用的示例 security-policy.example.json{ version: 1, boot: { fail_closed: true }, network: { egress: { mode: allow, allow: [*.amazonaws.com] } }, commands: { mode: deny, deny: [curl*://*, wget*://*, nc *] }, approval_modes: { mode: deny, deny: [yolo] } }这一份文件就能做到控制项效果network.egress限定 Agent 的 fetch 工具可访问的主机白名单commandsdeny拒绝指定 shell 命令模式且成为不可取消的强制锁定——用户在本地关掉某条内置规则也没用approval_modesdeny yolo全队封禁自动批准模式YOLO已激活的授权也会被立即吊销sandbox.min_level为 OS 沙箱设等级下限本地配置只能更严updates钉住自更新来源与最低版本——自我更新是「改写所有其他天花板」的最大权限操作必须受控distribution中心化下发全队机器定时从同一地址拉取同一份上限五、Profile 如何绑定到具体场景按 surface / app / task 收窄Profile 是针对某个场景的「收窄圈」以多频道对话管理为例绑定规则一句话版绑 surface如surface:cron的 Profile 只关定时任务的对外消息能力capabilities.messaging聊天界面完全不受影响绑 app / task某个应用或某次任务获得专属 Profile比 surface 级更细无人值守 身份未证明的场景未绑 Profile 时默认拒绝全部fail-closed而不是默认宽松。六、中心化下发与热更新改一处全团队生效distribution是「企业级分发」的开关引擎实现见 policy_distribution.py每台机器保留「最后已知良好」缓存中心端点短暂故障时用缓存副本继续治理网络抖动不会造成治理真空fail_closed 为默认缓存过期又连不上中心时拒绝启动而不是「无上限裸奔」签名校验Policy 可携带identity.signatureHMAC-SHA256。开启require_policy_signature后验签不过的文档直接拒载——防止本地篡改与传输替换热交换刷新线程周期性拉取新上限走完「校验 → 发布 → 安装」三步后才替换无需重启后续每一次判定立即按新上限执行被拒的坏文档永远不会进入缓存。七、查看与诊断治理状态的 3 个入口仪表板 Settings → Security只读治理查看器展示当前哪些作用域受管、严格程度如何。注意它刻意只展示「姿态」而从不展示具体规则内容——因为仪表板可被 Agent 的浏览器工具访问泄漏 deny 模式等于让 AI 学会绕过kirocrew policy show打印上限的「已证明来源」signed and verified / signed but UNVERIFIED / unsignedkirocrew policy explain scope item追溯某次判定的规则、层级与理由——排查「这个操作为什么被拒」的第一站。此外每一次允许/拒绝都会写入 HMAC 链式、仅追加的安全事件日志SEL治理行为事后可完整追溯。八、新手操作建议清单✅ 单人使用可以不开 Policy安全默认值已够用先写一个surface:cronProfile 体会收窄效果✅ 团队使用先写最小可用 Policyboot.fail_closedcommandsapproval_modes再逐步加上distribution与签名校验✅ 凭据不要写进 Policy 文档——逐机的请求凭据应走环境变量通道分发的文档里不能带机密✅ 记住「Profile 只能更紧」想放宽请改上层 Policy在 Profile 里放宽是无效的⚠️ 别把治理当作万能锁文档在「Known gaps」中如实列出了已知残余缺口如默认无出站网络边界运维前应通读一遍。延伸阅读治理模型完整规范docs/system-specs/modules/governance.md安全架构深度解析docs/architecture/security-deep-dive.md架构总览docs/architecture/overview.md核心评估器源码src/kiro_crew/platform/governance.py、src/kiro_crew/platform/governance_profiles.pyPolicy 配置示例docs/guides/assets/security-policy.example.json【免费下载链接】KiroCrewA persistent workspace for development work that self-improves and continues beyond one session.项目地址: https://gitcode.com/gh_mirrors/ki/KiroCrew创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考