同事在用，不是安全背书

“我同事在用”这句话，在安全这边不值半分钱。它证明不了他看没看过那个 MCP server 申请了哪些工具权限，证明不了他有没有顺手点了“跳过所有确认”，更证明不了他机器上几把 key 该不该挂进 agent 的上下文。

上个月挂上 arXiv 的那篇（编号 2607.01418）把传播参数补上了。论文研究的是微软 2026 年初向数万名工程师铺开 Claude Code 和 GitHub Copilot CLI 的过程：命令行 AI 编码代理的最初采用，基本就是沿着社交网络走的。先上手的工程师把它带进自己的小圈子，再一环一环往外传。能不能持续用下去，跟人口统计特征关系不大，跟日常编码活动的强度倒绑得挺紧——四个月观察窗口里，工具带来的提升一直没掉。传到第五个人手里的时候，他接收到的已经不是“第一个人检查过这个 MCP server 的权限配置”，而是“第一个人觉得这工具不错”。第一个人往往也没检查过——他只是用着顺手。一条链条上每个人都在转嫁信任，没人真正验过货。

论文里还有个数：采用工具的工程师，合并的拉取请求数量比未采用时预计多约 24%。这个数字挂在产出指标上的时候，很容易被顺成“这工具真行”。但它度量的是合得快不快，度量不了权限边界有没有被配乱——agent 明明只该读，结果挂着写权限；该走隔离网络出口，结果连的是内网。这些不会体现在 PR 数量里，它们体现在审计日志里，而审计日志永远是最后被看的那份东西。论文自己也承认：合并 PR 数量不等于实际价值。

换成攻击者的思路，这简直是最理想的传播模型。你不需要攻破任何人的配置，只要让前面两三个人觉得“方便”，后面的人会自己走进来。每个新用户都是一次免费的信任传递，攻击者一个字节都不用发。攻击链画下来就四步：

诱饵（顺手好用的 MCP server）→ 触发（第一个用户没校权限就装上了）→ 执行（同事看他天天用，第二、第三个人照抄配置，社交背书这时候比安全评审好使）→ 外带（需要数据的那个节点出现时，没人拦它）。

论文结尾建议把“可见的同伴使用”摆成推广策略的核心——这条对推广负责，不对安全负责。推广可以继续，加三道硬门槛就行：新工具进团队，先过一遍它申请的工具权限和网络出口，再谈上手；agent 上下文里的 key 按“丢了不心疼”的标准发，别按“反正能用”的标准发；“跳过所有确认”只在没 secrets、没外网、没生产权限的机器上开。“同事都在用”是传播策略，不是安全背书。

排雷记录：最贵的那次信任，往往来自最便宜的背书。