2026年8月11日，Hacker News上流传着一篇分析，值得每个在工作IDE中使用AI助手的人阅读：一位研究人员将VS Code与GitHub Copilot通过拦截代理连接，并观察到发送到服务器的内容。结果发现，发送的请求中包含的信息远不止您正在输入的那一行——包括开放的.env文件的内容。
好消息是：任何人都可以验证这一点，不仅限于Copilot。以下是一个工作指南，教您如何在20到30分钟内启动对助手流量的审计，查找拦截请求中的内容以及内置文件排除机制的限制。
为什么要自己做
供应商的文档描述的是政策，而不是客户端的实际行为。在“我们不使用您的代码进行训练”和“客户端不将您的代码发送到服务器”之间存在巨大的差距：为了生成提示，模型必须获得上下文，问题在于客户端收集上下文的范围有多广。
如果您：
- 根据保密协议（NDA）工作或处理客户的个人数据，并有义务了解哪些信息超出了边界；
- 在代码库中保存秘密、环境配置、内部地址和令牌；
- 负责团队的合规性，您需要的不仅仅是设置中的屏幕截图，而是实际请求的日志；
- 只是想了解为什么助手突然“知道”您未打开的文件。
在Copilot流量中发现了什么
所讨论的分析基于经典的mitmproxy：VS Code被引导到本地8080端口的代理，并关闭了严格的证书检查。关键发现包括：
- 上下文超出一个文件。 在内联补全中，客户端收集多达20个文件，8个最近更改的摘要，以及每个更改周围的3行上下文，加上当前文件的完整文本和最近编辑的文件的差异。
- 秘密未被掩盖。 在请求体中，
prompt字段包含类似TEST_ENV_VAR_SECRET="mysecretenvvar"的字符串——即来自开放文件的环境变量以普通文本形式发送。 - 本地数据库也暴露。 文件
session-store.db存储user_message和assistant_response，没有加密和编辑：其中包含令牌、云服务提供商的密钥和您曾经插入聊天的连接字符串中的密码。 - 服务调用。 除了补全，客户端还调用
/models、/agents/swe/models、/models/session/intent和GitHub的OAuth端点——通过这些可以清楚地看到助手在生成响应之前如何分类您的请求。
需要特别注意的是：客户端将当前代码库的URL发送到服务器，以获取适用的排除政策。这个事实本身并无害，但它意味着您工作树的组成也是一个信号。
逐步：启动拦截
- 安装mitmproxy并启动它。 只需使用Web界面：
mitmweb。默认情况下，代理监听8080端口，控制台在浏览器中打开。对于CI和长时间会话，使用mitmdump更方便。 - 安装根证书。 在首次运行时，mitmproxy会在
~/.mitmproxy目录中创建CA（文件mitmproxy-ca-cert.cer）。需要将其添加到受信任的证书中——否则客户端将中断TLS连接。在审计期间，用户级别的信任就足够了；之后——删除证书，不要在系统中保留其他CA以防万一。 - 选择拦截模式。 有三种模式，正确的选择可以节省一个小时的麻烦：
- regular——普通代理，客户端明确配置。最可预测的选项。
- local——在同一台机器上透明拦截应用程序，无需修改程序设置：
mitmproxy --mode local:Code只会捕获VS Code进程，--mode local:42——捕获指定PID的进程，--mode local:!curl——捕获所有内容，除了curl。这是监听没有代理设置的助手的最佳方式。 - upstream——链式模式，您的自定义代理位于mitmproxy之后：
mitmdump --mode upstream:http://host:8081，登录名和密码通过选项--set upstream_auth=user:pass指定。
- 将IDE指向代理（对于regular模式）。 在VS Code的
settings.json中："http.proxy": "http://127.0.0.1:8080""http.proxySupport": "override""http.proxyStrictSSL": false——仅在审计期间。此标志完全禁用证书检查，不能在工作配置中保留。
- 成熟地解决证书问题。 Copilot扩展在Node上运行，因此正确的方式是不要禁用检查，而是收集根CA和mitmproxy证书的PEM，并通过环境变量
NODE_EXTRA_CA_CERTS指定。需要重启IDE：该变量在进程启动时读取。 - 将流写入文件。 实时查看毫无意义——每分钟有数十个请求。启用
--set save_stream_file=flows.dump，为了不收集所有内容，通过--set save_stream_filter=...限制采样。然后文件可以离线轻松解析。 - 根据请求体而不是URL进行搜索。 实用技巧：在测试代码库中放置一个包含唯一字符串的哨兵文件（例如，
CANARY_9f3c_DO_NOT_SEND），在编辑器中打开它，在相邻文件中工作——然后在拦截的请求体中搜索哨兵。这样您可以看到您版本客户端实际收集上下文的范围，而不是理论上的。
潜在问题
许可证可能会阻止拦截。 在企业计划中，Copilot会返回类似“您的当前Copilot许可证不支持使用自签名证书的代理连接”的错误。这不是代理的错误——客户端故意拒绝通过自签名CA工作。通过系统级别的受信任证书或为Node构建PEM解决此问题；如果组织政策禁止这样做，审计必须与管理员协调，而不是规避。
固定和QUIC。 部分客户端通过HTTP/3在QUIC上运行，普通代理无法看到。如果在启用拦截后应用程序“运行，但日志为空”——几乎总是因为这个原因：阻止UDP/443以进行测试，客户端将回退到HTTP/2。
遥测和有效负载走不同的路径。 不要仅根据一个端点得出“没有数据发送”的结论：查看进程访问的所有主机列表，而不仅仅是文档中提到的那个。
法律框架。 可以在自己的机器和账户上拦截流量。在未告知所有者的情况下监听他人的工作笔记本电脑——这是另一回事，任何“安全性”都无法为其辩护。
如何处理结果
如果审计显示请求中包含多余的文件，内置工具的表现如下——每个都有明显的限制。
- 内容排除。 GitHub的官方机制，禁止Copilot使用指定路径。仅在Business和Enterprise计划中可用，由管理员在Copilot设置中配置，支持VS Code、Visual Studio和JetBrains；在Xcode、Eclipse和Vim/Neovim中——仅限于内联提示。
- 主要漏洞——代理模式。 文档明确指出，Copilot Chat中的Edit和Agent模式以及Copilot CLI不支持排除。这意味着在助手自行浏览文件、读取配置和执行命令的地方，平台过滤不适用。如果您依赖内容排除作为唯一屏障——在代理模式下没有屏障。
- .gitignore不提供保护。 常见误解：从Git索引中排除并不意味着从助手的上下文中排除。
- 组织最低标准。 秘密存储在秘密管理器中，而不是与代码并排的
.env中；助手的聊天不是插入连接字符串的地方；本地历史数据库应像清理shell历史一样清理。
这里的代理是什么，为什么它对您有用
拦截有实际的延续。首先，upstream模式允许将助手的所有流量通过受控的出口节点：您可以同时看到请求并控制它们从哪个地址发送。这在助手的API在您的地区不可用或企业政策要求固定的外部IP时非常必要——这种场景适合具有固定地址的稳定数据中心代理。
其次，同样的设置适用于调试自动化：当AI代理自行浏览网站时，拦截显示它实际发送的标题以及防护措施如何捕获它。我们在关于Playwright和MCP上的AI代理的代理的材料中讨论了这种组合——那里讨论了代理场景下地址类型的选择，其中需要住宅IP而不是服务器IP。
如果您之前没有启动过mitmproxy，请从HTTPS拦截的基本设置开始——在我们的mitmproxy流量拦截指南中有详细描述，然后在此基础上添加local和upstream模式。
结论
AI助手流量审计不是偏执，而是正常的工程卫生，花费一个晚上一次性完成。Copilot的分析展示了清晰的图景：客户端广泛收集上下文，秘密与代码一起进入该上下文，本地历史以明文形式存储，而内置的排除机制在最危险的代理模式下不起作用。
检查流量而不是文档。启动mitmproxy在local模式下，将哨兵放入代码库，收集流到文件中，亲眼看看您的机器上发送了什么。接下来的决定很简单：您要么有意识地接受这个传输量，要么在外部服务器看到它之前将秘密移出工作树。