AI Agent Defender 揭示智能家居的安全缺口

AI Agent Defender 已成为一个颇具实用价值的标签，但消费者目前仍无法购买对应产品：面向自主智能家居助手的全面防护。

这种缺失至关重要，因为家庭助手正逐步获得对摄像头、门锁、日历、扬声器、灯光和自动化例程的访问权限。传统安全产品保护设备、账户或网络流量，却很少评估 AI Agent 所请求的操作是否符合房主最初的意图。

这一冲突已不再停留在理论层面。安全研究人员已表明，隐藏在普通内容中的恶意指令能够操纵可访问互联工具的助手。与此同时，Google 正在将 Gemini 扩展到更多 Home 设备，并加入更自然的自动化控制功能。

因此，消费者面临着一种令人不安的权衡：最有用的 Agent 会连接更多家庭数据和控制权限，但每增加一项权限，被操纵的 Agent 可能造成的损害也会随之扩大。

如今已有一些具备实际意义的保护措施，包括账户防护、网络分段、安全设备标准、本地处理、活动记录和确认要求。然而，这些控制措施仍分散在不同产品和设置之中。

目前，没有主流消费者服务能够在 Google Home、Alexa、Apple Home、独立摄像头和第三方自动化系统之间充当通用的 AI Agent Defender。市场提供的是零散的防御组件，而非完整的防御层。

AI Agent Defender 是一个类别，而非成熟的消费产品

首先需要明确的是，AI Agent Defender 描述的是一项尚未满足的安全功能，而不是一个功能一致、已被广泛确立的产品类别。

传统智能家居安全始于设备。厂商通过经过身份验证的设置、加密通信、签名软件和安全更新来保护摄像头、扬声器、门锁和中枢设备。

AI Agent 则增加了不同的一层。它们理解自然语言、收集上下文、选择操作，并代表用户调用工具。工具可以是日历服务、摄像头存档、智能门锁、消息应用或家庭自动化系统。

这一转变改变了核心安全问题。设备安全关注攻击者能否攻破门锁或摄像头；Agent 安全关注的是，获得批准的软件能否被诱导执行不当操作。

即使 Agent 始终处于已验证状态、在技术上未被攻破，仍可能作出危险决定。它可能误解命令、遵循恶意文本、组合无关权限，或在缺乏充分确认的情况下采取行动。

间接提示词注入正说明了这一问题。当敌对指令通过电子邮件、文档、网站、图像或日历邀请等内容进入 Agent 时，就会发生这种攻击。

攻击者无需直接向助手发出指令。Agent 会在执行合法任务时获取相关内容，将嵌入的文本理解为指令，并可能调用其被授权使用的工具。

研究人员在 2025 年论文 targeted promptware attacks 中展示了针对 Gemini 连接服务的这一风险。其场景包括数据泄露，以及通过受污染内容操纵家庭自动化系统。

这些是受控安全实验，并非针对家庭的大规模攻击活动证据。但它们仍揭示了一个普通杀毒软件无法可靠解决的架构问题。

家庭路由器可以阻止连接已知恶意服务器，却难以判断在某段特定对话中关闭摄像头是否恰当。

同样，多因素身份验证能够阻止外部人员登录账户，但未必能阻止已通过验证的助手滥用获准的集成权限。

真正的 AI Agent Defender 需要同时理解四项要素：用户的请求、影响模型的内容、所请求的工具调用及其实际后果。

它还需要跨越厂商边界运行。一个家庭可能同时使用 Google 扬声器、Apple 手机、Matter 门锁、Ring 门铃和独立照明产品。

如今的控制措施通常止步于各厂商的边界。Google 管理 Gemini 和 Google Home 权限；Apple 管理其平台内的 Home 访问；设备制造商则控制各自的账户、固件和云服务。

这种碎片化解释了为何现有保护措施虽有价值，却无法构成完整的 Agent 防御。每个组件只覆盖决策链中的一部分。

