Before payment
Guard
An agent or a service asking to pay is not the same as being allowed to. Guard is the deterministic authorization layer that sits in front of every machine and agent payment request — it decides what may be paid, under a policy you set, and prepares the authorization. It never signs and never moves value.
The problem
When software initiates payments, the dangerous gap is between “the agent asked” and “the value moved.” A prompt, a bug or a compromised model can request anything. If the request is the authority, there is nothing between a mistake and a loss.
AGENT_CAN_REQUEST != AGENT_CAN_SPEND
What Guard does
Decides deterministically
Every request is evaluated
against your policy — per-asset and per-recipient budgets, velocity limits,
allowlists — and returns ALLOW,
REQUIRE_APPROVAL or DENY. Same
inputs, same verdict.
Holds for human approval
Requests over a threshold wait in an approval queue. A person approves, denies or lets it expire; the decision and who made it are recorded.
Prepares, never signs
On allow, Guard produces an authorized intent your signer can act on, bound to a hash. Your key still signs the value — Guard is the gate, not the wallet.
What StoneReason does not do
No signing, no keys. Guard never signs a transaction and never holds a key. Your signer signs the value it authorizes.
No custody. It does not move, hold or touch funds.
No replacement of your stack. It authorizes before your wallet and provider — it does not replace them.
No guessing. A request outside policy is denied with the reason, not approximated.
Live on this deployment
Guard is live. The policy engine and the approval workflow run today — the authorization decision is deterministic and needs no chain, so it does not depend on any network being observed. Execution of the authorized payment then happens through your own signer and provider.
A request, and its verdict
Who this is for: teams giving autonomous systems, agents or internal services the ability to initiate payments — who need budgets, approvals and an audit chain, not unrestricted spend.
Input: a proposed payment (agent, network, asset, amount,
recipient).
Output: a deterministic verdict and, on allow, an authorized
intent bound to a hash.