In July, Zscaler documented attackers hiding instructions inside websites and poisoned search results to push AI agents into sending crypto payments to wallets the agents were never told about. Palo Alto’s Unit 42 had already written up the retail version: a shopping agent scanning for discounts reads a hidden line on a deals page, and quietly appends a gift card to the cart before checkout. No stolen password. No exploited bug. Just a sentence in the right place, and an agent that does what the sentence says.
Meanwhile Coinbase pushed over $100 million through x402, its machine-to-machine payment standard, and agents now settle in USDC on AWS without a human approving each transaction. So the money is real, the payment rails are real, and the way you break an agent is to write it a convincing sentence. Those three facts arrived in the same summer.
Here is the number that ties them together. Surveys this year point at the same gap from both sides: most organizations report they’ve already had a confirmed or suspected agent security incident, while most executives still believe their existing policies cover them. The same companies, holding both positions at once.
Those policies fail at the design level. Agentic payment rails shipped without a cryptographic answer to the most basic question a bank or a merchant should be able to ask: did anyone actually authorize this? The industry filled the gap with trust layers, identity platforms, certificates, some of them free. Strip the branding and they ask for the same thing — believe the provider checked. The check happens where you can’t see it, and you take their word.
What we’ve built doesn’t ask for the word.
moltrust-enforce takes one transaction and the mandate its principal signed, and answers whether the transaction stays inside the mandate — before the agent acts. PERMIT, DENY, or PENDING. It runs on the operator’s side, in their own runtime. There’s no proxy sitting in the path and no instance you have to trust, because the operator is enforcing on their own agent for their own reasons.
Then there’s a second call, and it’s the one worth having. check() asks our server. verify() recomputes the verdict on your machine, from the mandate and the transaction, and holds the two answers up against each other. The verdict is a function of those two inputs and nothing else — no server state, no clock, no database — so anyone with the mandate and the transaction lands on the answer we did. Hand verify() a server response that’s internally tidy but doesn’t follow from the inputs, and it says so. That is the difference between auditing a verdict and accepting one.
Everything fails closed. Unreachable server, error status, unreadable response — all DENY. Nothing here turns a failed check into a yes.
pip install moltrust-enforceSame auth as the rest of the API, and a free key is one signup away. The quickstart with both calls is on the developers page.
Plenty of teams now build a mandate an agent can’t step outside of. Good — the field needs it. What a provider can’t build, as long as it’s the provider, is a verdict you don’t have to believe. That’s the one we went after.