AI 编码代理的安全缺口，有人用一根「缰绳」堵上了
AI 编码代理正在以历史性速度被接入开发流程。但安全团队看到的是另一面——大多数组织对 Agent 写代码这件事，态度是「先试试，别出乱子」，因为没人能说清楚怎么给一个自主行动的 Agent 上好安全锁，更别说把这些锁均匀地分到每个开发者的桌面上。
7 月 28 号上 arXiv 的一篇论文，直接对着这个痛点去的。题目很老实——"Distributing Security Controls Through Harness Engineering"，作者 William Robert Gore。论文问的是：能不能用一个可分发的 Agent 缰绳（harness），把安全控制嵌进去，一条命令铺到整个团队，效果还不输给直接在商业 Agent 上配安全策略？
安全控制可以跟 Agent 解耦
论文提出了一套叫 SHarD（Secure Harness Distribution）的方案，基于 Pi agent harness 构建。它嵌了三层安全控制：OS 沙箱、技能扫描、工具限制。这三样都是 off-the-shelf 的东西。关键是把它们打包进一个 harness，一条 install 命令就能拿到，不依赖特定 Agent 厂商的原生方案。
现在市面上的商业编码 Agent 不是没有安全功能，但要么锁在厂商生态里，要么安全团队配好了却没法保证每个开发者都用同一套配置跑。SHarD 的做法是把控制层从 Agent 本身抽出来，放到 harness 层——用什么 Agent 都行，控制逻辑在 harness 这层统一执行。
论文用了 4 组 Agent 配置做对比测试——两个商业 Agent（分别有/无安全控制）、一个基线 harness、一个安全加固后的 harness（即 SHarD）。测试集来自 OWASP Top 10 for Agentic Applications，一共 23 项。
结果：SHarD 调整后的得分是 100%，跟配置最好的商业 Agent 持平，所有测试类别没有回归。harness 方案在安全性上没妥协。
两个有意思的观察
论文提了两个发现，比分数本身更有意思。
第一个，模型非确定性会导致安全结果不一致。同样的 Agent、同样的控制配置，两次跑可能结果不一样。这不是 bug，是 LLM 推理的固有随机性。如果靠 Agent 自己判断「这步能不能做」，它可能这次拒绝、下次就干了。SHarD 的做法是把判断从模型手里挪到 harness 层——OS 沙箱、工具白名单不由模型决定，模型怎么说都绕不过去。
第二个，自主 Agent 的行为会跨系统边界，OS 沙箱直接就能兜住。Agent 本来就是为了「自己操作」而设计的，要读文件、写代码、调 API，边界天然就模糊。OS 沙箱是最朴素的兜底手段，但之前很少有人认真论证它跟 Agent 安全控制的关系。
论文也留了个尾巴：提出了一个控制 harness 适配性框架的初步特征，并指出了第三个待研究的问题。没有把话说满。
对谁有用
正在带团队用 AI 编码 Agent 的人，或者给团队配开发环境的安全工程师，这篇论文的思路可以直接参考。SHarD 基于 Pi agent harness 构建，代码和测试方法都可以复现。不需要等 Agent 厂商出企业版安全功能，自己就能搭一层控制。
当然，这不是银弹。23 项 OWASP 测试覆盖的是已知攻击面，不是全部。模型非确定性的问题在 harness 层也只能缓解、不能消除。但至少它给了团队一个可操作的方向：安全控制可以跟 Agent 解耦，可以分发，可以一条命令铺开——而不是靠每个人自己记得打开某个开关。
如果还在为「怎么让安全团队同意我们用 Agent 写代码」头疼，这篇论文是个不错的参考。
相关链接
- 论文 PDF：https://arxiv.org/pdf/2607.25890
- HTML 版：https://arxiv.org/html/2607.25890v1
- OWASP Top 10 for Agentic Applications（测试来源）