Pre-Execution Guardrails for Autonomous Agents: How to Stop Bad Trades and Payments Before They Happen

A pre-execution guardrail is a check that runs after an autonomous agent decides to take an action and before the action executes. It can allow the action, change it (for example, reduce its size) or block it.

It is different from the two controls people usually reach for. Prompt instructions ('never spend more than $100') live inside the model and can be ignored, forgotten or overridden by injected text. Post-execution monitoring tells you what went wrong after the money has moved. A pre-execution guardrail is the only one of the three that can prevent the loss.

This applies to any agent that moves value: trading agents, payment agents, treasury agents, agents that pay for APIs with stablecoins.

Outside the model. The guardrail is code, not a prompt. The model produces a proposed action as structured data; the guardrail evaluates that data deterministically. The model never gets to decide whether the guardrail applies.

On the execution path. Every action must pass through it. If the agent has a second route to the wallet, such as a raw signing tool, the guardrail is decorative.

Read-only to the agent. The agent can query its limits but cannot change them. Changing limits is a human action, on a different channel, ideally with its own audit log.

Fail closed. If the guardrail cannot evaluate, because a data source is down or the input is malformed, the action does not execute. An agent that trades blind when its risk check times out has no risk check.

Size against a cap. Is the order larger than the maximum position size allowed right now, as a fraction of capital?

Exposure across positions. Does this order push total exposure in one direction past its limit, or is it a hedge that reduces exposure?

Leverage. Is leverage allowed in current conditions, and below the human-set maximum?

Market state. Is the market in a condition where new entries should be blocked: a liquidation cascade, extreme volatility, crowded positioning about to unwind?

Data quality. Are the inputs behind the decision fresh? A decision built on a stale price or a missing funding rate should not execute.

Loss limits. Has the agent already hit its daily or weekly loss limit?

Payment agents need the same pattern with different checks.

Amount limits per transaction, per counterparty and per period.

Allowlists of payees, contracts or domains. An agent paying a new address should need more than its own judgement.

Purpose binding. Does the payment match the task the agent was given? An agent sent to buy API credits should not be able to pay an arbitrary invoice it found in an email.

Rate and velocity. Ten payments in a minute is a pattern worth blocking, even if each one is small.

Asset risk. If the agent pays or holds stablecoins, is the stablecoin trading at its peg? Paying out of a depegging asset or accepting payment in one is a risk decision.

1. The agent produces a structured intent: action, asset, size, counterparty, reason.

2. The guardrail service receives the intent and gathers context: current holdings, limits set by a human, and current market or counterparty state.

3. It returns a decision: allow, resize (with the new size) or block (with reason codes).

4. Only an allowed or resized intent reaches the signer. The signer refuses anything that does not carry a valid decision.

5. Every decision is logged with its inputs and a hash, so the same inputs reproduce the same decision.

The key property is determinism. The same intent and the same state always produce the same decision, which makes the guardrail testable before deployment and auditable after.

Guardrails in the prompt only. Useful as guidance, useless as control.

Static limits in a dynamic market. A fixed cap that is sensible in calm conditions is too loose in a crash. The effective limit should tighten when conditions deteriorate.

Checking the order, not the portfolio. A small order can still be the one that makes the book dangerously concentrated.

Failing open. Timeouts and errors must block, not allow.

No reason codes. If the guardrail just says 'no', the agent retries the same thing. Reason codes let the agent adjust (smaller size, different asset, wait) and let humans audit.

RiskState is a pre-execution guardrail for the market-risk side of crypto agents. For BTC and ETH it returns, on every call, the maximum position size, whether leverage is allowed, which actions are blocked and why, and a policy_hash for audit. The portfolio endpoint evaluates a proposed position together with what the agent already holds, including stablecoin and concentration checks, and answers 'allowed, at what size cap'.

It is read-only by design: agents can ask for limits, never change them. Payment-specific checks such as allowlists and purpose binding belong in your own guardrail service, with RiskState as the market-state input.