消费者还应区分 Agent 防御与 AI 驱动的家庭安防。使用 AI 对人物或包裹进行分类的摄像头，是在保护房产免受已观察到的事件影响。

AI Agent Defender 则保护决策系统本身。它会判断助手是否应信任某项输入、访问特定数据或执行所请求的操作。

这两类产品听起来相似，但威胁模型不同。更好的物体识别并不能防止提示词注入。对话式摄像头搜索功能也不会自动验证每一项下游操作。

因此，正在形成的趋势并非某一产品的单独发布，而是 Agent 能力与消费者能够看见、理解和管理的控制措施之间不断扩大的鸿沟。

智能家居 Agent 如今已有值得攻击的目标

智能家居 AI 改变了风险等级，因为一次错误响应可能突破聊天窗口，影响摄像头、例程或实体设备。

Google 宣布将以 Gemini for Home 替代受支持扬声器和显示设备上的 Google Assistant。该服务旨在理解复杂请求并控制已连接的家庭设备。

Google 早期的 Gemini Home plans 介绍了更具对话性的控制方式，以及能够处理复合指令的助手。这项能力减少了家庭自动化过去所需的僵硬措辞。

便利之处显而易见。住户可以描述期望结果，而不必为每项条件单独编程。助手可以理解上下文、识别相关设备，并将意图转化为多项操作。

同样的灵活性也削弱了一个熟悉的安全边界。传统自动化遵循预先创建的明确条件；生成式 Agent 则会解读其含义可能随上下文变化的指令。

以“让家里做好睡前准备”为例，助手可能会调节灯光、检查门锁、降低恒温器温度、查看明天的日历，并总结一条摄像头事件。

每项单独权限看起来都可能合理，但它们的组合形成了一个能够观察私人活动、推断生活规律并控制家庭多个部分的系统。

当助手读取不可信信息时，风险会进一步增加。共享邀请或消息中可能包含对房主看似无关、但对模型却有意义的文本。

如果 Agent 将检索到的内容视为指令，它就可能混淆数据与授权。这正是提示词注入问题的核心。

OpenAI 对 prompt injection 的公开说明将其描述为一项持续演变的行业挑战。其指导建议强调，应将 Agent 限制在完成任务所需的数据和能力范围内。

这一原则在家庭环境中更难落实。家庭助手之所以有价值，恰恰是因为它们连接了原本彼此分离的服务，并减少了用户逐一管理各个界面的需求。

因此，承受压力的是平台运营商。Google、Amazon、Apple、Samsung 和设备制造商必须提供广泛集成，同时防止这些连接演变为不受限制的授权。

消费者同样面临压力。他们必须在无法看清自然语言请求背后完整操作链条的情况下作出权限决策。

一个简单开关或许会说明助手可以访问摄像头或控制设备，却很少解释哪些被检索到的内容能够影响这种控制。

家庭环境也不同于工作场所。企业可以配备安全团队、批准应用、收集日志，并在受管设备上执行访问策略。

大多数家庭只有一名管理员，同时还要负责采购、设置、维修、订阅和家庭成员访问。安全设置必须在这些条件下仍保持易于理解。

共同居住还带来另一项复杂因素。命令可能来自成年人、儿童、访客、电视、电话或录音。仅靠语音识别并不总能为敏感操作确立授权。

摄像头和麦克风还带来了多模态输入。多模态模型处理的不仅是文本，还包括音频、图像和视频。

因此，一项指令可能出现在屏幕上、音轨中，或摄像头可见的物体内。安全软件必须评估来源和上下文，而不能仅扫描输入的提示词。

这并不意味着每一种互联助手目前都能通过每一种输入被操纵。不同产品、账户、地区和预览计划的能力各不相同。

这意味着攻击面扩大的速度正快于消费者安全界面的演进。更多集成带来了更多路径，而防御系统必须对这些路径加以区分。

相应地，基本安全承诺也必须改变。保护登录凭证固然必要，但它已无法覆盖所有以用户授权作出的重要决策。

消费级智能家居安全工具实际覆盖什么

