Architecture
Protection patterns for AI trading frameworks
Where to place pre-execution security around AgentKit, ElizaOS, x402, Safe, session keys, and other agent-wallet stacks.
Published by Kondux · Updated July 24, 2026
Direct answer
Frameworks give agents actions and wallets; a protection layer evaluates the resulting economic action. Place pre-execution policy after the framework has formed a concrete trade or payment payload and before the wallet, smart account, facilitator, router, or network executes it.
The framework-independent pattern
The same control pattern applies whether an agent uses a native wallet provider, an action plugin, a smart account, a session key, or an HTTP-native payment protocol. The agent proposes; the security layer evaluates; the execution system signs or settles only after an acceptable verdict.
- Agent runtime: strategy, reasoning, memory, and tool selection.
- Action layer: swap, transfer, approve, bridge, payment, or contract call.
- Protection boundary: intent comparison, authority, decoding, simulation, route and counterparty screening, policy verdict.
- Execution layer: wallet, signer, smart account, paymaster, facilitator, router, or settlement network.
- Evidence layer: decision receipt joined to the final transaction result.
How the pattern maps to common stacks
Coinbase AgentKit exposes wallet and onchain actions, including transfers and extensible action providers. Inspect the fully formed action immediately before the wallet provider signs or sends it.
ElizaOS plugins can give agents wallet awareness, transfers, and token swaps. Treat plugin output and aggregator routes as untrusted inputs until the final transaction passes policy.
x402 lets agents programmatically pay for HTTP resources. Evaluate the payment requirements, network, asset, recipient, amount, and signed payload before the client retries with payment authorization.
Safe and permissioned smart accounts provide approvals, spending limits, guards, and multi-signer patterns. These are strong authorization controls; pre-execution screening adds context about intent, route, token, and transaction risk.
ZeroDev-style permissions and session keys can constrain who acts, when, and what they may call. Screening the actual trade adds dynamic checks that static permissions may not express.
Integration-status clarity
These are architecture patterns, not claims of certified or production integrations between Seraph and the named projects. A production integration should document supported networks, payload formats, failure behavior, latency, policy ownership, and recovery before funds are exposed.