提示词注入并非终点，苹果 PCC 的安全风险可能藏在底层架构中

讨论 Apple Intelligence 时，很多人会把注意力放在“提示词注入（Prompt Injection）”上，例如尝试用某些话术诱导 Siri 突破限制，说出不该说的内容。但在应用层进行这种博弈，在我看来只是最低维度的较量。如果深入研究苹果私有云计算（Private Cloud Compute, PCC）的架构，就会发现真正的战场可能位于更底层的计算基础设施。

PCC 的核心卖点是“私密性”。苹果承诺，数据在云端处理时对公司不可见，并会通过独立审计来提供背书。不过，对追求极致的开发者或安全研究员来说，这种高度封闭、又格外强调安全的架构，恰恰构成了最值得挖掘的“压力测试”对象。如果目标是绕过表面的对话逻辑，直接检验 PCC 的安全性，那么有三条硬核路径值得深挖。

一条路径是内存状态分析与隔离机制。PCC 强调状态隔离，这意味着每个用户的请求在云端应当完全独立，并在执行结束后被彻底清除。但从理论上讲，任何内存清理都不可能绝对完美。如果能够研究内存快照的刷新机制，或者尝试利用类似 Spectre（幽灵）这种基于预测执行的漏洞，那么在高并发请求处理期间，是否可能诱导系统在缓存中留下残留信息？如果可以通过某种方式窥探到其他用户的上下文片段，那么所谓的“私密计算”在技术层面上就出现了裂缝。

另一条路径是围绕资源争抢展开的侧信道攻击（Side-Channel Attack）。在共享计算环境中，即使用户之间实现了逻辑隔离，CPU 缓存、内存总线等物理资源仍然需要共享。通过编写高频请求脚本，精确测量响应时间在微秒级产生的波动，研究者或许能够反推出云端模型处理特定数据时遵循的逻辑分支。这类攻击不需要接触源代码，只要观察“执行时间差”这样的物理特性，就能推断后台正在处理什么数据。相比在对话框里尝试“破防”，这种攻击显然更加硬核。

还可以测试 API 边界上的通信协议。PCC 必须与设备端（iPhone/Mac）进行高频通信，这中间必然存在一套复杂的签名与验证机制。如果能够伪造设备端的合法签名，或者在传输链路中注入非标准的非法指令，观察系统是否会触发“未定义行为（Undefined Behavior）”，这才是真正意义上的 Hacking。比如，发送一个超出预设长度的异常数据包，导致 PCC 的处理进程出现内存溢出（Buffer Overflow），那么直接取得执行权限的可能性就会大幅增加。

如今的攻防方向已经发生明显变化：人们不再满足于调优提示词，让模型按照预期“听话”，而是开始把大模型视为一个入口，转而攻击承载它的整套计算基础设施。提示词注入改变的是“输出结果”，底层漏洞改变的则是“控制权”。对于 PCC 这种试图定义私有云标准的产品而言，从底层切入展开攻防博弈，远比单纯讨论如何编写 Prompt 更有价值。