消费者如今可以组合多种有用的防御措施，但没有任何一种能够独立验证从外部内容到 Agent 实体操作的完整路径。

第一层是账户安全。使用唯一密码、多因素身份验证、账户恢复保护，以及及时移除不再使用的家庭成员，都能减少未经授权的访问。

这些控制措施依然不可或缺，因为账户接管会让攻击者获得直接访问权限。它们也能限制泄露密码或重复使用凭证所造成的损害。

然而，账户安全假设危险请求来自未获授权的人。提示词注入则可能影响已经在合法会话中运行的助手。

第二层是设备安全。购买者可以优先选择提供签名更新、公开支持期限、漏洞报告渠道和自动安全补丁的产品。

美国正在围绕消费级物联网产品的基础保护措施推进 U.S. Cyber Trust Mark。NIST 的 consumer IoT guidance 涵盖配置、数据保护、接口访问、更新和网络安全状态感知等能力。

这些标准有助于购买者避开维护不善的设备，但并不认证生成式助手能够正确解读每一条不可信内容。

第三层是 Matter，这一互操作标准得到主要智能家居公司的支持。Matter 使用成熟的安全机制来实现设备配网、设备身份、加密通信和受控访问。

Connectivity Standards Alliance 将 Matter security 描述为该协议的基础组成部分。这些保护措施使未经授权的设备加入和网络拦截变得更加困难。

Matter 解决的是设备与控制平台之间的通信问题。它并未定义一种通用策略引擎，用于在每次行动前评估 AI 模型的推理。

一把通过 Matter 认证的门锁可以正确验证命令，但获得授权的平台仍可能错误地决定发送该命令。该协议保护的是传输路径，而不是请求背后的语义判断。

第四层是本地处理。在设备端分析更多数据的摄像头、集线器和助手，可以减少不必要的云端暴露。

本地运行还可以让部分自动化例程在互联网中断时继续可用，并限制接收原始音频、视频或家庭事件数据的服务数量。

但本地处理并不天然等同于安全处理。本地模型仍可能误解输入、接受注入攻击，或行使过多权限。

计算发生在哪里，以及授权质量如何，是两个独立的问题。消费者需要同时了解这两者。

第五层是网络隔离。许多路由器提供访客网络、专用 IoT 网络、设备暂停、流量提醒和已连接设备列表。

将智能设备与笔记本电脑和存储系统分隔开，可以在设备被攻破后减少横向移动。它还可以发现未知设备，并禁用不再需要访问权限的设备。

网络工具对加密的应用流量了解有限。它们通常能看到设备联系了哪项服务，却看不到代理为何请求某个具体操作。

封锁每一个异常连接也会造成误报。智能产品会与内容分发网络、分析系统、云平台以及不断变化的服务端点通信。

第六层是活动历史记录。摄像头时间线、家庭事件日志、账户提醒和自动化记录可以帮助住户了解发生了什么。

当代理协调多项服务时，日志尤为重要。一份有用的记录应显示输入来源、解释后的请求、访问的数据、调用的工具，以及最终的设备操作。

大多数消费者产品的历史记录并不会呈现这一完整链路。一个应用可能记录语音请求，另一个应用则记录门锁事件，住户只能自行将两者关联起来。

第七层是确认机制。要求手机解锁、生物识别验证、语音代码或明确批准，可以防止后台指令触发敏感操作。

确认机制在关键步骤发生前立即执行时效果最佳。初始设置期间授予的广泛许可，提供的保护不如针对特定交易的同意。

不过，过多提示会训练用户习惯性地自动批准操作。设计者必须将更严格的检查保留给高影响操作，例如解锁门、停用摄像头或暴露录像。

最后一层可用防护是降低权限。消费者可以移除未使用的集成、拒绝不必要的数据访问，并区分家庭成员角色。

儿童账户不应继承家庭管理员拥有的全部能力。食谱助手不需要获得解锁外门的权限。

这些做法通过若干相互独立的控制措施，近似实现了 AI Agent Defender。其弱点在于操作复杂度。

