# What AI agents on Solana use for spending limits today

*Research cut-off: 15 October 2026. One-page desk review; “documented” below means a primary source describes the capability, not independently verified deployment or adoption.*

**Answer.** Documented Solana agent tooling combines delegated signing authority with limits enforced by token programs, smart-wallet programs, or a hosted signer. Session keys identify an agent and can bound its access window; the spending ceiling depends on the permissions attached to that authority. The sources establish available integrations and a devnet demonstration, but do not establish which mechanism most production agents use.

| Mechanism | Documented controls and enforcement | Evidence of agent use / limits of evidence |
| --- | --- | --- |
| **Session keys + policy wallet: Swig** | Swig describes onchain program, token, and spend policies. Its MCP interface supports session-based authorities, one-time SOL/token allowances, recurring allowances, SOL destination limits, and program permissions. These are distinct permissions, not an automatic consequence of generating a session key. | The first-party MCP server explicitly connects AI agents to Swig wallets: concrete integration evidence, without production usage counts. Sources: [Swig](https://onswig.com/), [MCP permissions and tools](https://github.com/anagrambuild/swig-ts/blob/main/packages/mcp-server/README.md). |
| **Token-account delegates** | Solana Token Programs let an owner approve a delegate up to an amount and revoke it. Each token account has one active delegate; a new approval replaces the old one. This is a token-account allowance, not a wallet-wide SOL budget. | A documented base primitive for automated spending; the cited page does not identify an AI-agent deployment. Its basic approval does not provide the recurring-window and recipient-policy features described for the programs below. Source: [Solana spend permissions](https://solana.com/docs/payments/advanced-payments/spend-permissions). |
| **Vault policy: Squads** | A spending limit lets a member withdraw a specified token amount without full multisig approval. Parameters include source account, reset period (or a non-resetting allowance), and destinations. Limits are managed through configuration transactions. | Coldstar documents an agent session key spending through Squads, with local signer policy layered over the onchain ceiling. Its reported successful transfer is **devnet**; this is a vendor demonstration, not evidence of broad mainnet adoption. Sources: [Squads controls](https://docs.squads.so/main/navigating-your-squad/settings/spending-limits), [configuration](https://docs.squads.so/main/development/reference/spending-limits), [Coldstar demo](https://coldstar.dev/agent-spending-limits). |
| **Hosted signer policy: Privy** | Privy advertises Solana agent wallets with programmable guardrails. Its security documentation places policy enforcement in the signing infrastructure: generally the enclave, with transfer-size checks using simulation outside the enclave at the API layer. This is a different enforcement boundary from an onchain vault program. | Explicit agent-wallet product support; the cited sources do not quantify Solana-specific agent adoption or establish every policy's Solana coverage. Sources: [agent wallets](https://www.privy.io/agent-wallets), [enforcement details](https://docs.privy.io/security/wallet-infrastructure/policy-and-controls). |

**Another available policy program — documented capability, agent adoption unproven here.** Solana's [Subscriptions Delegation Program](https://solana.com/docs/payments/subscriptions/overview) puts a program-controlled authority behind the token approval, then checks separate authorizations. It supports fixed allowances with optional expiry and recurring limits. This adds multiple spending arrangements above the token account's single-delegate primitive; it is not evidence that agents have adopted it.

**Inference.** The meaningful distinction is who rejects overspending and whether the agent can bypass that authority. A session key needs a capped role or signer policy; a per-transfer cap alone does not bound cumulative spending. Restricting authority management is also necessary if an agent could otherwise raise its own ceiling. These are architectural conclusions, not measured guarantees for the named products.

**Uncertainty / unanswered questions.** Which mechanisms dominate live agents? What budgets, reset semantics, and revocation delays do deployed configurations actually use? Do fees, swaps, delegated approvals, and alternate signing paths fall inside each budget? This review did not inspect deployed accounts, audit code, or execute transactions, so it cannot certify those properties or comparative security.