Does an AI agent crypto wallet hold a real private key?

Not in the way a personal wallet does. In production, the private key lives in dedicated infrastructure — a secure enclave, an MPC network, or a managed signing API — and the agent only requests signatures through an interface. The key never enters the model's prompt or reasoning, because anything in an LLM's context can be logged or manipulated.

How do you stop an agent from draining its own wallet?

With a policy engine and scoped permissions. Spend limits cap how much can move per transaction and per day, allowlists restrict which contracts and addresses the agent can touch, and high-risk actions can require human approval. Account abstraction adds session keys — narrow, expiring, revocable grants — so the agent never holds full signing power over the whole balance.

What is account abstraction and why does it matter for agents?

Account abstraction (ERC-4337) makes a wallet a smart contract instead of a single all-powerful key. That lets you encode rules into the account itself and issue session keys scoped to specific actions and time windows. For an autonomous agent, it replaces one key that can do everything with many narrow keys that can do exactly one thing — a much smaller blast radius.

Privy vs Turnkey vs Coinbase AgentKit — which should an agent use?

They solve different layers. Privy gives you embedded wallets with a simple SDK. Turnkey provides enclave-based signing with a programmable policy engine for fine-grained control. Coinbase AgentKit is an agent framework with a wallet built in. Pick by priority: speed, policy granularity, or an all-in-one runtime — and note they can be combined.

Are agent wallets safe?

Safety depends entirely on configuration, not the label. The right custody (keys out of the prompt) plus tight policies (spend limits, allowlists, scoped session keys, approvals for irreversible actions) reduce the risk a lot — but prompt injection, policy gaps, and key leakage are real. Treat any "safe" or "secure" claim as unproven until the wallet controls and on-chain behavior actually show it.

← Back to wiki

How Agents Use Wallets

Last updated 2026-06-24

Agent wallets are key-management systems that let an AI agent sign transactions programmatically, ideally with policies, spend limits, and approval flows that constrain what the agent can do.

Key takeaways

