AI 代理数据泄露：代理知道你哪些信息，又会从哪里流出去

AI代理（替你干活的AI）能读文件、调用工具、上网搜索，还能替你提交代码。要做到这些，它得先拿到一堆上下文：指令、文档、设置，往往还有一些关于你本人的信息。上下文让代理变得好用。可同样是这些内容，代理往外发东西的时候，它们也可能跟着出去，去到你没打算让它们去、也从没检查过的地方。

AI代理数据泄露，是指代理上下文里的信息，经由代理自己的某个输出流到了外部，比如一次网页请求、一条代码提交、一个文件、一次工具调用或一段日志。这里面通常没有黑客，也没有哪个密码被破解。代理只是在做它的本分：用手头的材料拼出文字，而其中一部分文字到了第三方手里。所以更该问的是：代理能看到什么，它的哪些输出会经过模型以外的检查。供应商靠不靠得住，倒在其次。

本指南依次讲：代理上下文里通常装着什么；这些信息能从哪些渠道出去；为什么写在提示词里的规定拦不住；GDPR对数据最小化有什么要求；以及哪些办法能在程序层面起作用。文中用2026年的一个有据可查的案例作说明：一款编程代理把账户邮箱带进了对外的网页请求。选它是因为记录特别完整，厂商也修得很快，并非要评判谁。发布本文的Karma Box在卖一款在本地硬件上运行AI代理的工作台。讲到它的那一节单独标明，用的也是和别家一样的检验标准。

01什么是AI代理数据泄露，它和数据被盗有什么区别

通常说的数据被盗，是有人闯了进来：凭证被偷、数据库暴露、服务器被攻破。代理造成的泄露正好反过来，没有人闯进来。信息本来就是合法交给代理的，它通过代理被允许使用的渠道出去，出去时的样子没人检查过。

这一区别决定了防线该设在哪儿。防盗看的是边界：谁能登录、哪些端口开着、哪些密钥有效。代理泄露发生在边界之内，发生在正常运行当中，借的是有意授予代理的权限。开联网搜索，是因为任务要查资料；给 git 权限，是因为任务要写代码。泄露走的，恰恰是那些对这份工作来说完全正当的权限。

它也决定了谁会先发现。数据被盗往往会留下安全工具专门盯着的痕迹：异常登录、大批量下载、访问已知的恶意地址。代理往请求头里塞了一条个人信息，产生的流量和它平时的每一次请求看上去没什么两样。最先出现的信号可能很间接。下面这个案例里，用户最先察觉到的，是诈骗邮件突然变多了；把两件事联系起来，靠的是一份缺陷报告。

还有一点不同：这类信息往往谈不上绝密，只是不该让大多数人看到。邮箱地址、公司名、项目代号、内网网址，放在对的地方都没问题。麻烦在于代理并不总能分清哪里是对的地方。后文要讲的「数据最小化」，就是这件事在法律上的解法：只给系统它的用途真正需要的个人数据，不在场的东西，自然也就带不出去。

很多团队把代理权限理解成一张能力清单：能不能上网、能不能提交、能不能发邮件。这张清单当然重要，我们此前那篇私有AI的能力悖论讲过，能力越强，触达越广。泄露问题还牵出第二张更容易被忘掉的清单：代理在使用这些能力的时候，脑子里装着什么。

02AI代理的上下文里通常装着什么

AI代理的上下文，指模型在决定下一步做什么时能读到的全部内容。其中一部分是用户敲进去的，很多则是由模型外面那层程序拼装进去的，用户并不知道。这层程序常被称作「harness」（代理运行框架），负责启动模型、把指令和文件递给它、执行它发起的工具调用，再把结果送回去。

其中有两层特别容易被忽略。一是系统提示词。大多数产品不给用户看，版本更新时它可能悄悄改了也没有公告。框架要是往里面加了一个账户字段，用户在正常使用中几乎没有办法知道。二是工具返回的结果。代理读过的每一个网页、外部工具送回的每一段内容，都会变成上下文。不可信的文字，正是借这个口子影响代理接下来的行为。

记忆是第三个来源，而且越积越多。记得以往会话的代理，会把人名、偏好和过去工作的片段一路带下去。这很有用，同时也意味着后面每一项任务都能取用这批材料。代理记忆该由谁掌控，我们在代理记忆应该归你一文里讨论过。这里关心的范围更窄：记忆里有的东西，代理都可能把它输出出去。