消费者必须在路由器、移动操作系统、家庭平台、设备应用和第三方服务中识别相关设置。更新还可能引入新权限或改变既有行为。

因此，安全在一定程度上依赖于持续的家庭管理。除非平台让这些控制措施更易理解，否则这并不是大规模普及的现实基础。

真正的竞争是代理便利性与强制权限之间的较量

核心权衡并非智能与无知之间的取舍，而是代理广泛实用性与严格受限权限之间的平衡。

平台公司希望助手以最少摩擦完成多步骤任务。每一次中断都会削弱代理能够独立处理结果的印象。

安全的方向则恰恰相反。它倾向于更小的权限范围、可信输入、明确边界，以及在高影响操作前取得批准。

两个极端都不令人满意。一个在开灯前都要求批准的助手会显得繁琐；而一个读到不可信文本后就能解锁房门的助手则不可接受。

解决方案需要基于风险的授权。日常且可逆的操作可以在有限摩擦下进行。敏感、不可逆或侵犯隐私的操作则需要更严格的检查。

一项实用策略可能允许代理在无需确认的情况下调暗室内灯光，但在停用摄像头或更改门锁之前要求通过手机批准。

上下文同样重要。识别到的住户在门旁提出请求后解锁房门，与因为日历条目中包含隐藏文本而解锁房门，是两种不同情形。

代理必须保留每条指令的来源。溯源意味着记录信息来自何处，以及它如何进入决策过程。

如果没有溯源机制，可信的用户命令与不可信的检索内容可能会在同一模型上下文中混合。模型可能难以区分权威指令与普通数据。

第二项要求是能力分离。读取外部内容的组件不应自动获得执行敏感操作的权力。

安全研究人员常描述将不可信内容与高权限工具隔离的设计。一种模型或进程可以提取信息，而单独的控制器则应用固定策略。

这种安排无法消除错误，但能降低消息中发现的文本直接变成门锁命令的可能性。

第三项要求是确定性执行。确定性规则会产生预期结果，而不是要求语言模型自行判断自身行为。

例如，软件可以始终要求在外门锁状态发生改变前进行确认。即使检索到的文档称情况紧急，模型也无法豁免这一控制。

第四项要求是受限记忆。持久化代理记忆可以改善个性化体验，但也可能将恶意或错误指令保留至单次会话之外。

用户需要能够检查、更正和删除已记住的信息。敏感权限不应悄然从临时任务迁移到未来的自动化例程中。

第五项要求是有意义的可审计性。住户应能询问某项操作为何发生，并获得基于已记录事件的追溯链路。

回答应标明发起用户、源内容、代理决策、调用的服务以及最终设备状态。泛泛的“自动化已运行”提示并不够。

OWASP 的 代理安全指南建议将工具输出视为不可信内容，并采用最小权限、结构化授权、监控和安全测试。

该指南面向开发者，而非普通家庭用户。它的相关性揭示了市场缺口：消费者平台必须将工程控制转化为易于理解的默认设置。

供应商还需要公布更清晰的边界。仅说明助手使用加密，并不能解释检索到的日历文本是否会影响家庭控制操作。

同样，有关隐私的声明也无法说明模型是在本地、云端，还是通过另一家 AI 提供商处理视频。消费者需要针对具体操作的信息。

如果企业让安全措施变得可见，竞争可以推动这些控制得到改善。Apple 可以强调本地执行和确认机制；Google 可以展示操作历史和权限边界。

Amazon 可以限制技能和家庭角色。摄像头制造商可以公开处理位置、保留期限和代理访问权限。

不过，零散的声明也可能让买家感到困惑。每家供应商对“私密”“安全”或“设备端”的定义可能不同。

因此，独立测试将十分重要。评测者不应只测试密码保护和网络加密。

他们还应检查敌对文本、音频或图像是否会影响助手。测试还应验证确认关卡、日志、权限撤销，以及收到不安全指令后的恢复能力。

