它能保护什么，保护不了什么

Anpio Key 的目标只有一个：让 Agent 能代表你签名，但拿不走私钥，也不能超出你批准的范围。

能保护

情况	结果
Agent 想读私钥文件	读不到；私钥在服务账号的托管目录里
Agent 想通过接口要私钥	数据接口没有这个操作
Agent 想访问别的网站、路径或方法	策略不匹配，拒绝签名
grant 过期或次数用光	拒绝签名
Agent 想改策略、改 grant、给自己加权限	管理接口只对管理员账号开放
你撤销了 grant	不再产生新签名
机器重启	旧 grant 全部作废，钥匙重新锁定

Linux 受保护部署还额外保证：服务、管理员、Agent 是三个系统账号，Agent 账号不能改程序、配置、状态或 socket 父目录。

保护不了

情况	说明
机器被 root、内核或管理员控制	这一层不在防护范围内
已经发出去的签名	撤销只能阻止新的签名，收不回已经到达对方的请求
你批准的权限太大	如果允许“删除任意订单”，Agent 就能删除任意订单
同账号里的其他程序	同一个系统账号就是同一个主体
以前导出或泄露的私钥备份	软件无法收回已经复制出去的材料
对方是否真的执行了业务	签名只证明请求来自这个身份

所以授权要写窄

grant 应该尽量写成：

• 只给一个 Agent 主体；
• 只用一把热钥匙；
• 只允许一个网站、一个路径、一个 HTTP 方法；
• 只在一段明确的时间内有效；
• 只允许有限的次数。

范围越窄，Agent 被控制后能造成的损失越小。解锁本身不等于授权；钥匙解锁后，Agent 仍然需要一张有效 grant。

信任前提

使用受保护部署时，下面这些必须成立：

• 管理员账号是可信的，没有被 Agent 控制；
• root 和内核没有被攻破；
• daemon 程序和配置没有被替换；
• Agent 没有 sudo、宿主 Docker socket 或管理员凭据；
• 整个 Agent 框架都在 Agent 账号下运行。

任何一条不成立，就不能把受保护部署的结论套用到这台机器上。

不同环境下的边界

环境	是否有账号隔离
Linux 正式 release + linux-protected-v1	有，protected_supported=true
Linux preview、调试构建	没有，protected_supported=false
macOS 本机预览	有独立账号，但不是正式发行，protected_supported=false
同 UID 开发模式	没有，任何同账号程序都能读文件