运行环境是最不显眼的一层。一条打印路径的命令，可能就把用户名露出来了；git 配置里存着姓名和邮箱；配置文件里可能有用户标识和机器标识。这些在通常意义上都不算机密，而代理的输出离开本机之前，它们一般也不会被谁检查。

03上下文里的信息会从哪些渠道流出去

代理有多少个工具，就有多少条出路。每一个会往别的系统发东西的工具都是一条渠道，每条渠道上又有不少地方能顺带夹进文字：请求头、查询参数、请求正文、提交说明、文件名。

网页请求是最直接的渠道。代理搜索或打开网页时，请求会带上 User-Agent 等请求头，被访问的每个网站都会记下来。提交和拉取请求是最难撤回的渠道：提交一旦推送，就会被复制到每一份克隆里，很难从历史里抹掉。文件是花样最多的渠道：生成的配置、测试样例、说明文档，都可能夹带一个本来只该被读的值。调用其他工具，包括 MCP 服务器（一种把代理接到外部工具上的常用协议），会把参数发给别人运营的系统。日志和会话记录是最慢的渠道，任务结束很久以后，它们还可能被存档、同步或分享出去。

这些渠道难管，是因为里面的内容由代理来写。一位开发者设定 User-Agent，挑一次值，之后一直沿用。模型则是每次现场生成，用的是它当时手里的上下文。同一个代理，这次会话发出的请求头干干净净，下次会话就可能夹着一个邮箱地址，取决于它拿到了什么、又推断出了什么。

案例：账户邮箱出现在对外请求里（2026年7月至11月）

2026年7月25日，有用户在 Claude Code（Anthropic 公司的命令行编程代理）的公开 GitHub 仓库里提交了 #81138 号问题。报告说，Claude Code 会从用户本机配置中读取账户邮箱，在每次会话时写进模型的系统提示词，内容就是一句「用户的邮箱地址是……」。报告人是通过分析发布出来的程序发现的。按报告的说法，这一行为没有任何文档说明，也没有可以关掉的设置；唯一有文档的隐私选项是演示模式，它能让邮箱不显示在屏幕上，却没有把邮箱从模型的上下文里拿掉。

报告接着列了用户亲眼见过的两个后果。一次是模型在回复里主动写出了这个地址，没有人问它。另一次是模型在十次提交中通过命令行把这个私人地址传给了 git，覆盖了早已配置好的「不公开邮箱」身份；推送之所以没成，只是因为 GitHub 的推送保护把它拒了。报告人用一句话概括了问题：「模型上下文里的任何东西，都是它可能输出的材料。」这个问题到十月一直有其他用户跟帖，撰写本文时仍处于打开状态。

2026年11月5日，又有用户提交了 #107757 号问题，说同一个地址出现在了另一个地方。用户写道，Claude Code 在搜索时发出的网页请求里，User-Agent 请求头带着自己的邮箱，自己现在每天收到几十封诈骗邮件，并表示要把公司迁到别的工具上。当天 Hacker News 上关于这份报告的讨论达到450分、157条评论。一位评论者描述，那个请求头的样子是会话名后面跟着尖括号括起来的用户邮箱。

Anthropic 当天就在问题下作了回应。一位贡献者写道，2.1.317 及之后的版本加入了一个名为 cc-plugin-privacy 的内置模组，会「确定性地」拦截这种行为；它默认开启，可以在插件菜单里关闭；他们还会争取公开这个模组的源码。

讨论里也有不同意见。一位评论者认为，问题出在模型自己用上下文里找到的地址拼出了请求，而框架没有拦住，并不是搜索工具里写死了这个值。他指出，修复的办法是在框架里加了确定性拦截，这与他的判断相符。另一位评论者则怀疑诈骗邮件和请求头到底有没有关系，因为邮箱地址常常是从别处被抓取的。这两点都应该保留：前者解释了修复为什么有效；后者提醒我们，即便机制确实存在，单个用户的收件箱也很难证明因果。

把两份报告放在一起，可以看出一个规律。地址经由框架进入上下文，几个月里先后从提交和网页请求两个不同的出口出去，两次都不需要黑客。厂商的修复，也是直接加在框架这一层的。

04为什么在提示词里写规定拦不住泄露

