一篇被 ECCV 2026 主会初步接收的工作，把移动端 Agent 的隐私风险推进到了一个更底层的位置：屏幕感知链路。

这篇论文叫 DualTAP: A Dual-Task Adversarial Protector for Mobile MLLM Agents。

https://arxiv.org/pdf/2511.13248

https://fyzhang1.github.io/DualTAP/

它讨论的不是提示词泄露，也不是工具越权调用，而是一个越来越现实的问题：当 Agent 为了替用户完成任务，开始持续“看屏幕”时，屏幕本身就会成为新的隐私出口。

这件事放到今天看，和 AgentOS 的演进是能接上的。

如果说过去的 App 时代，屏幕主要是“人和应用”的交互界面；那么在 AgentOS 或端侧 Agent 的语境里，屏幕会越来越像一种系统级上下文。Agent 想理解用户当前处在什么页面、下一步应该点哪里、是否进入新的状态，就必须持续读取屏幕。问题在于，屏幕并不只包含任务信息，也同时承载了大量个人隐私、账号信息、聊天内容、订单记录、地理位置和业务上下文。

这正是 DualTAP 要解决的问题：当屏幕截图需要发送给外部多模态模型或第三方 Router 时，如何在尽量不破坏 Agent 可用性的前提下，降低截图中的隐私泄露风险。

从移动 Agent 到 AgentOS：屏幕正在变成系统级上下文

移动端 Agent 和网页 Agent 有一个很不一样的特点：它对“视觉状态”的依赖更强。

网页 Agent 通常还有 DOM、可访问性树、结构化页面元素可以利用；手机端很多操作却只能通过截图去理解。Agent 要下单、订票、回消息、改日程、切换 App，本质上都要先知道“当前屏幕是什么”。

这意味着，屏幕不再只是一个展示层，而是逐步变成 Agent 的输入层、判断层，甚至是执行层的一部分。

从 AgentOS 的视角看，这个变化更明显。未来的操作系统如果真的把 Agent 作为一等公民，屏幕就很可能成为它的默认感知入口之一：通知栏、弹窗、支付确认页、聊天窗口、地图导航、照片预览、邮件列表，都会被纳入 Agent 的观察范围。

问题也随之升级。

只要 Agent 持续看屏幕，屏幕上的所有内容就都有可能被带入模型上下文。

而一旦这个上下文被发送到设备之外，隐私风险就不再是抽象概念，而是具体的数据出站问题。

截图流出站：移动端 Agent 的隐私泄露入口

论文聚焦的是一条很具体的链路：

手机截图 → 第三方 Router / 外部 MLLM → 返回动作决策

这个流程在当前很多移动 GUI Agent 系统里都成立。Agent 截一张图，把它交给视觉模型理解；模型判断该点哪里、该输入什么；然后 Agent 执行动作，再截下一张图继续循环。

看起来，这是移动 Agent 完成任务的正常流程。

但从安全视角看，问题恰恰出在这个“正常”上。

因为一张手机截图里可能同时包含：

  • 姓名、手机号、邮箱；

  • 收货地址、酒店地址、出行轨迹；

  • 订单记录、付款信息、会员信息；

  • 聊天记录、联系人、社交关系；

  • 公司日程、审批流程、业务通知；

  • 各类账号状态、验证码、待办事项。

这些信息很多并不是用户主动交给 Agent 的，而是随着屏幕状态被动暴露出来的。用户让 Agent “帮我订一张票”，并不等于同意把整张屏幕上的所有上下文都发送给外部模型。

论文里把第三方 Router 设定为一种 honest-but-curious 的对手：它表面上正常参与任务流程，但可能利用自己的模型能力，从截图中额外抽取隐私信息。这个设定并不激进，却已经足够说明问题——哪怕链路里的参与方没有显性恶意，只要它具备读取截图的能力，就具备隐私抽取的能力。

在 AgentOS 场景下，这个问题只会更突出。

因为截图不再是偶发事件，而可能变成一种持续的、序列化的屏幕观察流。

单张截图也许只泄露一个地址。

连续几十张截图，就可能泄露完整的行为轨迹、社交关系和工作上下文。

简单打码会破坏 Agent 可用性

当我们意识到截图会泄露隐私，最直觉的想法通常是：打码、模糊、遮挡。

这在很多传统场景下确实有效，但放到移动 GUI Agent 上，问题就复杂得多。

因为 Agent 要完成任务，恰恰需要依赖这些视觉信息：

  • 页面标题；

  • 按钮文字；

  • 输入框位置；

  • 列表结构；

  • 弹窗状态；

  • 商品名称；

  • 时间和地点；

  • 页面之间的层级关系。

