Privy Agent Wallets: Embedded Wallets and Programmable Permissions

Product analysis · Public sources reviewed October 28, 2026 · No account registration or hands-on test.

A developer who wants an agent to buy API access needs a payment instrument, but giving the entire agent environment a private key can expand risk. Privy provides embedded wallets, login, signing and policy tools for applications to configure restricted agent access. It primarily serves developers; end users generally interact with the wallet inside the developer’s product.

Background and users

Privy began with login and embedded-wallet infrastructure and later joined Stripe. It continues to provide developer products; Stripe payment products and Privy wallet infrastructure should be evaluated and priced separately. See Stripe’s annual update and Agent Wallets.

Participant	Goal	Privy’s part
Application developer	Create and manage user or agent wallets	API, SDK, login and wallet services
User	Review the agent’s wallet access	Authorization flow, configurable policies and approvals
Agent	Call paid services within permissions	Request controlled signatures and transactions
Merchant	Verify payment and deliver	Must be handled by the relevant merchant and payment solution

An illustrative controlled purchase

sequenceDiagram participant U as User participant A as Agent application participant P as Privy wallet and policy participant M as Data provider U->>A: Log in and review authorization A->>P: Create or connect wallet and configure policy A->>M: Request paid data M-->>A: Return payment requirements A->>P: Request signature P->>P: Check configured limits and rules P-->>A: Return signature if allowed A->>M: Submit credential and obtain data

Privy describes scoped access using authorization keys, policies and approvals. Policies can involve per-transaction or time-window spending, contract and address targets, expiry and approvals; applicability depends on configuration, chain and product. See authorization and policy controls and the policy-engine introduction.

Permission design matters more than a wallet label

Question	What to examine
Who controls the wallet?	Provider distinguishes developer-owned and user-owned modes; verify what administrators and users can change
What does the agent hold?	Restricted access still uses credentials; protect tokens and the environment
Where are limits enforced?	Privy describes infrastructure enforcement; check configuration, signature type and network
Can access be revoked?	Test revocation timing, pending requests and previously approved external contracts
Is the purchase worthwhile?	Policies can restrict targets and amounts, but cannot guarantee content quality or agent judgment

Pricing and business model

Public pricing lists a free developer tier, Core and Scale tiers by monthly active users, enterprise customization, and monthly signature and transaction-volume allowances. Prices depend on plan, definitions and usage; confirm the current schedule. Privy sells wallet, identity and transaction infrastructure to developers; network, conversion and partner services may cost extra. Inference: growing user and transaction volumes may lead developers to upgrade or buy more services. Privy has not disclosed separate Agent Wallet revenue.

Adjacent alternatives

Compared with Turnkey’s lower-level signing and key emphasis, Privy combines login, embedded experience and wallet policy in one developer product. Unlike a wallet used directly by an end user, the application team must define the experience and operations. Teams embedding wallets in existing agent products may find this appealing; those needing self-hosting, specific compliance responsibilities or strict funds control must review contracts, recovery and deployment.

Where is policy enforced?

Privy’s security documentation says that by default a secure enclave evaluates wallet-action policy before signing or exporting key material, and requests also require a registered authorization public key’s signature. Users, servers or multiple participants can be configured as owners and authorization-key thresholds. Authorization keys prove who may request action from the wallet service; wallet keys produce transaction signatures. They are different keys.

The same documentation says compliance screening or transaction simulation may run outside the enclave depending on chain, method and configuration. Those checks are not the same as policy execution within the enclave. Simulation can inform a decision but cannot replace verifying what is actually enforced. Ask which signatures and exports are protected, who can change policy, and whether every relevant network and signing method is covered.

A user-facing integration

A research app enabling data purchases might evaluate the following, subject to current APIs and eligibility:

Create a Privy application, choose login and determine whether authority is user-held, server-controlled or shared.
Create or connect a wallet and show the user assets and networks; funding, conversion and region limits depend on the provider and integration.
Give the agent restricted access and configure signing policies for recipients, amounts and expiry. Verify enforcement on the target network and signing method.
Submit an action when the service requests payment; sign only after authorization, policy and any approval. The merchant still handles data delivery.
Record the transaction hash, order and task; test again after revocation, and inspect already signed transactions and external-contract authorizations.

The EVM transaction documentation distinguishes signing and broadcasting and describes gas sponsorship for some transactions. A transaction hash is not proof of service delivery or final on-chain confirmation.

What does a purchase cost?

Imagine an app with 1,000 monthly active users, 10,000 monthly signatures and $1,000 of transaction volume. The public tiers might place it in the 500–2,499 MAU Core tier listed at $299 per month. This illustrates a billing unit, not a guaranteed invoice. Verify MAU definitions, included quantities, signatures and volume against current rules, then add network, funding, conversion and merchant costs. See Privy pricing.

One purchase need not equal one billable operation: creation, signing, retries and conversion may involve different services. A complete quote based on expected user count, signing volume, network and transaction volume is more reliable than comparing a single transaction amount.

Fit and failure cases

Privy’s advantage is the combination of login, wallet, authorization and developer tooling for teams building an integrated user experience. Turnkey also supplies signing and policies; compare control models, networks and prices on the same task instead of deciding from a “non-custodial” label.

A policy cannot tell the user why an unfamiliar data provider is trustworthy. If an administrator can unilaterally loosen rules, the visible transaction cap is not the only risk boundary. Ask teams to demonstrate over-limit and wrong-address or wrong-chain rejection, revocation, administrator audit records, timeout status checks, and the separate outcomes of simulation and actual signing policy.

Sources: product page, authorization and controls, policy explanation, and pricing.