https://coolbeevip.github.io/tags/security/Recent content in Security onHugo -- gohugo.ioen-usWed, 15 Apr 2026 10:00:00 +0800https://coolbeevip.github.io/posts/harness_engineering/ai-collaborator-safe-isolation-with-harness-engineering/Wed, 15 Apr 2026 10:00:00 +0800https://coolbeevip.github.io/posts/harness_engineering/ai-collaborator-safe-isolation-with-harness-engineering/这篇文章记录一次小范围实践：在 AI 开发时代，如何通过 Harness Engineering 给协作者加上清楚的边界。 问题并不抽象。代码库里已经出现了新的协作者。它可能是 Codex、Claude Code、Cursor。它能读代码、改文件、跑命令、提 PR。风险也随之变化了。关键不再只是“它会不会答错”，而是“它有没有权力改不该改的东西”。 只靠提示词约束不够。上下文会漂移，任务会扩张，模型会误判，人也会口头越权。更稳妥的做法，是把边界从提示层压到执行层。 为什么 AI 协作者更需要隔离 传统团队协作里，权限问题很多时候由人来兜底。一个经验足够的工程师通常知道什么目录不能碰，什么配置不能改，什么操作需要再次确认。AI 协作者没有这种默认判断： 它行动很快，但不天然理解组织边界。 它能执行很多事，但不天然知道哪些事情不该做。 它在单次任务里看起来“理解了约束”，不代表下一轮仍然稳定遵守。 所以安全隔离的重点，不只是“让模型更听话”，而是让越界本身更难发生。这也是这里对 Harness Engineering 的理解：先把边界做成可读取、可检查、可执行的工程约束。 这次实践：把仓库变成一个带边界的执行 Harness 这套机制不复杂，重点是先把最小边界立起来。做法大体有四步：识别协作者身份、加载对应权限、按目录最小授权、把扩权能力留在人手里。 1. 用 Git 身份识别当前协作者 进入仓库后，先读取： git config user.name 这里把这个值当作协作者身份入口，而不只是提交记录上的一个名字。后续权限文件直接按这个名字映射，比如： docs/access_policy/<user.name>.md 这样做的好处很直接：人类和 AI 可以共用同一套身份入口。 2. 默认只读，而不是默认可写 如果没有找到与 user.name 对应的权限文件，就回退到： docs/access_policy/default.md 默认策略里没有任何 Writable Dirs，也就意味着整个仓库只读。 这样做把安全模型从“默认信任，出问题再收缩”改成了“默认拒绝，明确授权后再开放”。对 AI 协作者来说，这比单纯依赖提示词稳得多。 3. 权限按目录白名单定义 每个协作者都有一个独立的权限文件，里面至少定义四部分： Identity Writable Dirs Read Only Dirs No Read Dirs Rules 这意味着协作者拿到的不是整个仓库的写权限，而是自己负责区域的写权限。这样至少能缩小误改和误操作的半径。 4. 策略文件只能由人维护，AI 不能自行扩权 这套机制里最关键的一条，是“谁有资格改授权”。docs/access_policy/ 被明确设为人类维护区，并在 AGENTS.