How we let an AI agent borrow on-chain without letting it drain the wallet

A co-authored technical write-up from Compass Labs and Sly.

Giving an AI agent access to money is the easy part. Making sure it can only do the thing you actually authorised is the hard part. An agent that can take out an on-chain loan can, with the same key, take out the maximum loan, send the proceeds anywhere, and do it again in a loop while you sleep.

So we built the boring, safe version on purpose. Sly wrapped the Compass CLI inside its agent stack, put a governance layer in front of it, and ran a full borrow end to end: the agent asks to borrow, the request is checked against what the agent is allowed to do, a human approves the part that needs approving, and the loan settles on-chain. The agent could borrow a little. It could not drain the safe. Here is how the pieces fit together.

The Sly × Compass governance demo. Every state-changing Compass call is evaluated by Sly first — KYA tier, scope step-up, venue allowlist, spending caps, operator kill-switch. Approved surfaces dispatch to the Compass CLI; denied ones never reach it.

The setup

The demo is an agent that needs liquidity. It holds crypto collateral and wants to borrow against it — in our case against collateral on Morpho — then optionally use the borrowed stablecoins to pay for something over x402. Two systems do the work:

• Sly owns identity, permissions, and approval. It decides whether the agent is allowed to do what it is asking to do, and routes anything sensitive to a human.
• Compass owns the on-chain action. It turns "borrow against this collateral" into a ready-to-sign transaction and returns positions, balances, and risk through one API.

Nothing custodial sits in the middle of the borrow: Compass never touches the funds, and the collateral and borrowed funds only ever move under the user's own signer. That property is what makes the whole thing safe to automate.

1. The agent is not the wallet

The first mistake most agent designs make is binding the agent's identity to a wallet. Once you do that, "what is this agent allowed to do" collapses into "what can this private key sign," and the answer is always "everything."

Sly separates the two. The agent gets its own on-chain identity — what Sly calls a portable Agent Card — backed by on-chain KYA (know-your-agent) verification and tied to a verified parent. That identity has a relationship to one or more wallets, and the relationship is scoped. One agent might have read-only visibility into a treasury. Another might be allowed to request small borrows. The identity is the thing you grant permissions to, not the key.

2. Permission is scoped, and a human sets the scope

Sly governs what an agent can do through spending policies and approval rules: what the agent may do, against which counterparties, up to what amount, with kill switches and cross-org governance on top. The scope is set by the human, not minted by the agent for itself.

In practice each action falls into one of three buckets:

• Allowed outright — read positions, check rates, simulate a borrow. No human in the loop.
• Needs approval — borrow above a threshold, move funds to a new destination. Routed to a human for a custom approval the platform configures.
• Never — anything outside policy. The agent cannot escalate its own scope.

This is the line that matters: the agent can borrow a little for a specific purpose, it cannot empty the position. That is not enforced by hoping the model behaves. It is enforced before any transaction reaches a signer.

3. Compass prepares, the signer signs

Here is the part people assume must be custodial and isn't.

Compass is non-custodial. When the agent asks to borrow, Compass prepares the on-chain transaction and hands it back unsigned. Compass never holds the collateral, never holds the borrowed funds, and never executes anything. The wallet that owns the position — the one the agent's identity is scoped to — signs the transaction Compass prepared. Same model across every Compass product: we build the transaction, your signer authorises it.

That maps onto Sly's policy model one to one. A spending policy already describes who may sign, for what, up to how much. A Compass-prepared transaction is exactly the object that policy is meant to gate. There is no custodial middle step to trust, because there is no custodial middle step.

agent: "borrow 200 USDC against my ETH"
  -> Sly: evaluate against spending policy
       within scope?      -> continue
       over threshold?    -> request human approval (step-up)
       outside policy?    -> reject, no signer is ever called
  -> Compass: prepare borrow transaction (unsigned)
  -> signer (scoped wallet): sign
  -> settles on-chain (Morpho), position + PnL returned via Compass
  -> Sly: log the action against the agent's identity

4. The approval loop is where policy meets the transaction

Putting it together, a single borrow runs like this:

• The agent decides it needs to borrow and calls the tool. Under the hood that tool is the Compass CLI, wrapped by Sly's MCP, so from the model's side it is just one capability among several.
• Sly evaluates the request against the agent's spending policy before anything is prepared. If the amount is over the configured threshold, Sly pauses and asks the human. The human sees a clear, specific request (borrow this much, against this collateral, for this reason) and approves or declines.
• On approval, Compass prepares the borrow transaction and returns it unsigned.
• The scoped wallet signs. The loan settles on-chain. Compass returns the updated position and risk.
• Sly writes the whole thing to the agent's verifiable transaction history — an auditable record tied to the agent's identity that feeds its on-chain trust score — so the platform exposing the agent can show exactly what happened and why it was allowed.

If the agent had asked to borrow the maximum, or to send the proceeds somewhere policy didn't cover, step 2 stops it and no signer is ever called. The guardrail is structural, not a prompt.

Why this is the interesting demo

Most "agentic finance" demos cheat in one of two ways. Either they skip the guardrails (an agent with a hot key and full access, which no real platform will ship), or they skip the real markets (a toy that can't actually borrow, swap, or earn anything on-chain). This one has both: real on-chain markets through Compass, real permissioning and approval through Sly, and nothing custodial in the middle.

That is what makes it safe to put in front of users. A wallet, neobank, or fintech can let an agent act on a user's position, with the user's own mandate setting the limits and the user's own signer authorising the transaction. The agent gets to be useful. The user keeps control.

Try it

• Compass API docs: docs.compasslabs.ai
• Compass CLI: docs.compasslabs.ai/v2/Agents/CLI
• Sly: getsly.ai
• Sly Docs: docs.getsly.ai
• Examples: github.com/Sly-devs/sly-demos

If you're building agents that need to do real things with on-chain capital, this is the pattern: scoped identity, human-signed mandates, non-custodial transaction prep, and an approval loop that runs before anything gets signed.

Compass does not control DeFi protocols or smart contracts. Using DeFi protocols involves risk, including potential loss of funds. This is not investment advice.