Klow Wallet Security Model: How AI Agents Manage Real Money

An AI agent that can't transact is a chatbot with extra steps. But an AI agent that can transact without proper security is a liability. If you're building autonomous agents that touch real money — DeFi swaps, treasury management, on-chain payments — the wallet architecture isn't a nice-to-have. It's the entire foundation.

This post explains exactly how Klow agents manage real funds: how keys are stored, how transactions are approved, how spending policies work, and why the "paste your private key in an env var" approach is a ticking time bomb.

The anti-pattern: shared keys and env vars

Most agent frameworks handle crypto the same way: you generate a wallet somewhere, export the private key, and paste it into an environment variable. The agent reads the key at runtime, signs whatever it wants, and you hope nothing goes wrong.

This is how funds get stolen. Private keys in env vars end up in logs, error traces, CI pipelines, and Docker images. One leaked key means total loss — there's no "change your password" in crypto. Worse, if multiple agents share a key (common in team setups), a single compromised agent drains every wallet.

Klow doesn't work this way. Every agent gets its own isolated wallet with its own key, and that key never exists in plaintext outside of the signing moment.

Per-agent key isolation

When you deploy a Klow agent, a fresh cryptographic keypair is generated using a secure random number generator. The private key is immediately encrypted with AES-256-GCM — the same encryption standard used by banks and government agencies — and stored in the database. The plaintext key exists in memory only during the milliseconds it takes to encrypt it.

Each agent has its own key. Your DeFi Scout and your Treasury Manager don't share a wallet. If one agent is compromised, the blast radius is limited to that agent's funds. This is the same principle behind hardware security modules in traditional finance — isolation by default.

We explicitly banned deterministic key derivation early in development. An earlier design derived keys using HMAC(master_key, agentId), which meant one leaked master key would compromise every wallet on the platform. That code was removed and the approach is documented as a hard rule in our engineering guidelines.

AES-256-GCM encryption at rest

Private keys are encrypted with AES-256-GCM before they touch the database. GCM mode provides both confidentiality and authenticity — if someone tampers with the encrypted blob, decryption fails rather than producing a corrupted key. Each encrypted value uses a unique initialization vector, so identical keys produce different ciphertexts.

The encryption key itself is stored as an environment variable on the API server, never in the database and never in the agent container. The agent container never sees the raw private key — it proposes transactions, and the API server decrypts the key server-side to sign them.

We also built key rotation support from day one. Each encrypted value is tagged with a key version. When you rotate the encryption key, a migration script re-encrypts all values with the new key. The old key can then be safely retired.

The approval flow: trust gradients, not binary access

Encryption protects keys at rest. The approval flow protects funds in motion. Every Klow agent wallet has a configurable spending policy that defines what the agent can do autonomously and what requires your sign-off.

Three modes are available. Autopilot: the agent executes transactions within defined limits without asking. Approval-required: every transaction goes to your Telegram for explicit approve or reject. Hybrid: transactions under a threshold execute automatically, anything above requires approval.

• →Small swaps under $50 on Base? Let the agent handle them instantly.
• →A $2,000 rebalance across chains? Telegram notification with full details — you approve or reject.
• →Interaction with an unverified contract? Always flagged, always requires manual review.
• →Transaction proposals expire after 10 minutes. No stale approvals sitting in a queue.

When a transaction needs approval, the agent sends a Telegram message with the full breakdown: what it wants to do, the estimated gas cost, the destination address, and why it's proposing this action. You tap Approve or Reject. Approved transactions execute in seconds. Nothing moves without your explicit authorization.

Spending policies and per-chain guardrails

Beyond per-transaction approvals, each wallet has a spending policy: a maximum daily spend limit, a per-transaction cap, and chain-specific rules. The agent is physically unable to exceed these limits — the policy is enforced server-side in the API, not in the agent container. A compromised agent can propose a million-dollar swap, but the API will reject it before the key is ever decrypted.

Gas estimation includes per-chain sanity caps. If an RPC returns an absurdly high gas estimate (a known manipulation vector), the transaction is rejected. Slippage on swaps is clamped to a maximum of 5% — the agent can't set slippage to 100% and accept any output amount, which is how sandwich attacks drain wallets.

Swap routing uses hardcoded Uniswap V3 router addresses per chain. The router address is never user-supplied or agent-supplied. A compromised agent can't redirect swaps to a malicious contract.

Full audit trail

Every transaction proposal, approval decision, and execution is logged with timestamps, the tool that triggered it, and the user who approved or rejected it. This isn't just for compliance — it's for debugging. When your agent makes a trade you didn't expect, you can trace the exact chain of events: which tool fired, what data it saw, what it proposed, and what happened.

The wallet activity feed in the dashboard shows real-time transaction history with tool attribution. You can see that your DeFi Scout used price_get to check ETH price, then used swap_execute to propose a trade, and the trade was approved via Telegram at 3:47 PM. Full provenance, every time.

Multi-chain support without multi-chain risk

Klow agents operate on Ethereum, Base, Arbitrum, and Polygon with the same wallet abstraction and the same approval flow. One agent, multiple chains, one set of policies. Your spending limit applies across chains — an agent can't bypass your $500 daily cap by splitting transactions across four networks.

Chain IDs are validated against a strict allowlist. An agent can't request a transaction on an unsupported or unknown chain. If it tries, the request is rejected with a clear error listing the supported chains.

What's next: smart contract wallets

Today, Klow agent wallets are EOAs (externally owned accounts) with server-side policy enforcement. The roadmap includes integration with Safe (formerly Gnosis Safe) and account abstraction frameworks like ZeroDev. Smart contract wallets move policy enforcement on-chain — spending limits become immutable contract logic, not API-level checks.

This means session keys with time-bound, scope-limited permissions. An agent gets a key that can only swap on Uniswap, only up to $1,000 per day, only for the next 30 days. The constraints are cryptographically enforced. No server, no API, no trust assumptions.

Deploy an agent with a real wallet

The wallet security model isn't something you configure. It's built into every Klow agent by default. Deploy an agent, fund its wallet, set your spending policy, and it's ready to transact — with every guardrail in place.

Your agent goes from "I found a good swap opportunity" to "I executed the swap, here's the receipt, here's what I paid in gas, and here's the audit log." That's the difference between a demo and infrastructure you can trust with real money. See also: EOA to Safe: upgrade to a smart contract wallet and multi-agent treasury management.