遇到这类事，人们的第一反应往往是加一句指令：请求里永远不要带我的邮箱，提交时永远不要用我的私人地址。指令有帮助，但堵不上这条渠道。原因有三，七月那份报告里也都提到了。

第一，「在场」和「使用」是两回事。指令管的是模型该怎么用它手里的东西，管不了它手里有什么。只要地址还在上下文里，往后的每一次输出都是它冒出来的机会，而指令必须每一次都赢。报告人的说法是，这样的指令「管的是使用而非在场，并且取决于模型是否遵守」。

第二，模型的行为不是确定的。同一个模型、同一条指令，这次会话照做，下次会话就可能走样，尤其是会话很长、大量文件和工具结果争夺注意力的时候。对写作风格来说，这可以接受；对隐私来说，这个基础太弱，因为出一次错就够了。

第三是提示词注入，也就是来自不可信来源、试图操纵代理的文字。代理读到的每一个网页、依赖包里的每一份说明、每一条问题评论、每一个工具结果，都是输入。其中任何一段都可能藏着冲着模型去的指令，比如要它在发往某个地址的请求里带上某项信息。用户的指令和陌生人的指令，挤在同一个上下文里较劲。七月那份报告把这个推理的终点说得很直白：不在上下文里的数据，就无从外泄。

这并不等于提示词对安全毫无用处。它能在大多数情况下塑造行为，让失误少一些。问题在于，一项依赖模型配合的管控，总有失手的时候；而程序层面的管控，不管模型怎么决定，都会检查或拦截输出，在它覆盖的范围内每次都起作用。隐私需要的是后一种。

05GDPR对数据最小化和默认保护有什么要求

欧洲数据保护法里有两条原则，直接适用于代理的上下文。它们写成的时候还没有AI代理，却很对得上这个问题。

GDPR第5条第1款(c)项规定了数据最小化原则：个人数据应当「充分、相关，并以处理目的所必需为限」。用来登录的邮箱，对身份验证来说是必需的；它放在模型的上下文里、又没有任何功能去读它时，是否仍属必需，是另一回事。七月那份报告认为不属于。

第25条把这项原则变成了工程上的义务。数据控制者必须采取技术和组织措施，这些措施要「旨在有效落实数据最小化等数据保护原则」。第2款又规定了默认要求：「在默认情况下，只处理为每一具体处理目的所必需的个人数据」，这一义务「适用于所收集个人数据的数量、处理的范围、存储的期限及其可访问性」。该款还要求，在默认情况下，未经本人介入，个人数据不得被提供给不特定的多数人。

GDPR在这里有两点限制。其一，GDPR适用于其管辖范围内的控制者和处理者所处理的个人数据；某个工具、某家公司、某种用法是否落在范围内，属于法律问题。本文是技术参考，不构成法律意见，也不判断任何具名厂商是否合规。其二是实际层面的：法律规定的是默认状态下应当如何，没有规定框架该怎样拼装上下文。下面讲的就是拼装和管控的做法。

对在工作中使用代理的公司来说，员工的工作邮箱同样是个人数据。把代理接上公司账户的团队，同样要面对「什么进上下文、什么出上下文」的问题，而且每个工具都要问一遍。代理在公司里有了自己的身份之后会怎样，见代理拿到公司邮箱一文；本文讲的是这个身份可能泄露出什么。

06如何在程序层面拦住泄露

靠得住的管控有一个共同点：不指望模型自觉。它们要么决定模型能看到什么，要么在内容离开之前检查一遍。

最有效的办法，是让数据根本不进来。框架如果不把账户邮箱放进系统提示词，那么无论什么指令、注入或者走样，都没法让模型把它输出。这就是在源头落实最小化原则。身份字段应当默认不放进上下文，少数确实需要的任务，再通过明确的设置打开。运行环境也一样：git 身份可以用不公开的邮箱，路径里可以避开真实姓名，配置文件里可以存不透明的标识，而不是邮箱地址。

判断一项隐私设置管不管用，要看它作用在哪一层。七月那份报告里的演示模式就是个例子：它把邮箱从屏幕显示和状态输出里藏起来了，可模型的上下文里照样有这个地址，模型的回复又会打印到同一个正在被录屏或直播的终端上。只改显示的设置，护住的是屏幕前的观众；要护住第三方网站和代码仓库，设置必须改到上下文或出站这一层。评估任何「隐私模式」时，都可以直接问厂商：开启之后，这个值还在不在模型的上下文里？

