Stop pasting private keys into Cursor: how to give your coding agent a wallet

You are deep in a build. Your agent in Cursor has written the contract call, picked the network, and is ready to send a test transaction. Only one thing stands between the plan and a signed transaction: a key. So you paste a private key into a .env file the agent can read, and keep building.

That single step is why many experienced developers keep AI away from anything that touches real funds. A private key is all or nothing. Once your agent can read it, it can move everything in that wallet, on any chain, permanently, with no way to undo it. And an agent is probabilistic by design: very good most of the time, occasionally confidently wrong.

There is a better way to do this. You give the agent a wallet without giving it the key. Below is how that works with agent wallets in the Alchemy CLI, and where the real limits are.

The problem is the key, not the agent

It is tempting to treat the agent as the risk, but the agent is not really the problem. A private key was never designed to be shared. It has no concept of "you can send up to this much," "only on these chains," "only for the next hour," or "actually, stop now." It is a single secret that grants total control, and the only way to use it is to expose it.

Until now, developers have had two options, and both come with real costs. You can paste the key into .env and accept that the agent has full control of the funds, which leaves you one stray prompt away from a drained wallet. Or you can wire a wallet SDK into a custom backend and rebuild auth, signing, and revocation yourself, which is weeks of work most teams should not take on. The first is too risky, and the second is too expensive.

What you actually want is closer to how you already think about access everywhere else in your stack. You do not hand out the root password. You issue a scoped credential, you set what it can do, and you revoke it when you are done. A wallet should work the same way.

How agent wallets work

Agent wallets in the Alchemy CLI let you create a wallet from the dashboard, grant your terminal a scoped and time-bound session, and let the agent send real transactions from the command line. The private key never touches the CLI, never touches Alchemy, and never sits in a .env file. It helps to see it as three layers, each owned by a different party.

The custody layer: someone else holds the key

The wallet's private key is held by Privy, our embedded wallet partner, on their infrastructure. It is not on your laptop, not in your repo, and not in our systems. This is what changes the risk calculation. The secret you were about to paste into .env is now something neither you nor your agent ever handles directly.

The session layer: the agent gets permission, not the secret

When you run alchemy wallet connect, the CLI generates a fresh P-256 keypair on your machine, and the private half of that pair never leaves the device. Your browser opens to the Alchemy dashboard, where you pick the wallet and approve a session. Approval attaches your CLI's public key as a signer on that wallet, scoped to specific capabilities and bounded by an expiry you set.

From then on, every signing call is a two-step challenge. Our backend builds the exact payload Privy expects, your CLI signs those precise bytes locally, and only then does the request reach Privy. If the session has expired, been revoked, or fails any binding check, the next signing attempt is rejected before it ever leaves our infrastructure. The agent is acting through a session you defined, not through a secret it holds.

The control layer: you keep the kill switch

The dashboard is the only place a wallet is created or revoked, and revocation is one click that takes effect immediately. You can also run alchemy wallet disconnect from the terminal. If a session starts doing something you did not intend, you end it and the signing stops. You are never left simply hoping a session behaves, because you can always end it.

What the agent can actually do

Once a session is live, the agent has a full transaction surface to work with. On EVM chains it can send native tokens and ERC-20s, make contract calls, manage ERC-20 approvals, swap, and bridge between mainnets. On Solana it can send SOL and SPL tokens. Transactions run through our Wallet APIs, so gas sponsorship through the Gas Manager, batching, automatic retries, and ERC-20 gas payments come with them.

Because the CLI was built as a tool surface for agents, your agent picks these commands up on its own. The --json flag returns structured output, --no-interactive keeps commands from blocking on prompts, and alchemy agent-prompt emits a JSON document describing every command, flag, and error code. Drop that into a system prompt and the agent learns the full surface at once. There is no SDK to integrate and nothing for it to infer from documentation.

Who this is for and the flows it fits

This is for the developer who lives in Cursor or Claude Code and builds onchain: someone integrating a DeFi protocol, wiring up a payments flow, or testing a contract, who wants the agent to actually run transactions instead of stopping at the point where a signature is needed. If you have ever let the agent write the code and then finished the onchain part by hand, this closes that gap. Two flows show where it earns its place.

