AI Agent 技能安全：为什么手机 Agent 不能只靠安装前扫描

通过扫描不等于可以完全信任

很多人安装 AI Agent 技能、插件或工具包时，最容易问的问题是：它有没有通过扫描？这个问题重要，但不够。AI Agent 技能安全不能只停在安装前，因为一个技能在文件里看起来干净，不代表它运行时一定安全。它可能延迟触发某段行为，也可能在拿到上下文、账号信息或用户指令后，才表现出真正意图。

The Hacker News 对 SkillCloak 的报道把这个问题推到台前：研究者描述了恶意 AI Agent 技能绕过静态扫描的方式，并提出更关注运行行为的检测思路。这里要谨慎理解：这是一条安全研究和行业警示，不等于所有技能都恶意，也不等于某个产品已经受影响。它说明的是信任模型需要升级。

静态扫描像门口安检，能发现明显危险物品；但 AI Agent 技能的风险常常发生在“进去以后”。例如技能表面上是总结文件，运行时却尝试读取更多目录；表面上是安排日程，后来请求联系人和消息权限；表面上只做查询，最后准备提交外部请求。判断规则很简单：安装前检查是起点，不是终点；真正的信任来自运行中是否被限制、被观察、被记录。

真正要看的，是技能运行时做了什么

运行时权限检查的核心，是把注意力从“代码长什么样”移到“实际做了什么”。一个 Agent 技能可以声明自己只处理文本，但运行时是否访问了文件、网络、剪贴板、联系人、通知或其他工具，才是更关键的信息。行为检查、隔离环境、数据流向分析和异常动作拦截，都是为了回答同一个问题：这个技能有没有越过它本该做的事？

Cloak and Detonate 预印本把静态扫描绕过和动态检测放在同一个研究框架里讨论。由于它是预印本，文中关于绕过和检测效果的结果应被视为研究报告，而不是行业保证。对产品团队来说，它的启发不在某个数字，而在方法：不能只看技能包被提交时的样子，还要看它在真实上下文里如何调用工具、处理数据、触发动作。

对手机 Agent 尤其如此。日志、确认和可回看历史不是形式主义，而是运行时检查能否被用户理解的一部分。当系统记录了技能何时请求权限、读取了什么、准备执行什么、用户是否确认，后续才有机会复盘。关于类似的可见记录和同意机制，可以参考 AI 代理权限日志，它讨论的是家庭监督场景，但“记录必须能解释动作”这一点同样适用于技能安全。

放到手机上，风险会从代码变成真实操作

在服务器或开发环境里，恶意 AI Agent 技能可能窃取文件、调用工具或泄露凭据；到了手机上，风险会更贴近日常生活。手机里有消息、联系人、通知、相册、日历、位置、文件、支付入口和各种账号。一个看似无害的插件，如果能参与手机任务，就可能从“读取信息”进一步走向“准备发送”“修改设置”“打开应用”或“触发工作流”。

这就是手机 AI Agent 权限比普通聊天插件更敏感的原因。读取通知和发送消息不是同一类权限；生成草稿和真正发出草稿也不是同一件事；打开设置页面和修改设置更不能混为一谈。Android 权限本身就体现了不同敏感级别，Android Developers 权限说明也展示了权限是由系统控制、由用户授予的能力，而不是 Agent 可以随意绕过的通道。

敏感手机上下文在哪里处理，也会影响风险。某些任务适合在本机完成，某些复杂分析可能使用云端模型；但无论走哪条路径，都需要说明数据范围和动作边界。讨论手机上下文、动作和本地/云端分工时，可以参考 云端 AI 智能体与本地 AI 智能体。判断规则不是“云端一定危险”或“本地一定安全”，而是每个任务都要最小化数据、明确授权、保留确认。

更合理的权限模型：少给、临时给、先确认

面对 AI Agent 插件风险，最实用的设计原则是最小授权：技能只拿完成当前任务所需的能力，不提前申请一整包权限。一个翻译技能不该默认获得联系人权限；一个日程技能不该默认读取所有消息；一个文件整理技能不该自动获得网络发送能力。权限越集中，恶意 AI Agent 技能一旦绕过检查，影响范围就越大。

第二个原则是按需提示。用户真正需要的不是一开始看到一大段授权说明，而是在关键时刻看到清楚问题：这个技能要读取哪条通知？要把哪些内容发给哪个 App？要修改哪个设置？要把文件上传到哪里？如果动作会产生外部影响，例如发送、删除、购买、共享位置或更改账号设置，就应该在动作发生前明确确认，而不是事后告诉用户“已完成”。

第三个原则是记录和复盘。消费级手机 Agent 的权限提示解决的是单次动作，企业里的控制则会更复杂，包含策略、分级、审批、合规和集中监控。更广义的治理可以参考 企业 AI 代理安全；但对普通手机用户来说，至少应能看到任务何时开始、调用了哪个技能、请求了哪些权限、最终执行了什么。没有记录，用户就无法判断异常行为是误操作、设计缺陷还是恶意技能。

普通用户和开发者可以怎样判断风险

普通用户不用把每个插件都当成恶意，但也不该只看“已通过扫描”。可以先问五个问题：技能来自哪里？它要完成什么明确任务？它请求的权限是否和任务匹配？敏感动作前是否会停下来确认？完成后是否有可回看的任务记录？如果一个天气技能要求读取联系人和消息，或者一个总结技能要求自动发送内容，这就是明显的风险信号。

开发者和产品团队还应增加几项检查：技能是否能在隔离环境中运行？是否限制网络访问？是否记录工具调用？是否区分读取、准备和执行？是否对异常行为设置拦截？是否能在用户撤销权限后停止相关动作？这些问题比“扫描器是否给了绿灯”更接近真实安全。扫描器能降低入口风险，运行时控制才决定事故范围。

还要避免另一个极端：把所有技能都视为不可用。插件和技能确实能让 Agent 更有用，例如查询资料、整理文件、创建日程、控制支持的手机功能。关键是把能力和权限绑在一起，把权限和确认绑在一起，把确认和记录绑在一起。一个可信技能不是永远不出错，而是在出错前有边界，出错后能解释，用户能撤回授权。

FoneClaw 应该守住的手机端安全边界

FoneClaw 与 The Hacker News、arXiv 作者、OWASP、Android、Google、Claude Code、OpenAI Codex、OpenClaw 或任何安全厂商没有从属或背书关系。本文讨论 SkillCloak 和运行时检测，是为了说明手机 Agent 的安全设计方向，不是暗示 FoneClaw 受影响，也不是声称 FoneClaw 扫描第三方技能或提供安全保证。

更合适的 FoneClaw 视角是：作为独立的 Android 手机 AI Agent，它应该让支持的手机操作保持可见、按需授权、敏感动作确认，并留下可回看的记录。用户说“帮我整理通知并准备回复”时，系统应区分读取通知、生成草稿、打开消息 App 和发送内容这几个步骤；用户说“帮我调整设置”时，也应说明要进入哪个设置项、为什么需要权限、是否会改变设备状态。

资料来源：本文的风险分类参考了 OWASP 大语言模型应用风险清单，其中包括提示注入、供应来源风险、不安全插件设计、过度代理和敏感信息泄露等问题；手机权限边界参考了 Android Developers 权限说明；SkillCloak 和 SkillDetonate 相关背景来自 The Hacker News 报道 和 Cloak and Detonate 预印本。这些资料支持风险判断和设计原则，但不代表任何机构认可 FoneClaw，也不代表运行时检查可以消除所有风险。