How agent permissions work
A BVCC Agent Wallet gives an AI agent a narrow, on-chain-enforced set of powers. You do not hand it your keys — you authorize an agent address to do specific things, within limits the contract itself checks on every transaction. This page explains what those settings mean, so you can configure an agent understanding exactly what you grant.
Capabilities instead of addresses
The authorize form leads with a simple question: what should this agent be able to do? Pick capabilities — swap on Uniswap, lend on Aave, unwind a position — and the form fills in the exact contracts, tokens and destinations each one needs. You never have to know that the Universal Router needs Permit2, or that Aave needs its Pool as a destination; the picker composes it for you.
Everything the picker adds is shown, and every address links to the explorer’s Contract tab so you can verify it is the real Uniswap, Aave or Permit2 contract. You can also add any address by hand in the "Addresses (manual / advanced)" section — for a protocol not yet in the list, for example.
The four permission layers
Every action an agent attempts falls into one of four cases, each governed by a different setting:
| Case | What it is | What governs it |
|---|---|---|
| 1 | Sending native ETH | Allowed destinations + ETH limits |
| 2 | transfer(token) | Allowed destinations + token limits |
| 2b | approve(spender) | Allowed destinations + token limits |
| 3 | DeFi calls (swaps, Aave…) | Allowed protocols + call policies |
Sending (cases 1 and 2) is always available; you shape it with destinations and limits. DeFi (case 3) is default-deny: whitelisting a protocol is not enough — a call policy per function must also be registered. The capability picker registers those policies for you.
Call policies — why a stolen agent key cannot redirect funds
A call policy pins the destination argument of a DeFi call to your own wallet. So even if an agent’s key were stolen, a swap or an Aave withdrawal can only send the output back to your wallet — never to an attacker. For calls where the destination is buried in complex data (the Universal Router), a fixed on-chain validator decodes it and enforces the same rule.
Limits and destinations: what 0 and empty mean
- ●A limit of 0 means unlimited — not zero. Leave it 0 to impose no cap; set a number to cap it.
- ●An empty destinations list means any destination is allowed. Add addresses only to restrict where the agent may send, transfer or approve.
- ●If you do restrict destinations, the contracts a capability needs (Aave Pool, Permit2, the swap routers) are added to that list automatically — their approve is a case-2b call.
Verifying a contract
Click any address in the form or on an agent’s card. It opens the block explorer on the Contract tab, where you can confirm the address is the canonical, verified contract for that protocol before you authorize anything.