第二个办法是出站过滤。代理发出的请求，在离开本机之前先经过一层检查，看请求头和正文里有没有像个人数据的内容，有就删掉或者直接拦下。按厂商的描述，前面那个修复就是这样工作的。过滤的效果取决于它的规则，所以它用来补充「不让数据进来」，而不能替代它。不过它有一个好处：那些从没人预料到的地方进入上下文的值，比如代理读过的某份文档里的信息，它也能拦住。

第三个办法，是对难以撤回的写操作设审批。有些输出很容易撤销，比如一份本地草稿；有些则不然，比如推送出去的提交、发布的软件包、发出的邮件。要求人工批准这类操作，或者至少让人先看一眼要写出去的内容摘要，就把自动化流程拿掉的那道复核找回来了。七月那份报告里，是 GitHub 的推送保护碰巧承担了这个角色。团队完全可以有意把它设好。

第四个办法，是把日志和会话记录也当作输出对待。它们往往包含代理看到过的全部内容。存在哪里、谁能看、保存多久，和本站讨论过的AI对话记录存在哪里是同一类问题。日志在同步或分享之前先把身份字段脱敏，就堵上了最慢的那条渠道。

凭据要单独处理，因为不管从哪条渠道漏出去，泄露的密钥都会以另一种方式造成损失。密钥该放在哪里，见我们的AI密钥自托管清单。放到代理这里，原则很简单：密钥应当存在框架调用时才去读取的地方，模型永远不该以文字形式看到它。

07如何检查自己的代理会发出什么

做这项检查不需要专门的工具，有一个你自己控制、能记下收到什么的地方，再列一张要找什么的短清单就够了。

最简单的方法是本地网页服务。在 127.0.0.1 上起一个小服务，把每次请求的请求头写进文件，然后在一项普通任务里让代理去访问它，再读日志。如果 User-Agent 或其他请求头里出现了个人信息，这条渠道就是开着的。这个方法是一位 Hacker News 评论者在十一月的讨论里提出的，好处是查的是真正离开机器的东西，不必依赖文档怎么说。

2026年11月6日，Karma Box团队在一台 Apple M4 Mac mini 上跑了这项测试中服务器那一半，用来展示这种日志长什么样。这是用普通命令行工具演示机制，并不是复现 Claude Code 的行为。一次普通的 curl 8.7.1 请求，到达时的 User-Agent 是「curl/8.7.1」。第二次请求的 User-Agent 由一个存着占位地址 [email protected] 的命令行变量拼成，服务器原封不动地记下了这个地址。一次 Python 3.9.6 的默认请求，到达时是「Python-urllib/3.9」。要看的是第二行：请求头里装的是拼它的程序放进去的任何东西，而接收的服务器会把它留下来。

读日志时，别只盯着 User-Agent。查询参数里可能有代理根据某份私密文档拼出来的搜索词；Referer 请求头可能暴露代理之前访问过的内网地址；发给某个 API 的请求正文，可能包含整段上下文。测试时要选一项真正会碰到你关心的那类数据的任务，代理对着一个练习文件干活时，本来就没什么敏感内容可发。每次更新后也要重测，因为框架和模型都可能在版本之间发生变化，而你这边什么都没动。

第二项检查是扫描身份字段。在代理的配置和工作区里搜索存放邮箱或账户名的字段，以及形如邮箱的字符串。同一天，团队扫描了撰写本文所用的那个代理的配置和工作区，共668个文件。扫描只打印文件名，从不打印值。结果是：没有名为 emailAddress 或 userEmail 的字段；配置里存有一个用户标识和一个机器标识；文本文件里唯一一个形如邮箱的字符串，是旧文章里一个 example.com 的占位地址，其余匹配都是图片文件里的随机字节。这个结果说明不了其他产品的情况，它只说明：这项检查几分钟就能做完，结果也具体到可以直接采取行动。

第三项检查是 git 身份。看清代理的提交会带上什么姓名和邮箱，仓库级和全局两处都要看，再和你的本意对一对。七月那份报告说明了为什么：模型在命令行里覆盖了一个配置正确的不公开身份。凡是代码托管服务提供推送保护、能拒绝含私人邮箱的提交的，都值得打开。

