Security model

Trust boundaries

Component	Holds	Can do
Agent	An agent bearer token or OAuth access token	Ask for decisions; submit signed decisions; read its own orders
Authorizer	The decision signing key; mandates; buying power	Sign decisions. Cannot send orders
Executor	Venue credentials, through the adapter	Send orders, but only for a valid, unexpired, unused, signed decision
Venue adapter	The venue credential, in its own environment	Map orders to the venue. Decides nothing

The agent has no path to the venue except through the executor, and the executor has no way to create a decision.

What the design prevents

• An agent trading outside its mandate. Every order is judged by the authorizer, not by the agent.
• Tampering in transit. Any change to a signed field fails Ed25519 verification (A2M_BAD_SIGNATURE).
• Replays and double sends. Decisions are single use and short-lived; intent_id and client_order_id are idempotency keys; the executor never resends an order whose fate is unknown.
• Downgrades. No component may round a signed price or quantity, or replace a time in force the venue does not support. It refuses instead.
• Silent defaults. Missing prices, unknown products and unreadable venue capabilities fail closed.
• Credential leakage into models. Tokens travel in HTTP headers; tools never accept them as arguments.
• Unattributed actions. Rejections are signed too, and every step is in the hash-chained evidence log.
• Withdrawal. On venues that support it, the executor uses a credential scoped to trading only. On Hyperliquid this is an API wallet, which cannot withdraw.

Enforcement strength

Only custodial_fairx enforcement is implemented: the executor is the only path to the venue. Other modes, where the agent keeps its own venue access and A2M only hooks or watches, are weaker by design and are planned, not available. Each decision states its enforcement mode in the signed payload so the evidence shows how strongly an order was controlled.

Kill switch

An operator can set a kill switch to halt (no new risk-taking orders) or reduce_only per scope. It is evaluated in the rule pipeline (kill.halt, direction).

Out of scope for v0.1

• Compromise of the authorizer’s signing key or of the executor host. Key rotation is supported through key_id, but key custody is a deployment concern.
• Market risk inside a mandate. A2M enforces the limits it is given; it does not judge whether a strategy is sound.
• Leverage, funding and liquidation risk on perpetuals. v0.1 treats supported perpetuals as long-only, fully reserved, at 1x.
• Venue-side enforcement (venue-verified decisions) and compiling mandates into venue-native limits are planned.