The first is the build-and-test loop. You are integrating against a protocol, and your agent has written the code. To know whether it actually works, someone has to send real transactions: fund the contract, call it, check the resulting state, adjust, and run it again. Doing that by hand means you approve and paste every transaction yourself, which is exactly the tedium you brought the agent in to remove. With a session, you create a wallet, fund it with a small balance, approve a session scoped to a short expiry, and let the agent run the whole loop. It sends, reads the result, and iterates while you watch, and when the session expires its access ends on its own.

The second is an agent that runs a multi-step onchain task. Some work is a sequence rather than a single call: swap a token on mainnet, bridge the proceeds to an L2, then deposit into a position. You can describe the outcome and let the agent carry out the steps through the session, instead of executing each one yourself. The session limits which capabilities the agent can use and for how long — not how much it can move — so fund the wallet with what the task needs, set a short expiry, and revoke when you are done.

An honest look at the boundaries

A tool that handles money is easier to trust when its makers are clear about where it stops. Here are a few limits worth knowing before you rely on this in production.

Gas and fee sponsorship policies control transaction fees. They are not wallet spend limits, so do not treat a Gas Manager policy as a cap on what the agent can move. Swaps and bridges are EVM mainnet only today. The session signer does not do direct raw EVM transaction signing; actions execute through Alchemy Wallet API calls such as wallet_prepareCalls and wallet_sendCalls. And the session is exactly as scoped as you make it in the dashboard, so the expiry and capabilities you set are the real boundary, not a suggestion.

None of this is a workaround; it is how the system is meant to work. The wallet keeps custody, the session carries permission, and you keep the ability to end it.

Getting started

Agent wallets in the CLI are live now, with no waitlist and no separate tier. You need Node 22 or higher and an Alchemy account. Three commands get you to an agent-controllable wallet:

The connect step opens the dashboard, where you approve the session and set its scope and expiry. Before any state-changing workflow, have the agent verify the session first:

When the work is done, end the session:

The teams building the most demanding products onchain already run on Alchemy, moving more than a trillion dollars a year across 100+ chains. The point of agent wallets is that the same infrastructure now backs the wallet you hand to your coding agent, without handing over the key. Instead of pasting a private key into Cursor, you can give the agent a scoped session and keep the ability to revoke it at any time.

Read the agent wallets docs, explore Alchemy for agents, or install the CLI to try it.

FAQ

How do I give an AI coding agent a wallet without sharing my private key?

Create a wallet in the Alchemy dashboard, then run alchemy wallet connect --mode session in your terminal. The CLI generates a local keypair and the dashboard approves a scoped, time-bound session. The agent sends transactions through that session, while the private key stays with the wallet provider and is never exposed.

Where is the private key actually stored?

The wallet's private key is held by Privy, Alchemy's embedded wallet partner, on their infrastructure. It is never written to your machine, your repository, or a .env file, and it never touches the CLI or Alchemy's own systems. Your agent acts through an approved session rather than through the key itself.

Can I revoke an agent's access to the wallet?

Yes. Revoke the session from the Alchemy dashboard with one click, or run alchemy wallet disconnect from the terminal. Revocation takes effect immediately, and the next signing attempt from that session is rejected. Sessions also expire automatically at the time you set when you approve them.

What can the agent do with an agent wallet?

On EVM chains, an agent can send native tokens and ERC-20s, make contract calls, manage approvals, swap, and bridge between mainnets. On Solana, it can send SOL and SPL tokens. Transactions run through Alchemy's Wallet APIs, so gas sponsorship, batching, retries, and ERC-20 gas payments are available.

Do sponsorship policies limit how much an agent can spend?

No. Gas and fee sponsorship policies control transaction fees, not wallet balances. They are not spend limits. The real boundary on what an agent can do is the capabilities and expiry you set on the session in the dashboard, so scope the session deliberately.

What do I need to start?

You need Node 22 or higher and an Alchemy account. Agent wallets in the CLI are live with no waitlist and no separate tier. Install with npm i -g @alchemy/cli@latest, run alchemy auth, then alchemy wallet connect --mode session to approve a session from the dashboard.