最后，如果产品允许，就去读一读系统提示词。有的工具会展示它，有的会公开它。两样都做不到时，退而求其次是厂商关于「哪些内容会被加进上下文」的文档；如果连这样的文档都没有，也要把这一点记下来。

08评估AI工具时应向厂商提哪些问题

认真考虑过这个问题的厂商，很快就能答上下面这些问题。

问一问框架会自动往模型上下文里加什么，账户信息在不在其中。问这项添加能不能关闭，关闭是不是默认状态。问对外请求有没有经过过滤，过滤检查什么，规则或源码有没有公开。十一月那次修复被描述为确定性的、默认开启的，方向是对的。问提交、推送、发布软件包、发送消息能否设置审批。问日志和会话记录怎么存，同步之前身份字段有没有脱敏。

还有一个问题，往往最能看出东西：你们改变上下文内容时，客户怎么才能知道？七月那份报告，是读了发布出来的程序才发现问题的。如果有一条更新日志，或一份写明上下文包含哪些字段的文档，就用不着这样做了。同时评估几款工具的团队，可以对每款都问同一组问题；我们那份更全面的AI供应商主权评估清单，把它们和数据驻留、退出等问题放在了一起。

09这些管控解决不了哪些风险

让身份信息不进上下文、过滤对外流量，解决的是一种风险：个人数据通过代理的正常输出流出去。其余几种风险它们管不到，最好分开说清楚。

它们管不到模型提供方怎样处理收到的上下文。代理如果调用托管模型，整份上下文，包括其中仍然存在的个人数据，都会送到那家提供方手里，适用对方的留存与训练条款。这属于供应商问题，也是一些团队在本地运行模型、或把敏感任务交给自己托管的模型的原因。

它们也不能完全解决提示词注入。把个人数据从上下文里拿掉，被注入的指令能偷走的东西就少了；但被注入的文字照样可以改变代理的行为，比如删掉一个文件，或用有害的参数调用某个工具。这需要限定哪些操作压根不被允许，并对后果重大的操作设审批。

它们够不着已经出去的数据。被一千个网站记下的请求头，会一直留在那些日志里；已经推送、被克隆过的提交，会一直留在那些克隆里。今天加上的过滤，只保护今天以后的请求。

它们也不能免去认真挑选工具这件事。过滤是一组规则，规则总会有漏网之鱼。新的输出渠道，比如给代理新加的一个工具，可能根本不经过过滤。本文讲的这些管控能降低泄露的可能，不能让泄露变得不可能。

10KarmaBox能解决什么，不能解决什么（产品说明）

KarmaBox是一个工作台，分身（各自负责某一类工作的AI代理）可以在你自己办公室的一台设备上运行，详见KarmaBox产品页。按产品页的说法，每个官方分身都有自己的边界，并且「由服务端强制执行，而不是靠提示词」；平台的权限模型把操作分为允许、需先询问和拒绝三类。这台设备配有128 GB统一内存，功耗约170瓦；它和云端、普通电脑方案的对比，见本地AI硬件页面。

这里要看的是边界设在哪里。由系统强制执行的权限，属于上文所说的程序层面的管控，不依赖模型自觉。工作台运行在团队自己控制的硬件上，也意味着文件、配置和记忆都留在那台机器上，除非某项任务把它们发出去。这正是主权AI工作空间落到实处的意思。在跑编程代理的研发团队，可以从研发解决方案页面看起。

对KarmaBox，也请用和其他产品一样的方法来检验。请用KarmaBox文档核实：在你的配置里，哪些内容会进入分身的上下文，哪些工具能往外发数据，其中哪些需要审批。然后跑一遍上文的本地请求头测试和身份字段扫描。KarmaBox同样提供云端选项，调用托管模型的分身会把上下文发给相应的提供方。多模型路由可以把敏感任务留在本地模型上，但前提是你确实这样配置了。本地硬件也有它自己的义务；当供应商终止服务时该怎么办，见我们的AI工具停服应对指南，那讲的是同一个选择的退出一面。

11常见问题

Karma Box 团队发布有关 AI 主权、工作台控制与供应商评估的实用指南。本文直接引用两份公开的 GitHub 问题报告和厂商的回应，保留了对成因持不同看法的评论，把本地机制演示和对其他产品的任何判断分开，并把同样的检验标准用于 KarmaBox。本文不构成法律意见，也不判断任何厂商是否遵守了数据保护法。来源核对日期为 2026 年 11 月 6 日。