Custom financial harnesses for agents

Builders often ask us how to best limit their agent’s execution privileges onchain. Historically we’ve guided them to use a 2-account structure: a main account requiring a human signer and a subaccount from which the agent can operate freely. While this setup effectively limits the agent’s blast radius, it does so by bluntly limiting the assets the agent can access. More recently, we realized our API can be repurposed to allow every developer to bring-their-own financial harness.

The two-key split#

A Splits API key doesn’t grant signing authority on its own. Signing needs a registered EOA, and that private key lives wherever you put it. You can probably guess what comes next:

Give the agent a write-scoped API key. It can read balances and propose transactions tagged with memos and custom JSON metadata. Since it holds no signing key, it can’t move any money on its own.

Give your server a write-scoped key plus the registered EOA. Your server polls for pending proposals, runs them through your bespoke policy engine—velocity limits, target allowlists, calldata restrictions, invoice lookups, Slack approvals, etc—and only signs the ones that pass. The proposal carries the agent's memo and properties, so your policy code has the agent's stated intent to check against the actual calldata.

Human fallback#

To further increase flexibility, make the agent a 1-of-2 subaccount, where the signers are your server’s EOA and a human passkey.

Now the flow has three outcomes. Policy passes, your server signs, it executes. Policy fails, your server declines (and pings Slack), and the proposal sits pending until a human approves or rejects it in the app. If something goes wrong, the parent account can rotate the subaccount's signers, preserving the agent’s address.

Great security comes in layers. The blast radius is still the subaccount's balance, but now your policy engine provides an extra layer you can change on demand. Each key leaves its own audit trail, so you can see exactly which proposals came from the agent and which your server let through.

Exploring further#

The example above is about as simple as it gets, but by using more subaccounts, higher thresholds, and more server keys, you can ship increasingly complicated policy rules to fit your business needs. For example, if the subaccount is a 2-of-2 with a server key and a human passkey, the human can only take actions adhering to your policy engine. If the subaccount is a 2-of-3 with one server key and two human passkeys, you can now differentiate the conditions under which one human may access funds relative to the other. The possibilities are, quite literally, endless.

Now that agents make shipping code easy, you don’t need to be constrained by someone else’s policy engine. If you’re building on the frontier with agents and policies, reach out. We’d love to help.