Staying in control
Should you give an AI agent a crypto private key?
Why a private key in an agent's prompt, config or environment is full control of the wallet, and what to do instead to let it pay without one.
Generally no. Whoever holds a private key controls everything the address holds, with no limits and no undo, so an agent with the key can be talked into moving all of it. Keep keys out of the agent and give it a payment tool with limits enforced elsewhere.
Why is this harder than it sounds?
A key is not a permission; it is ownership. Blockchains don't know about per-payment limits or approved recipients unless a contract enforces them, and a raw key bypasses all of that. Agents also leak. They summarise, quote and log their context, call other tools with it, and follow instructions embedded in what they read. OWASP lists prompt injection as the top risk for LLM applications precisely because a model cannot reliably separate instructions from data. Putting the key in an environment variable instead of the prompt helps less than it seems if the agent can run code that reads the environment.
How do you do it?
- Keep the key in a wallet the agent can't reach. Hold funds in a wallet you sign with yourself: a browser extension, a passkey smart wallet or a hardware wallet.
- Give the agent a request tool. The agent asks for a payment with amount, recipient and reason; something outside the agent decides.
- If you must delegate, delegate a cap. For unattended payments, grant a capped token allowance or use a smart-contract permission rather than handing over the key, and size the cap as money you could lose.
- Use a separate float for experiments. If you want an agent to hold a key while you experiment, give it a fresh address with only what you'd be willing to lose.
- Assume anything in context can leak. Don't put keys, seed phrases or exchange API secrets in prompts, files the agent can read, or tool results.
What it does not mean
- A 'burner' wallet is still full control of its balance. It limits the loss, not the access.
- Encrypting the key doesn't help if the agent also has the decryption password.
- Telling the agent never to reveal the key is not a control. Instructions in context can be overridden by other instructions in context.
Common questions
What about an exchange API key with withdrawals turned off?
A key that can't withdraw is far less dangerous than a wallet key, but then it can't pay either. Exchange keys that can withdraw deserve the same caution as a private key.
Is this financial or security advice?
No. It describes how keys and delegation work so you can decide for yourself.
Where does Veyra fit?
Veyra exists so you don't have to do this. It never asks for a seed phrase or private key. Payments above your auto-approve limit, and every payment on the Free plan, are signed by you in your own wallet. For unattended payments on Pro and Team, you grant a capped ERC-20 allowance on USDC to Veyra's relayer: the token contract enforces the cap, and your recipient allowlist constrains the destination. You can revoke that allowance at any time.
Sources
Terms on this page
- Token allowance (ERC-20 approve)A token allowance is the amount of an ERC-20 token that an owner has authorised a specific spender address to transfer from the owner's account, set with approve and spent with transferFrom.
- Stablecoin (USDC)A stablecoin is a blockchain token designed to keep a stable value relative to a reference asset, usually a currency such as the US dollar; USDC is a dollar stablecoin issued by Circle.
This page explains how agent payments and the related technology work. It is not financial, investment, legal or tax advice. Protocols and provider features change; check the linked official sources before relying on a detail.