Para: Agent Wallet Permissions Depend on Ownership and What the Signer Can Read

A company wants an operations agent to pay approved software invoices. Some payments use the company’s wallet; others use a customer’s wallet after consent. Those two workflows may look similar in an API client, but their authorization starts from opposite positions: restrict authority the application already has, or obtain authority from someone else.

Research boundary: official Para materials reviewed November 1, 2026. This is a documentation-based analysis, not a wallet or policy penetration test. The invoice workflow is hypothetical.

One product, including the old Capsule name

Para’s REST API page identifies Para as formerly Capsule and describes programmatic wallet creation and signing. We treat the names as one product lineage, not two competing wallet entries. The agent product page positions its MPC wallet infrastructure for automated transactions with policy controls.

For an implementation decision, separate those capabilities from the business workflow. Creating a wallet does not establish who owns its funds, which service may request signatures, or whether an invoice is authentic. Record those decisions before choosing an unattended signing path.

Guardrails and Requests solve different authorization problems

The permission model distinguishes app-owned wallets from user-owned wallets. Guardrails narrow what the app may sign from wallets it controls. Requests ask users to authorize a class of actions. When no rule decides a request, an app-owned wallet can sign, while a user-owned wallet goes to user review under the active permission model.

That default is important for the invoice agent. A rule blocking large transfers is not automatically an allowlist of everything else the wallet may do. Start by enumerating the signing operations your application exposes, including messages and raw signatures, rather than reviewing only the normal token-transfer screen.

Conceptual permission decision flow, not a policy test. The decision is evaluated against the actual request and applicable defaults.

A limit can only inspect facts that are available

The detailed policy reference explains an important decoding exception: when a standard rule depends on transaction details that cannot be decoded, that rule can be skipped. Other rules and defaults then decide the request. Different unresolved conditions, such as a failed fact lookup, have different handling.

Our reading is that teams should not promise “every possible movement is capped” merely because they configured an amount rule. Restrict unwanted signing classes explicitly and exercise the exact transaction forms the application can submit. For a workflow that only pays known invoices, unrestricted raw signing or arbitrary contract calls deserve a clear business justification before they are enabled.

This is especially relevant when another smart account sits behind the Para signer. A signature can authorize an operation whose eventual asset movement is not represented as a simple transfer in the request. The integration review needs to follow authority to the final account, not stop at the first API endpoint.

A daily budget needs a precise definition

The planning guide describes spending totals per wallet, network and asset, with fixed windows. Its daily example resets at midnight UTC. A single allowance configured for two networks should not be presented as one pooled cross-network budget.

For the hypothetical invoice agent, write the product rule in ordinary language first: which wallet pays, which asset, which network, which recipients and which accounting window. If finance wants a company-wide cap shared by several wallets, identify the additional mechanism that aggregates it. Otherwise the UI could display one number while the configured policies allow several independent budgets.

A useful test set includes a request just below the limit, one just above it, two concurrent requests near exhaustion, and a request at the window boundary. These are proposed tests, not observed outcomes.

Production policy is an operational dependency

Para’s permission documentation describes separate Development and Production policies and a provider review path for production activation and changes. Some approval and adjustable-limit features also require enablement. A beta policy working correctly is therefore not the final launch milestone.

Plan for three records: the policy your team intends, the version a user has accepted where relevant, and the policy actually active on the production key. A change to a budget or recipient list should be traceable through all applicable records. The operator also needs a way to suspend new work while a policy change is awaiting review.

Release question	Evidence the team should retain
Who owns this wallet?	App or user ownership and the matching policy type
What happens outside the normal transfer path?	Raw-signing and contract-call test results
What does “daily” mean?	Network, asset, wallet scope and reset boundary
Is production protected?	Active production policy and required feature enablement
Did payment finish?	Transaction outcome linked to the approved invoice

Our assessment

Para is worth evaluating for backend agent wallets and user-consented automation. Its permission documentation is more useful than a generic claim of infrastructure-level guardrails because it exposes defaults and decoding boundaries a team can test. Review the key-management model alongside those policies: keeping a full private key away from the model does not make every request made with valid API authority acceptable.

Continue with the Para reference and agent spending-limit design. The goal is a narrow invoice-payment capability with an explainable refusal path, not simply a wallet that can sign from a server.