The policy layer for agent transactions
Free your agents. Keep your money safe.
Agents can pay. Your rules decide what goes through. No prompt can change that.
Caps, allowlists, rolling windows, a person above a threshold. Enforced at the key, receipted every time.
The separation
The one who acts can't be the one who approves.
Merkl puts a second signer you run between every agent and its treasury. The agent proposes a payment and signs its half; the signer checks it against rules the agent cannot see or change, and signs the other half only if it fits. Ask for more than the policy allows and the agent's signature is worth what it always was: half of two. A prompt injection can convince the agent; it cannot convince the signer.
Two signatures settle a payment. One does not.
01 · The rules
You write the rules. The signer enforces them.
A policy is a document you sign and the signer holds: where an agent may pay, what it may move, how much at once, how much in a rolling window, when a person has to say yes, and which invoice a payment must name. Nothing in a prompt can edit it, so how much autonomy an agent gets is a line in that document rather than a matter of trust.
At most 20 XRP per payment. At most 7.5 XRP every hour. Payments of 3 XRP or more need 1 of 2 approvers, who have 1 hour to answer.An example policy, in the same words the dashboard writes it in. The amounts are yours.
Built for treasuries, funds and payment operations that want agents on the money without a person approving every cent.
Guardrails in a prompt are advice. Guardrails in a signer are law.
02 · Attacks, stopped
The attack has to get past the rules, not the model.
An injected instruction tells the agent to drain the account: the destination is not on the allowlist, so the signer refuses. The same drain comes back as four small payments minutes apart: the rolling window trips on the fourth. A payment over the threshold does not move until a named person signs it with a passkey.
Every attempt, approved or refused, is a receipt.
03 · The enclave
The rules run on hardware you control.
The signer runs in an enclave inside your own account — AWS Nitro — and its policy key is generated in there, sealed to it, and never leaves in the clear. The enclave attests to the exact code it is running and the exact policy it loaded, and anyone can check that attestation offline. Merkl never holds a key that can move your money.
Attested code. Your account. Your key.
Open verification
Verify it yourself. Trust no one.
Every decision leaves a receipt: what the agent was told, what it asked for, which rule allowed or refused it, who approved, and what settled on the rail. A receipt is a standalone page that checks itself in your browser — offline, no account, nothing installed — and it says plainly which of those it could confirm instead of hiding them behind one green tick. If your audit trail needs you to trust the vendor, it hasn't solved the trust problem.
Read the codeTwo lines. Any agent. Any rail.
Wrap your agent and every action is recorded — the SDK fingerprints on your machine, and the notary only ever sees hashes and tool names, never your data. Point a treasury at the signer and no payment settles without its half. XRPL is the first rail; the receipt format does not change when the next one is.
Payments require a second signature today. Guardrails for every other action are next.
$ pip install merkl-sdk
$ merkl install --claude-code --global$ merkl signer serve --policy policy.jsonNot just payments.
The same SDK already secures agent sessions run through tools like Claude Code — every tool call, prompt, and approval recorded the moment it happens, independent of the agent it is watching. Payments are the first place a wrong action costs money. They are not the only place it costs something.