能付款和签名的智能体如何做威胁建模
文章建议先明确攻击者可获得的收益，再分别分析输入、模型和宿主环境的攻击面。重点风险包括外部数据中的提示注入、智能体持有凭证导致的泄露，以及模型行为偏离授权意图。
原文暂未完整获取，基于公开信息的快读
能付款、能签署发布包的 Agent，安全问题已经超出「回答是否靠谱」。dev.to 的这篇文章援引 Ledger CTO Charles Guillemet 的观点：选模型之前，先写清攻击者得手后能拿走什么，再检查输入、模型和宿主环境。防护强度应由可能损失决定。
目前能确认什么
节选区分了几条攻击路径。提示注入把指令藏进 Agent 读取的外部数据；越狱则诱导模型突破安全训练。两者入口不同，都不能只靠模型自己识别。
如果 Agent 持有 API keys 或钱包助记词，泄露凭证后，攻击者可能直接获得相应操作权限，绕过原有策略检查。即使凭证没有泄露，含糊的请求也可能被转成偏离授权意图的动作。
宿主环境是另一层风险：主机被攻陷，策略引擎可能被篡改。密钥放在硬件里，也不代表攻击者无法调用它签名。
密钥不被导出，不等于每次签名都获得了正确授权。
文章按损失价值讨论软件访问控制、硬件自动签名、带屏幕的人工核验，以及需要多人批准的多重签名。这是受访者的分层思路，并非统一标准。节选还明确，Ledger 尚未在设备层使用所述零知识证明方案。
我的判断
给 Agent 接支付或发布工具时，第一份安全设计应列出它能支配的资产，以及一次错误操作会造成什么损失。低价值操作可以考虑受限额度和访问控制；资金库或固件发布，则需要更强的独立核验。
对程序员而言，关键是把「模型提出动作」和「系统授权执行」分开，并检查最终收款方、金额或待签名内容是否与授权一致。仅过滤输入输出，无法完成这一步。
节选最后被截断，策略如何准确映射具体动作、核验界面展示什么、宿主失陷后如何约束签名，都还缺少完整说明。不能据此认定，加上硬件或可信执行环境就已解决整条链路的安全问题。