Para：Agent 钱包的权限，取决于归属和签名器能读懂什么

公司想让运营 Agent 支付已批准的软件服务发票。有些款项来自公司钱包，有些来自用户同意使用的钱包。它们在 API 客户端里看起来可能很像，但授权起点正好不同：前者要收窄应用已经拥有的能力，后者要先获得别人的权限。

资料边界： 本文于 2026 年 11 月 1 日核对 Para 官方资料，属于文档分析，不是钱包或策略渗透测试。发票付款是设想场景。

Para 与旧名 Capsule 是同一条产品线

Para REST API 页面明确标注 formerly Capsule，并介绍程序化创建钱包与签名能力。目录将它们视为同一产品沿革，而不是两款互相竞争的钱包。Agent 产品页则面向带策略控制的自动化交易。

接入决策要把这些能力与业务流程分开。创建一个钱包，不等于已经确定资金归谁、哪项服务能请求签名，也不能证明发票真实。选择无人值守签名前，应先记录这些决定。

Guardrails 与 Requests 解决的是不同授权问题

权限模型文档区分应用所有的钱包与用户所有的钱包。Guardrails 限制应用原本就能签的操作；Requests 则请求用户允许某类动作。在已启用权限模型下，如果没有规则决定结果，应用钱包可能直接签名，用户钱包则转给用户审核。

这对发票 Agent 很重要。阻止大额转账的规则，并不会自动变成其他所有操作的白名单。应先列出应用暴露的完整签名入口，包括消息与原始数据签名，不能只检查常规代币转账界面。

权限判断概念示意，非策略实测。最终结果取决于实际请求、适用规则及默认处理。

规则只能检查它能够获得的事实

详细的策略参考说明了一个重要例外：标准规则如果依赖无法从交易中解析出的细节，可能被跳过，随后由其他规则和默认处理决定结果。事实查询失败等其他未决情况，处理方式又不同。

我们的理解是，团队不能仅凭一个金额规则，就承诺“所有可能的资产移动都受限”。需要明确限制不需要的签名类型，并测试应用实际能提交的交易形状。对于只支付已知发票的流程，开放任意原始签名或任意合约调用之前，应有清楚的业务理由。

当 Para 签名器背后还有另一个智能账户时，尤其需要注意。签名可能授权一项操作，而最终资产移动并没有在当前请求里表现为普通转账。接入评审要沿着权限追到最终账户，不能只看到第一个 API 就停止。

日预算需要精确定义

规划指南说明，支出分别按钱包、网络与资产计量，使用固定时间窗口；其日额度示例在 UTC 零点重置。把同一额度配置给两条网络，不应向用户展示成跨链共用的一个总预算。

对这里的发票 Agent，先用普通语言写清规则：哪个钱包、哪种资产、哪条网络、哪些收款人，以及哪个会计时间窗口。如果财务需要多个钱包共用公司总额度，就要指出另外的汇总控制在哪里。否则界面显示一个数字，实际策略却允许多个独立预算。

建议测试刚低于上限、刚超过上限、临近额度耗尽时的并发请求，以及窗口切换时的请求。这些是待执行的验收建议，并非本文已观察到的结果。

生产策略是上线依赖

Para 权限文档说明 Development 与 Production 策略分开，生产启用和变更需要经过服务商审核路径；部分审批与可调限额功能也需要另外开通。因此，测试环境策略正确，并不是最后一个上线条件。

建议同时保存三份记录：团队打算实现的策略、适用时用户同意的版本，以及生产密钥上实际生效的策略。额度或收款人变化，应能沿这些记录追溯。等待策略审核时，运营方也应能够暂停新任务。

上线问题	团队应保留的证据
钱包归谁控制	应用或用户归属，以及匹配的策略类型
常规转账之外会发生什么	原始签名与合约调用测试结果
“每天”具体指什么	网络、资产、钱包范围及重置边界
生产是否已受保护	实际生效策略及必要功能开通状态
付款是否完成	与已批准发票关联的交易结果

我们的判断

Para 值得用于评估后台 Agent 钱包与用户同意后的自动化。相比笼统的“基础设施级保护”，其权限文档更有价值之处，是暴露了团队可以针对性测试的默认行为和解析边界。还应结合密钥管理模型一起审核：完整私钥不进入模型，并不意味着每个持有有效 API 权限的请求都合理。

相关资料见 Para 目录页与 Agent 额度设计。真正目标是一项范围有限、拒绝原因可解释的发票付款能力，而不只是让服务器可以签名。