Wallet With Guardrails: Policy Checks Before Your Agent Signs

#agents #security #api #webdev

Handing an agent a wallet is the easy part. Key generation is a commodity, and half a dozen providers will give you an address and a signing endpoint in an afternoon. The question that actually matters is what happens in the moment between your agent deciding to send funds and those funds leaving the wallet. Is anything checking that decision, or is the wallet just doing what it is told?

A wallet answers one question: can this key sign a transaction? It has no opinion on whether the destination is one you recognize, or whether this is the fortieth transfer in ten minutes when it should have been the fifth. A wallet executes what it is asked. Infrastructure decides what is allowed to be asked in the first place. That is the gap worth closing before your agent touches real funds.

Policy-first: the check runs before anything is signed

Most "safety" in agent wallet products lives in the prompt: a system message that says never send more than a set amount, or only use approved addresses. That is guidance, not enforcement. A long context window, a clever injection, or a model that reasons its way past the instruction all beat a prompt.

OpenClawCash puts the policy in the execution path instead. The check runs on the API, before a transaction is built, so a jailbroken model, a compromised prompt or a buggy retry loop all hit the same wall:

agent requests: transfer 5.0 ETH to 0xUnknown...
  -> policy engine checks: per-transaction cap, destination allowlist, daily limit
  -> cap exceeded or address not allowlisted -> rejected
  -> the transaction never reaches the chain

Nothing here depends on the agent choosing to behave. The request either matches policy or it does not leave the building, and the agent was never the one holding the rule.

Read the policy that is actually enforced

Policies come back hydrated with current usage, so you can see a limit and how much of it is already spent in one call:

curl https://openclawcash.com/api/agent/policies \
  -H "X-Agent-Key: occ_your_api_key"

[
  {
    "wallet": { "id": "Q7X2K9P", "label": "Trading Bot", "chain": "evm" },
    "policies": [
      {
        "id": 31,
        "type": "daily_spending_limit",
        "config": { "amount": "100" },
        "usage": { "spent": "45.00", "limit": "100.00", "symbol": "USD", "window": "24h" }
      }
    ]
  }
]

A send is one call in the same shape, and it goes through that policy before it is signed:

curl -X POST https://openclawcash.com/api/agent/transfer \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "walletId": "Q7X2K9P",
    "to": "0xRecipientWalletAddress...",
    "token": "USDC",
    "amountDisplay": "100"
  }'

Every wallet id, address and key above is a placeholder, so copy the shape, not the values.

One policy layer across chains

Agents do not stay on one chain. A trading agent settling an escrow on Ethereum and paying out in USDC on Solana is a normal week, not an edge case. The usual fix is a different wallet SDK per chain, each with its own key model and its own security posture, so the spending limit you set on one chain means nothing to the integration sitting next to it.

OpenClawCash treats multi-chain as the starting assumption. One API and one policy layer span Ethereum, Polygon, Base and Solana mainnets. The allowlist, the per-transaction cap and the daily ceiling apply the same way regardless of which chain the agent is transacting on. You define the policy once instead of re-deriving your security model for every new chain.

Auditable: the rejected attempts, not just the confirmed ones

A log that only shows what succeeded is half a record. The other half is what your agent tried to do and got stopped from doing: the transfer to an off-list address, the request that hit the daily cap.

Event	What is recorded
Approved transfer	timestamp, agent key, source and destination, amount, transaction hash
Rejected transfer	timestamp, agent key, attempted destination and amount, rejection reason
Policy change	who changed it, what changed, when

That is the difference between a bank statement and an incident report. The statement tells you where the money went. The incident report tells you what almost happened, which is usually the thing you need when a security review asks how the system behaved.

Getting started

Create a wallet and set a policy: per-transaction cap, daily limit, address allowlist.
Generate a scoped agent API key for that wallet.
Read the policy back with GET /api/agent/policies and confirm the usage numbers.
Point the first transfer at a supported testnet and watch the activity log do its job before you trust it with anything real.

The full version of this argument is on the site: Every Competitor Gives Your Agent a Wallet. OpenClawCash Gives It Guardrails.

Docs: openclawcash.com/docs | Agent wallet surface: openclawcash.com/agents

DEV Community