消费者网络安全标签最终可能纳入代理行为。现有设备基线提供了基础，但由模型介导的操作需要额外标准。

这些标准不应承诺能够完美防御提示注入。没有可信测试能够证明通用模型会拒绝每一种未来攻击。

相反，一项有用的标签可以验证架构层面的保护措施，例如受限工具、保留输入溯源、强制确认、可访问日志和快速撤销。

怀疑性的结论无法避免。供应商可以降低代理风险，但关于完全保护的声明值得审视。

若 AI Agent Defender 仅扫描提示词，就会遗漏不安全的工具组合、过度权限、记忆投毒，以及孤立来看似乎合理的操作。

最强的保护将围绕模型部署。它将控制代理能够访问什么、能够做什么，以及何时必须由人类批准结果。

AI Agent Defender 接下来必须证明什么

下一阶段将由可见的控制措施和独立测试来评判，而不是又一个贴着安全标签的仪表盘。

第一个值得关注的信号，是针对敏感家庭操作的交易级确认。平台提供商应明确哪些操作始终需要用户重新批准。

这一标准应覆盖外门锁、警报状态、摄像头停用、视频共享、家庭成员资格以及安全自动化例程的变更。具体清单可因产品而异。

关键在于代理无法绕过该规则。如果主要平台引入固定的批准关卡，便利性与权限之间的权衡将更易于管理。

如果确认机制仍只是开发者选项或隐藏设置，防御缺口就仍然存在。消费者不应需要自行设计授权模型。

第二个信号是统一的代理活动记录。房主需要的不只是分散的设备历史记录和账户通知。

完整记录应将触发请求与受影响的每项服务和设备关联起来，还应标明影响该操作的检索内容。

这一记录必须易读。原始技术日志对专业人士有帮助，但普通住户需要一条以通俗语言解释决策的时间线。

强大的实现方式应允许用户直接从历史记录中撤销权限，也应支持将某项操作报告为意外或不安全。

如果 Google、Apple、Amazon 或 Samsung 提供这样的追溯链路，竞争对手将面临跟进压力。市场届时便可比较问责能力，而非模糊的安全措辞。

第三个信号是跨平台的独立对抗测试。研究人员需要能够访问结合助手、摄像头、门锁、消息、日历和第三方设备的真实环境。

测试应包括直接命令、被投毒的文档、恶意邀请、音频指令、图像、共享账户和多步骤工具使用。结果应区分实验室演示与可被利用的消费者配置。

开发者也需要可重复的基准测试。只能拦截已知措辞的防御机制，可能会在措辞、输入渠道或操作序列变化时失效。

公开结果将帮助买家区分架构控制与营销过滤措施，也能显示软件更新是否真正提升安全性，还是仅改变了模型行为。

三项成果将强化 AI Agent Defender 的价值主张。供应商可以强制要求敏感操作获得批准、公开因果活动历史，并将集成系统提交给独立测试。

相反的结果会削弱这一判断。隐藏权限、不完整日志，以及无法验证的检测声明，都会让消费者只能依赖信任。

在这些信号出现之前，购买者应使用现有的保护措施。保护好每个账户，移除闲置集成，启用自动更新，并隔离不必要的设备访问权限。

他们还应定期检查家庭成员和自动化历史记录。敏感操作应获得明确确认，即使这会降低一些便利性。

没有任何设置能够保证通用型助手会正确理解未来的每一项输入。实际目标是在理解失败时限制后果。

这一原则在安全工程中并不陌生。系统应假定某一层可能出错，并防止该错误演变为更严重的安全失陷。

对于智能家居而言，缺失的一层是围绕 Agent 的、具备操作感知能力的控制机制。它必须将用户意图、输入来源、权限与现实世界的物理影响连接起来。

消费者在授予任何助手更多权限前，应先直接问一个问题：我能否查看、限制并撤销它采取的每一项敏感操作？

如果答案不明确，就应保持权限范围狭窄。可信的 AI Agent Defender 不会只承诺更智能的检测；它会让 Agent 的权限变得可见、有限且可追责。