▸Production agents do **not** hold a raw private key — keys sit in secure enclaves, MPC networks, or managed signing APIs, and the agent only *requests* signatures.
▸A **policy engine** sits between the agent and the signer: it checks every request against spend limits, contract allowlists, and time windows before approving.
▸Account abstraction ([ERC-4337](https://eips.ethereum.org/EIPS/eip-4337)) adds smart-contract accounts with **session keys** — narrow, revocable, expiring permissions instead of one all-powerful key.
▸Providers like [Privy](/resources/privy), [Turnkey](/resources/turnkey), and [Coinbase AgentKit](/resources/coinbase-agentkit) split the job differently — embedded wallets, raw signing infrastructure, and an agent framework with a built-in wallet.
▸"Safe" is a claim until the wallet controls show it. Whether an agent is actually constrained is something you check, not something you take on faith — that gap is what the [Sato Score](/sato-score) tracks.

An AI agent crypto wallet is the key-management system that lets an autonomous agent hold funds and sign its own transactions — without a private key ever sitting in a prompt, a log, or the model's reasoning. In production, the agent never touches raw keys. It asks an external signer to approve a transaction, and a policy layer decides whether the request is allowed before any signature happens.

This is the part of the stack that turns an onchain agent from a chatbot that *talks about* crypto into software that *moves value on a chain*. It is also the single largest risk surface: an agent with unconstrained signing power can lose everything it holds in one bad decision. This page covers where the keys actually live, how account abstraction reshapes agent signing, and how spend limits and signer policies keep autonomous execution inside a survivable blast radius.

Why It Matters

The wallet is what makes an agent onchain. It is also the single biggest risk surface: an agent with unconstrained signing power can lose everything it holds in one bad transaction. The agent wallet stack — embedded wallets, secure enclaves, policy engines, and scoped session keys — is what makes autonomous execution viable for real value instead of a demo with play money. Get the wallet layer right and an agent can pay, trade, and transact on its own; get it wrong and a single prompt injection drains the balance.

How It Works

▸Keys are held by infrastructure — secure enclaves (TEEs), MPC networks, or custodial signing APIs — never in the agent's prompt, code, or model context.
▸The agent constructs a transaction and requests a signature through an API; it never sees the private key material itself.
▸A policy engine evaluates each request against rules — spend limits, allowlisted contracts and addresses, per-action caps, and time windows — and rejects anything outside scope.
▸High-risk or irreversible actions can route to a human-approval step before the signer will sign.
▸With account abstraction, deployers issue **session keys**: narrow, time-boxed, revocable permissions that grant exactly the capability the agent needs and nothing more.
▸Every signature is logged, and a revocation or kill switch can cut the agent's signing power instantly if something looks wrong.

Key Components

•Key custody (TEE/enclave, MPC, or managed signing)
•Policy engine (spend limits, allowlists, approvals)
•Signing API
•Smart account / account abstraction layer (ERC-4337)
•Session keys and scoped permissions
•Audit logs
•Revocation and kill switches

Where the keys actually live

The first rule of agent wallets: the private key never goes near the model. An LLM's context can be logged, leaked, or manipulated by prompt injection, so putting a key there is a reliable way to lose funds. Instead, production setups keep keys in dedicated infrastructure and give the agent a *request-to-sign* interface, not the key itself.

Three custody patterns dominate:

▸Secure enclaves (TEEs). Keys are generated and used inside hardware-isolated environments (like AWS Nitro or Intel SGX) where even the operator can't read them. The agent sends a transaction in; a signature comes out. Turnkey is built on this model.
▸MPC (multi-party computation). The key is split into shares held by different parties, and signing happens collaboratively without ever reconstructing the full key in one place. Compromising one share isn't enough to sign.
▸Managed / embedded wallets. A provider runs the custody infrastructure and exposes a simple API or SDK. Privy and Coinbase AgentKit take this route, so builders get a wallet per agent without standing up enclaves themselves.

The trade-off is always custody versus convenience: the easier the wallet is to wire up, the more you should ask *who actually controls the keys* — the provider, the deployer, or the agent.

Account abstraction and session keys (ERC-4337)

A plain Ethereum account (an EOA) has exactly one key that can do anything: send the whole balance, approve any contract, sign any message. That is a terrible default for an autonomous agent. Account abstraction fixes the shape of the problem by making the account a smart contract instead of a single keypair.

ERC-4337 is the standard that brought this to Ethereum without changing the protocol. A smart account can encode its own rules about what counts as a valid transaction, which makes two things possible for agents:

Session keys. Instead of handing the agent the master key, the deployer mints a temporary key scoped to specific actions — for example, "swap up to 100 USDC on this one DEX, valid for 24 hours." When it expires or gets revoked, the agent's power is gone. The funds were never at full risk.
Paymasters and gas sponsorship. A smart account can let a third party pay gas, or pay gas in USDC, so an agent doesn't need to hold native ETH just to transact.

A newer path, EIP-7702, lets a regular EOA temporarily act like a smart account, bringing session-key-style scoping to plain keypairs. Either way the point is the same: replace one all-powerful key with many narrow, revocable ones. For the contract-call mechanics on top of this, see how agents interact with smart contracts.

Spend limits, scopes, and signer policies

Custody decides *who can sign*. Policies decide *what gets signed*. The policy engine is the layer that sits between the agent's request and the signer, and it is where most of the real safety lives.

Good policies are specific and layered:

▸Spend limits — caps per transaction, per day, and per counterparty (e.g. "no more than $500/day, $50 per transfer").
▸Allowlists — the agent can only call approved contracts and send to known addresses. Anything off-list is rejected before signing.
▸Action scoping — distinguish reads, swaps, transfers, and withdrawals; an agent might be allowed to trade but never to withdraw to an external wallet.
▸Time windows and rate limits — narrow when and how often the agent can act, so a runaway loop can't fire a thousand transactions.
▸Human-in-the-loop — route anything irreversible or above a threshold to a person for approval.

The failure mode to internalize: an agent can do anything its policies don't forbid. Policies are deny-by-default done right, allow-by-default done wrong. Start narrow, watch the audit log, and widen scope only when behavior earns it — never the reverse.

Privy, Turnkey, and AgentKit: who does what

These three names come up constantly, and they solve different layers of the same problem. Picking well means knowing which job you're actually outsourcing.

▸[Privy](/resources/privy) — embedded wallets as a product. It provisions a wallet per user or per agent with a clean SDK, handling key custody and recovery so a builder doesn't manage enclaves. Best when you want a wallet *attached to an app* fast.
▸[Turnkey](/resources/turnkey) — raw signing infrastructure built on secure enclaves, with a programmable policy engine as a first-class feature. You define who can sign what, and Turnkey enforces it inside the enclave. Best when policy granularity and verifiable custody are the priority.
▸[Coinbase AgentKit](/resources/coinbase-agentkit) — an agent framework with a wallet built in, wiring a managed wallet to a set of onchain actions an agent can call. Best when you want the agent *and* its wallet from one toolkit.

These aren't mutually exclusive — a stack might use Privy or Turnkey for custody underneath a framework's action layer. Browse the full set in the directory, and match the choice to your priority: speed, policy control, or an all-in-one runtime. None of these labels imply the setup is safe by default; that comes from how you configure the policies, which is on you to check.

Examples

▸A treasury agent with a $500 daily spend limit and a three-contract allowlist.
▸A trading agent using a policy-controlled signer that blocks withdrawals to unknown addresses.
▸A payments agent using x402 to pay per-request for API access in USDC.
▸A smart account that issues a 24-hour session key scoped to one DEX, then auto-revokes it.

Risks & Limitations

⚠Key leakage through logs, prompts, or compromised infrastructure.
⚠Policy gaps: an agent can do anything its policies don't forbid.
⚠Social engineering and prompt injection aimed at triggering transfers.
⚠Custody questions: who actually controls the agent's funds — provider, deployer, or agent?

Frequently Asked Questions

Does an AI agent crypto wallet hold a real private key?: Not in the way a personal wallet does. In production, the private key lives in dedicated infrastructure — a secure enclave, an MPC network, or a managed signing API — and the agent only *requests* signatures through an interface. The key never enters the model's prompt or reasoning, because anything in an LLM's context can be logged or manipulated.
How do you stop an agent from draining its own wallet?: With a policy engine and scoped permissions. Spend limits cap how much can move per transaction and per day, allowlists restrict which contracts and addresses the agent can touch, and high-risk actions can require human approval. Account abstraction adds session keys — narrow, expiring, revocable grants — so the agent never holds full signing power over the whole balance.
What is account abstraction and why does it matter for agents?: Account abstraction (ERC-4337) makes a wallet a smart contract instead of a single all-powerful key. That lets you encode rules into the account itself and issue session keys scoped to specific actions and time windows. For an autonomous agent, it replaces one key that can do everything with many narrow keys that can do exactly one thing — a much smaller blast radius.
Privy vs Turnkey vs Coinbase AgentKit — which should an agent use?: They solve different layers. Privy gives you embedded wallets with a simple SDK. Turnkey provides enclave-based signing with a programmable policy engine for fine-grained control. Coinbase AgentKit is an agent framework with a wallet built in. Pick by priority: speed, policy granularity, or an all-in-one runtime — and note they can be combined.
Are agent wallets safe?: Safety depends entirely on configuration, not the label. The right custody (keys out of the prompt) plus tight policies (spend limits, allowlists, scoped session keys, approvals for irreversible actions) reduce the risk a lot — but prompt injection, policy gaps, and key leakage are real. Treat any "safe" or "secure" claim as unproven until the wallet controls and on-chain behavior actually show it.