如果简单把文字模糊掉，隐私可能少泄露了一些，但 Agent 也会失去判断能力。它看不到地址，同时也可能看不到“确认支付”；看不到联系人，也可能看不到“发送”；看不到订单号，也可能看不到“改签入口”。

这就是移动 Agent 隐私保护里最核心的矛盾：

隐私信息和任务信息常常共存于同一张截图，甚至交织在同一个界面区域。

所以，这里的目标不能只是“把隐私遮掉”，而是要做到：让模型更难抽取敏感信息；尽量不破坏它对页面的任务性理解。

换句话说，移动 Agent 需要的不是粗暴打码，而是一种任务保持型降敏。

DualTAP：截图出站前的任务保持型降敏

DualTAP 的思路很直接，也很适合落地理解：

它不改外部模型，不要求 Router 自律，而是在截图出站之前先加上一层本地保护。

原始截图先经过一个保护模块，生成带有对抗扰动的截图，再把这张处理后的截图发送给外部模型。外部模型看到的仍然是“能理解页面的大致内容”，但对其中的敏感信息读取能力会被显著削弱。

从架构位置上看，DualTAP 更像是一个端侧的视觉隐私保护器。

它解决的问题很明确：让 Agent 继续能看懂页面、能执行任务，但尽量不要让外部模型顺手把用户隐私一起读走。

这也是它与传统隐私方法的区别。它不是只追求“保护得最狠”，而是在保护和可用性之间找一个工程上可接受的平衡点。

论文同时构建了一个专门用于这个问题的数据集 PrivScreen。数据集包含 500 多张移动应用截图、1000 多条合成 PII，覆盖 10 个移动 App，并为每张截图设计了两类问题：

  • 一类是隐私问题：测试模型能否读出截图中的敏感信息；

  • 一类是正常任务问题：测试模型是否还能理解界面并完成操作。

这个设计非常关键。

因为它把“隐私泄露”和“任务成功”放在了同一个评测框架里，而不是只看其中一个。

对比注意力：只干扰更像隐私的区域

DualTAP 的第一个关键设计，是 Contrastive Attention Module，也就是对比注意力模块。

它背后的想法不复杂：并不是截图里的所有区域都同样重要，也不是所有区域都同样敏感。

有些区域更容易被“隐私抽取任务”关注，比如邮箱、地址、聊天内容、订单号；

有些区域则更容易被“正常任务”关注，比如按钮位置、导航栏、页面结构、控件布局。

DualTAP 会分别估计这两类关注，然后计算两者的差异，把更多扰动集中加到那些：

  • 更像隐私区域；

  • 但又不是任务必需区域的地方。

这么做有两个好处。

第一，它避免了全局粗放加噪。如果对整张截图一视同仁地处理，往往很容易把页面结构也破坏掉。

第二，它更符合实际的任务逻辑。Agent 真正需要的是“知道页面怎么操作”，而不是“逐字还原页面上所有信息”。

因此，对比注意力的价值在于：把有限的扰动预算，尽量花在更值得保护的位置上。

双任务目标：让隐私抽取变难，让正常操作继续可用

DualTAP 的第二个关键设计，是 双任务对抗目标。

它同时优化两件事：

  • 对正常任务，要尽量保住模型的页面理解能力；

  • 对隐私任务，要尽量提高模型的抽取难度。

这个思路非常符合 Agent 安全的实际需求。

企业不会接受一个“绝对安全但完全不能用”的 Agent；同样，也不会接受一个“任务能力很强但把屏幕内容原样送出”的 Agent。

DualTAP 的训练目标，本质上就是在这两个方向之间找平衡：

  • 让模型还能回答“下一步该点哪里”；

  • 让模型更难回答“这个页面上用户住在哪里、邮箱是什么、订单号是多少”。

这也是为什么论文方法名里会强调 Dual-Task。

它不是单纯的视觉扰动，而是围绕“任务保真 + 隐私抑制”展开的联合优化。

从安全体系的角度看，这很值得关注。

很多防护机制失效，不是因为它们完全没效果，而是因为它们只优化安全，不优化可用性，最后根本上不了线。DualTAP 至少提供了一个更现实的方向：安全目标必须和任务目标一起建模。

实验结果：隐私泄露下降，但它还不是完整治理方案

论文在六个不同模型上进行了评测，覆盖开源多模态模型、GUI 专用模型和商业模型。整体结果表明，DualTAP 能显著降低截图中的隐私泄露，同时把任务性能损失控制在相对可接受的范围内。

摘要给出的核心结果是：

  • DualTAP 在六个 MLLM 上把平均隐私泄露率压到了 31.6%；

  • 同时保持了 80.8% 的任务成功率；

  • 未保护基线的任务成功率为 83.6%。

