Microsoft Security Blog 于 2026 年 9 月 4 日发表一篇关于 customer-owned Edge AI 的研究文章。核心判断很直接：当 inference 在设备、sensor、gateway 或其他由客户拥有和运行的环境中进行，模型权重、客户数据、credential 和 system authority 会更接近彼此，谁负责建立信任也会随之改变。
Cloud AI 通常由不同供应商负责硬件、平台和 model weights 的 attestation；Edge AI 则把更多 stack 交给客户控制。Microsoft 特别指出，prompt injection、model tampering 和 malicious firmware update 可能在同一个环境出现，而该环境同时保存模型、数据、credential 以及通往实体系统的权限。Local 不等于天然安全，反而令客户要承担更多 verification。
文章提出四个互相配合的控制：用 attestation 验证 runtime，用 provenance 验证会影响模型行为的 artifacts，用 deterministic mediation 约束 model actions，再用 evidence-based release 决定何时把 weights、keys 或 data 放入环境。四者不是同一件事：干净的 runtime 仍可加载被污染的 artifact；来源可信的 artifact 也可能在已经被入侵的平台上运行。
Deterministic mediator 应该在模型之外工作，把可用 action allowlist、限制 argument scope、控制频率，并只在批准后释放 credentials。Microsoft 的说法是，model output 应该是 recommendation，不应该本身成为 authorization。对于高后果或不可逆的动作，仍要有独立批准、interlock 或 fail-safe；mediator 可以缩小 blast radius，但不保证每一个已经允许的动作都是安全的。
Edge AI 的另一个难点是 disconnected operation。设备失去云端连接时，不能依赖实时 detection、policy update 或 revocation，因此本地要保留 verification 和 enforcement。如果 runtime 或 loaded components 没有足够 evidence，风险操作应该延后或要求重新验证，而不是因为系统仍然可以运行就继续执行。
Microsoft 也把 model security 扩展到 data、context 和 tool call。Prompt injection 可以改变代理行为；被污染的 retrieval document 可能看似来自可信来源，却不代表适合给模型解读；同一个输入在不同 context 下也可能产生不同 output。这些特性令 signed binary、传统 vulnerability scanning 和单纯的 content filter 不足以单独画出可接受的 authority boundary。
在 release 流程上，attestation 回答「这个 runtime 是否可信」，provenance 回答「这个 component 从哪里来、由哪个 build pipeline 产生」。Microsoft 建议把 release 当成会过期的 lease：系统状态改变、evidence 不再符合 baseline 时，scheduler placement、storage、identity 和 credential release 都要重新评估。这种思路比一次性批准一台 edge device 更接近真实营运。
这篇文章的实际价值，是提醒企业不要把「模型放在自己的设备」直接等同于数据主权或安全。Edge AI 需要从 hardware、firmware、runtime、model、integration 到 customer policy 的完整 evidence chain，也需要把 agent output 当作不可信输入。真正可落地的设计，是把模型的推理能力和系统的授权能力分开，让每次高风险 action 都有可验证的条件和人工介入点。
