Give every AI agent a wallet it can't abuse
Give agents spending power inside guardrails you define — session keys, spend caps, and x402 payments. The key stays in a TEE, the scope is enforced on-chain, and you can revoke it in one call.
No credit card required • Free testnet accounts
Give the agent a key. Keep the rules.
Issue a session key scoped by contract address, function selector, spend cap, and expiry. The agent signs transactions inside the policy. Revoke instantly. No shared secrets, no off-chain trust.
HTTP-native payments for agents
Openfort agent wallets natively support x402 for HTTP-native payments, plus subscriptions, batch operations, and one-click purchases. Drop the agent in front of paid APIs and let it pay per call inside its policy.
The agent never holds its own key
Agent keys are generated and used inside a trusted execution environment — GCP Confidential Space, with AMD SEV-SNP memory encryption. The private key is encrypted at rest with AES-256-GCM under a data encryption key unique to that wallet, and that key is wrapped by an HSM-backed key in Cloud KMS that only an attested workload can unwrap. Plaintext key material exists only in enclave memory for the duration of a signature, then the memory is zeroed. For embedded wallets you can run the signer yourself: OpenSigner (opensigner.dev) is open source and self-hostable.
Key handling
Where the key lives, and who can use it
An autonomous agent signs without a human approving each transaction, so the storage model, the scope, and the revocation path are the whole security argument. Here is ours, in full.
- Where the key is stored
- Each agent wallet private key (secp256k1 or ed25519) is encrypted with AES-256-GCM under a data encryption key unique to that wallet. The data encryption key is itself encrypted by an HSM-backed key encryption key in Cloud KMS, bound to the wallet address as additional authenticated data so a key cannot be swapped between wallets. A stolen database yields nothing without KMS access and a valid enclave attestation.
- Where signing happens
- Inside a GCP Confidential Space trusted execution environment with AMD SEV-SNP memory encryption. The enclave has no persistent storage, no interactive access, and no external networking. Cloud operators with root on the host cannot read enclave memory. Your agent process never receives key material — a prompt injection can attempt a transaction, but it cannot exfiltrate a key.
- How the agent’s authority is scoped
- Two independent layers. A session key is a separate keypair authorized on the smart account via ERC-7715, bounded by contract address, function selector, spend cap, and a validAfter/validUntil window — enforced on-chain, so a counterparty contract can verify the limits without trusting our API. A signing policy is evaluated server-side on every operation against value caps, address allowlists and denylists, chain IDs, decoded calldata, and Solana mint and program addresses.
- What happens when no rule matches
- The operation is rejected. The policy engine is fail-closed: once any policy exists on a project, anything outside your allowlist is denied before it reaches the chain. Rules are ordered by priority and the first match wins. Call policies.evaluate() to pre-flight an action and get back the matched policy and rule ID before spending gas.
- How authority is revoked
- Two paths, either of which is sufficient. POST /v1/sessions/revoke, signed by the account owner, removes the session key’s authority on-chain. Disabling or updating a signing policy takes effect on the agent’s next operation. The wallet secret that authorizes backend signing can be rotated from the dashboard. Give each agent its own wallet so it can be audited, rate-limited, and revoked without touching the others.
- What signing latency looks like
- Measured end-to-end, not enclave-only: median signMessage round trip of 104 ms in Frankfurt, 106 ms in London, 175 ms in N. Virginia, 247 ms in Oregon, and 327 ms in Tokyo for EVM — 97–322 ms for Solana across the same regions. Measured with the open-source Slate benchmark at 20 iterations per region, last updated January 2026. Latency is dominated by the network path to the signer, so benchmark from your own region.
Openfort does not hold SOC 2 Type II. What we publish instead is five dated independent audits — CertiK (December 2023), Cure53 (September 2024), Omniscia (December 2024), and Quantstamp (September 2025 and October 2025) — and the signer source itself. See the security page, the signing benchmarks, or compare the key model against other providers in best AI agent wallets for developers.
Everything an agent needs to transact
Spending power for agents, control for you — one SDK for keys, policies, and payments.
Session keys, scoped and revocable
Grant access by contract, spend cap, and expiry. Revoke instantly — no shared secrets.
Spending limits that hold
Caps and contract allowlists enforced at signing time — not in the prompt.
x402 payments
HTTP-native pay-per-call. Put an agent in front of paid APIs and let it pay inside its policy.
pay()Subscriptions built in
Recurring charges approved once, then enforced under the limits you set.
Batch operations
Bundle many actions into one transaction for cheaper, atomic execution.
Every action, on the record
Signed webhooks on each agent transaction — monitor, alert, and reconcile in real time.
- 1M+
- wallets created
- 10M+
- transactions
- <200ms
- signing speed
- 99.99%
- uptime
Build the rest of the stack with Openfort
Agent wallets plug into the same SDK as embedded wallets, smart accounts, and wallet automations.
Embedded wallets
Non-custodial embedded wallets powered by OpenSigner, with full key export and self-hosting options. Read more
ERC-4337 smart accounts
Native ERC-4337 + EIP-7702 smart accounts with paymasters, session keys, and batched operations. Read more
Wallet automations
TEE backend wallets for server-side key storage with permissions and automatic transaction execution. Read more
Frequently Asked Questions
Can't find your answer?
An agent wallet is a non-custodial wallet purpose-built for AI agents. It uses programmable session keys, policy-based spending limits, and HTTP-native payment standards like x402 so an agent can transact autonomously inside the rules you define — how much it can spend, which contracts it can call, when its access expires.
Create a non-custodial wallet for the agent with the Openfort SDK, attach a session key scoped by contract address, spend cap, and expiry, and let the agent sign transactions inside that policy. Full guide and code at openfort.io/docs/overview/building-with-cli.
Openfort provides embedded wallets purpose-built for AI agents: keys generated and used inside a trusted execution environment, programmable on-chain session keys, a fail-closed policy engine, on-chain revocation, and x402 support. Agents get their own non-custodial wallet, and you control what they can sign, how much they can spend, and which contracts they can call.
Yes. Openfort agent wallets natively support x402 for HTTP-native agent payments alongside session keys, subscriptions, batch operations, and one-click purchases.
Agent wallet keys are generated and used inside a GCP Confidential Space trusted execution environment with AMD SEV-SNP memory encryption, and are encrypted at rest with AES-256-GCM under a per-wallet data encryption key wrapped by an HSM-backed key in Cloud KMS. Only an attested enclave workload can unwrap it, so cloud operators and a stolen database both come up empty. Session keys add a second layer: even if a key leaks, the on-chain policy still enforces spending caps and contract allowlists. For embedded wallets you can self-host the signer with OpenSigner, which is open source.
Inside the TEE, never in the agent process. The enclave has no persistent storage, no interactive access, and no external networking, and plaintext key material exists only in enclave memory for the duration of a signature before the memory is zeroed. Your agent receives a signature, never a key — so a prompt injection can attempt a transaction, but it cannot exfiltrate the key.
Two independent paths, either of which is sufficient. Call POST /v1/sessions/revoke, signed by the account owner, to remove the session key’s authority on-chain. Or disable or update the signing policy, which takes effect on the agent’s next operation because the policy engine is fail-closed — once a policy exists, anything that matches no rule is rejected. The wallet secret authorizing backend signing can also be rotated from the dashboard. Give each agent its own wallet so you can revoke one without touching the others.
Median signMessage round trip is 104ms in Frankfurt, 106ms in London, 175ms in N. Virginia, 247ms in Oregon, and 327ms in Tokyo for EVM, and 97-322ms for Solana across the same regions. These were measured with the open-source Slate benchmark at 20 iterations per region and last updated January 2026 — they are end-to-end round trips, not enclave-only signing times, so they are not comparable to vendor figures that measure only the signing operation. Full data at openfort.io/benchmarks.
Yes. Openfort supports multiple wallets per user across EVM and Solana chains. You can give each agent its own wallet with its own policy, or share one wallet across agents with per-agent session keys. One wallet per agent is the recommended default, because it lets you audit, rate-limit, and revoke each agent independently.