这个结果的意义不在于“已经完美解决隐私问题”，而在于它证明了一件事：

截图隐私保护不一定要以明显牺牲 Agent 可用性为代价。

论文的消融实验也说明，简单 Blur、Mask 这类方法要么保护不够，要么对任务伤害太大；DualTAP 通过更有针对性的扰动，把两件事兼顾得更好一些。

不过，实验结果也同时暴露出它的边界：

  • 隐私泄露并没有被归零。对更强的模型，尤其是商业模型，迁移防护效果并不总是稳定。

  • 任务损失仍然存在。对一些 GUI 专用模型，任务准确率下降会更明显。

  • 实验主要还是单步评测。真实 Agent 的多步执行、状态恢复、跨 App 跳转，比单张截图问答更复杂。

  • 攻击者假设偏温和。如果对手使用更强 OCR、去噪、放大、时序拼接和多轮追问，DualTAP 的效果还需要进一步验证。

所以，对这项工作的合理定位应该是：

它是移动端 Agent 截图保护的一层有价值组件，但还不是完整的 AgentOS 隐私治理方案。

对 AgentOS 的启发：感知层需要安全边界

DualTAP 真正值得 Agent 安全领域重视的地方，在于它把防护重点前移到了感知层。

过去讨论 Agent 安全，大家更熟悉的是：

  • 提示注入；

  • 工具越权；

  • RAG 投毒；

  • 日志泄露；

  • 输出违规。

这些都重要，但它们大多发生在模型已经拿到上下文之后。

DualTAP 关注的是更前面的一步：模型究竟看到了什么。

这在 AgentOS 语境里非常关键。

如果未来的 AgentOS 真的以屏幕、通知、系统弹窗、应用状态作为默认感知输入，那么安全边界就不能只放在模型输出端。系统需要在感知入口就开始做约束：

什么内容允许被看见；

什么区域允许被发出设备；

什么上下文必须本地处理；

什么截图只能保留任务必要部分；

什么连续观察行为需要被审计。

换句话说，AgentOS 需要的不是一个“更会看屏幕”的 Agent，而是一个“知道什么该看、什么不该带出去”的系统。

这会把安全能力从“输出审核”扩展到“感知治理”。

企业落地：从截图降敏到视觉隐私网关

如果把 DualTAP 放进企业的 Agent 安全体系里，我更倾向于把它理解为一种视觉隐私网关能力。

企业真正可落地的方向，大概包括五件事。

1. 原始截图尽量不出端

能在本地完成的 OCR、布局识别、敏感区域定位，就不要先把整张截图交给外部模型。截图一旦出端，后面的合规和控制空间就会明显缩小。

2. 尽量只发送任务相关区域

很多任务并不需要完整屏幕，例如改签机票，真正相关的可能只是订单页中部区域；顶部通知栏、底部聊天浮窗、后台提示信息都应该尽量裁掉。

3. 对敏感区域做任务保持型降敏

企业需要的不是“全局打码”，而是细粒度处理：页面结构尽量保留；控件位置信息尽量保留；与任务无关的身份信息、地址、聊天内容优先压制。

4. 对连续截图流做风险评估

单张截图风险有限，连续截图风险会急剧放大。评测时不能只看一帧，而要看一个任务序列里，模型能拼出多少用户画像信息。

5. 建立专门的隐私抽取红队

可以用一个独立模型持续做压力测试：给它一组 Agent 截图，看它能读出多少姓名、地址、订单、支付、聊天、账号信息。把这个结果作为视觉链路的红队指标，而不是只看任务成功率。

从这个角度看，DualTAP 不是终点，而是提醒企业：

Agent 安全需要补上一块以前很少被单独治理的能力——视觉上下文出站治理。

写在最后

DualTAP 这篇工作切中的问题，其实可以用一句话概括：

当 Agent 开始看屏幕，屏幕就不再只是界面，而是安全边界。

AgentOS 的能力越强，系统越需要认真回答一个问题：

Agent 的感知输入究竟应该被如何治理？

过去很多安全讨论都默认，模型拿到输入之后，再去控制它怎么输出。

但在屏幕感知场景里，这个顺序需要往前推。因为一旦完整截图已经出站，很多风险其实已经发生了。

所以，移动端 Agent 的下一步，不只是“更会操作手机”，还包括“更有边界地操作手机”。

这意味着系统要具备三种能力：

  • 知道什么该看；

  • 知道什么该发；

  • 知道什么必须留在本地。

DualTAP 给出的答案还不完整，但方向是对的：

在截图出站之前，先把隐私风险压下来，同时尽量保住任务可用性。

对于 AgentOS 来说，这类能力很可能会从“可选增强项”，逐渐变成“默认安全基线”。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。