当手机开始自己“动手”，它就不再只是回答怎么点外卖更划算，而是会真的打开 App、比价、下单。操作权从人的手指，交给了一个能看屏、能规划、能执行的智能体。
2025 年底推出的豆包手机助手（以下简称豆包助手），第一次把整个手机的完整操作链条交到了智能体手里：它以大语言模型作为中枢决策单元，结合 GUI Agent 技术，从用户目标出发进行意图理解、任务拆解与路径规划，并以系统级的能力完成跨应用、跨场景的复杂任务执行。
但 AI 与手机的结合，也让它同时站在两类风险的交汇处：既要应对传统手机安全问题，也要面对智能体带来的新攻击场景。攻击者不必再费力诱导用户多点几步，只需要把智能体的规划引向错误方向，就可能让一串看起来正常的操作变成窃取用户信息的攻击链。
DARKNAVY 在评估中发现，豆包助手在安全与隐私方面做了大量考量，但仍存在可被利用的真实风险：攻击者可能在用户正常使用的过程中，通过发送恶意信息误导并劫持智能体，进而窃取手机银行验证码等敏感信息。
本文将围绕豆包助手的技术实现路径、安全及隐私考量、潜在安全风险展开进一步讨论。
架构分析与业务逻辑
Obric 是豆包手机搭载的基于Android的定制操作系统，其 AI 相关功能由一组系统级应用构成，覆盖语音交互、记忆管理、模型推理、自动操作等关键能力模块。从职责划分来看，各核心应用的功能边界较为清晰：
ObricAiAgent：豆包助手应用主体。主进程负责能力调度、任务编排等核心业务逻辑；子进程集中处理唤醒、声纹识别及相关 UI。
ObricAutoAction：豆包助手自动操作模块，承载自动化任务的核心业务逻辑，负责将用户意图转化为可执行的操作序列并执行。
AIKernel：端侧模型与推理基础设施，提供统一的模型加载、调度与推理能力。
MemoryData：记忆管理模块，用于持久化与检索用户相关的长期与短期记忆。
AIVoiceService：语音相关能力模块，涵盖语音识别、语音合成及信号处理能力。
在上述组件中，ObricAutoAction 是实现“豆包助手自动操作”能力的关键模块。分析结果显示：业务流程上看，一条用户输入的自动化任务在进入业务层后，会被封装为一个 AutoOperateTask，随后自顶向下经过如下执行链路：
AutoOperateTask → AOSession → AOAgent / AOStep → Action / Operation
以用户在豆包助手聊天框中输入“打开百度地图，导航到佘山”为例，其推理与执行流程如下图所示。在向模型发起推理请求之前，豆包助手会截取当前手机屏幕。模型输入为此截图与一组附带信息，包括基础上下文、设备与系统参数、位置信息，以及版本与扩展字段等。模型返回的结果将用于描述下一步应执行的动作指令，例如打开目标应用。
在每一步操作执行完成后，智能体都会再次截图，并对当前任务状态进行判断：若任务尚未完成，则再次携带最新屏幕状态向云端请求推理结果，获取下一步操作指示。通过这种“感知—推理—执行”的循环，整体任务被逐步规划并完成：打开百度地图、在搜索框中输入“佘山”、点击“搜索”、请求用户澄清具体的导航目标（如佘山地铁站或佘山公园），以及点击“开始导航”按钮。
“打开百度地图，导航去佘山” 注：图片仅作演示目的，不代表真实业务的具体实现与推理细节
在此过程中，执行框架以云侧模型推理为核心，端侧推理仅作为 VlmAgent 中的辅助能力存在，由 aikernel 提供支持。目前可观测到的本地模型包括一个基于 TensorFlow-Lite 的轻量模型 AIKLoadingDetection，用于在向云端请求推理之前判断当前页面是否仍处于加载状态，来决定是否暂停任务等待加载；此外，滚轮相关的 OCR 能力（如 OpScrollWheelAction）也依赖本地模型来识别滚动目标位置。
安全策略与隐私考量
我们对豆包助手展开了初步的安全分析，发现其整体安全架构较为完整，未发现结构性缺陷或明显的高危设计问题，但安全漏洞依然存在。此部分将从多个维度对豆包助手的安全与隐私机制进行讨论。
应用组件鉴权：超级应用的能力滥用风险
为了自动化实现点击、读屏、安装应用等功能，豆包助手相关应用及组件被赋予了大量强力的权限。然而一旦这些超级应用的鉴权出现纰漏、强力权限被恶意利用，将会成为用户隐私及系统的严重威胁。
DARKNAVY 通过对豆包助手 Obric 相关的应用层组件进行分析，发现其针对Android 应用鉴权进行了较完善的防护，对暴露功能接口通过UID、包名及应用签名等多重校验手段，并辅以策略文件进行精细化约束，为第三方应用滥用超级应用的特权功能提供了较强的安全防护。
以 ObricAiAgent 为例，其关键组件通过 SecurityManager 实现统一的鉴权控制。对于其对外暴露的 ScheduleService 服务中的 dispatchServerActions 功能，系统允许特定应用向豆包助手触发执行动作，但在实际执行前会强制进行安全策略校验，默认拒绝未知或未授权的调用请求。该校验流程通过 checkPolicy 从私有目录读取策略文件，并对 (category, subject, target, action) 四元组进行精确匹配，策略逻辑相对直接且约束严格。
由于策略文件位于私有目录，第三方应用无法直接进行替换或篡改。这样的鉴权设计有效降低了恶意应用滥用豆包助手能力的风险。
策略文件四元组精确匹配
云端交互与隐私策略
豆包助手集成字节跳动自研网络通信库，在端云通信链路中依托 TEE 保护的客户端私钥实现 mTLS 双向身份认证机制，在端侧有效对抗中间人攻击的同时，也确保云端每一次请求均来自真实的物理终端。在此网络基础上，豆包助手在端侧和云侧引入了较为全面且审慎的 AI 安全与隐私策略。
在非高敏场景下，当需要请求云端推理或验证操作有效性时，豆包手机会截取当前屏幕截图。该截图经过压缩处理后上传至云端服务器、进行推理。根据豆包安全白皮书[8]的公开说明，云端在接收推理请求后，不会将截图、任务描述等用户数据用于模型训练或进行持久化存储。
另一方面，针对安卓系统中被标记为 FLAG_SECURE 的高敏感页面，例如隐私设置、视频播放及支付相关界面，豆包助手在执行过程中不会截取真实屏幕内容，而是使用一张不包含任何敏感信息的本地占位图作为云端推理输入，并辅以必要的附加上下文信息以保证执行流程的完整性。由此可以排除“使用豆包助手会导致登录密码等敏感信息被后台截图并上传”的常见顾虑。
在行为控制层面，豆包助手的自动操作能力受到云端推理结果与策略引擎的双重约束，具体表现为：
出于隐私保护及应用厂商合规要求，豆包助手目前无法对微信、支付宝等应用执行自动化操作，该限制由云端策略统一判定。
对于手机银行等高敏感应用，豆包助手的自动操作能力同样被明确禁止，相关判断亦发生在云端。
在自动操作过程中，一旦涉及支付、身份校验或需要用户补充关键信息的场景，云端策略会在执行前进行决策：拒绝并终止任务，或通过
call_user、clarify等动作提示用户手动完成相关操作，从而避免未经授权的高敏行为或自动填充、编造敏感信息。
实测表明，云端策略会明确要求用户手动输入或上传敏感信息（如手机验证码等），自动化流程不会尝试代为完成此类操作。
对于 FLAG_SECURE 标记的高敏页面，豆包助手使用本地占位图代替屏幕截图
AI 操作相关日志与数据库文件均存储于豆包助手相关应用的私有目录中，其他第三方应用无法访问。需要指出的是，在当前测试机环境中，本地仍保留了较为完整的明文会话日志与截图持久化记录，理论上存在一定本地风险，但这些数据并未被上传至云端。
GUI TOCTOU
GUI TOCTOU （Time-of-Check to Time-of-Use）风险是指 AI 在自动操作手机时，可能在“判断该做什么”和“真正执行操作”之间出现时间差。如果在这段时间内界面发生变化，AI 仍会按照旧判断继续操作，从而在用户毫无察觉的情况下误点按钮、触发非预期行为，甚至涉及隐私或资金风险。这一问题源于 GUI 自动化必须先截图分析、再执行动作的工作机制，是当前所有 GUI Agent 都难以完全避免的固有风险。
近期有研究工作对 GUI TOCTOU 风险进行了系统分析[1] 。在对豆包助手端侧自动操作能力进行评估时，DARKNAVY 同样重点关注了这一潜在问题。GUI Agent 自动操作范式的工作流本质上是一个闭环序列：
其中，系统在时刻 t0 截取屏幕并送入 VlmAgent 请求决策；云端推理完成后在 t1 执行动作注入；在 t2 再次截图以获取执行反馈。由于界面状态在 t0 与 t1 之间可能发生变化，该流程天然存在竞争窗口，从而带来误操作风险。尤其是 t0 到 t1 的窗口往往较长，因为云端推理通常需要 2–3 秒。豆包助手在 t2 阶段并未实现自动回滚或报警机制，即便后续截图发现界面已偏离预期，也无法撤销已经发生的操作效果。因此，目前豆包助手针对误触的主要防护集中在 t1’ 阶段：动作执行前的校验校验。
点击操作通常会为误触的利用带来强大确认语义，而在豆包助手的具体实现中，OpClickUI 引入了较为严格的校验逻辑：
系统会在 t0 记录顶层 Activity，并在 t1’ 时校验其是否发生变化，若已改变则直接跳过点击。
同时，t1’ 阶段还会检查最近三步内是否存在应用拉起操作单元 OpOpenApp。若存在，则重新截图并比较像素变化，若界面发生明显变化，同样跳过操作。
在 t1 执行阶段，豆包助手支持三种点击模式：单击、长按与双击操作。其中，单击与长按在安卓的注入实现中几乎不存在可控的时间窗口。对于双击操作，攻击者也无法在在第一次点击与第二次点击之间稳定完成界面切换。
由此可见，在现有实现下，GUI TOCTOU 的可利用性较低。不过，从安全演进角度看，若未来引入“两次以上点击”或“多次长按”等更长时间跨度的操作单元，则 GUI TOCTOU 仍可能成为攻击者更可控的误触渠道，需要提前纳入设计防护。
除点击外，其他操作单元如 OpTypeText、OpSwipeUI、OpScrollWheelAction 等目前并未实现类似 Action Guard 校验，虽然存在误操作可能性，但由于缺乏按钮级确认语义，这类误操作可造成的实际影响相当有限。
值得一提的是，当用户的手动操作与自动任务发生冲突（例如用户同时操作同一应用界面）时，豆包助手会主动暂停自动操作任务，优先让渡控制权给用户，这进一步降低了并发交互带来的额外误触风险。
Prompt Injection
在 AI 理解并执行用户任务的过程中，界面中呈现的文字、图片或其他内容有可能被模型误判为新的操作指令，从而影响其后续决策与行为。这类风险通常被称为 Prompt Injection。相关风险在大语言模型发展早期即已被广泛讨论[2,3]，此前亦出现过商业模型在特定场景下被诱导执行非预期邮件发送等操作的公开案例[4,5,6]。
在 GUI Agent 场景中，由于模型需要同时理解图像与文本信息，其潜在的注入路径与攻击面进一步扩大。此外，受上下文长度限制影响，在多场景切换与任务持续推进过程中，模型对初始用户意图的保持能力可能逐渐下降，从而在一定程度上提高后续注入攻击成功的概率。
在实际测试中，我们观察到豆包助手的云端模型具备一定的提示词注入防护能力，我们也初步排除了云端 Special Token Injection 风险[7]。同时，针对用户直接输入的任务描述，端侧通过 checkPrompt 函数对部分敏感词与典型注入模式进行了基础拦截。
checkPrompt 拦截敏感词与提示词注入
然而，在现有实现下，云端模型的可见输入主要由用户任务描述与屏幕图像共同构成。相较于文本输入，针对屏幕截图中的内容，豆包助手端侧目前尚未引入额外的内容过滤或语义约束机制，界面中的文本信息将被完整纳入模型推理视野，完全依赖云端过滤或隔离。在实验环境中，通过对界面文本进行精心构造并结合敏感词绕过手段，我们在特定条件下成功获取了模型的 System Prompt。同时，我们也观察到，Prompt Injection 可能对云端高敏操作检测逻辑产生干扰，从而影响模型对任务目标与执行状态的判断。
文初所展示的示例正是基于上述风险模型展开：在用户发起合法任务请求的流程中，若模型受到来自外部输入（如短信、邮件或网页内容）的持续干扰，可能在缺乏用户显式感知的情况下暴露部分个人信息（例如长期记忆内容、录音、相册、短信或邮件等），或被嵌入至更复杂的攻击链中，辅助完成后续操作。在系统性评估过程中，我们注意到，豆包助手云端对诈骗短信与钓鱼类内容的识别能力仍有提升空间；而其具备的高权限自动操作能力，则可能使上述风险在特定场景下表现得更加直接。
从另一个角度看，若未来豆包助手等智能体能够具备更强的安全意识与反诈能力，并部署于老年人等“网络安全弱势群体”使用的设备中，则其有望转化为一种积极的防护工具。
结语
超级智能体已然成为行业发展的必然趋势。随着 OpenClaw 等项目的涌现，AI 被赋予更强的自主能力与跨域执行力，正逐步深度融入从生活到工作的各类场景之中。
在这一进程中，智能体的安全体系建设必须与功能进化同步向前。DARKNAVY 自2024年起，便与多家行业伙伴携手，共同应对手机智能体、意图框架等新型系统与传统领域结合时所带来的全新安全挑战。
我们深信，面对AI智能化的全新挑战，唯有提前洞察并系统性地构建防御，才能在其大规模部署时实现真正的可信与可靠。
参 考：
[1] https://arxiv.org/html/2601.12349v1
[2] https://security.googleblog.com/2025/01/how-we-estimate-risk-from-prompt.html
[3] https://supertokens.com/blog/gemini-phishing-attack
[4] https://bughunters.google.com/blog/task-injection-exploiting-agency-of-autonomous-ai-agents
[5] https://openai.com/zh-Hans-CN/index/hardening-atlas-against-prompt-injection/
[6] https://embracethered.com/blog/posts/2025/chatgpt-operator-prompt-injection-exploits/
[7] https://blackhat.com/eu-25/briefings/schedule/#token-injection-crashing-llm-inference-with-special-tokens-48830
[8] https://o.doubao.com/whitepaper
声明：本文来自DARKNAVY，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
