Syenite is built for production use. The MCP server never holds private keys, returns only unsigned transactions for execution tools, and is rate-limited and stateless. This page states the security model clearly so you can evaluate it for your agent or application.
Syenite never has access to user or agent wallets. Data tools (lending.rates.query, yield.opportunities, lending.position.monitor, and similar) return read-only data. Execution tools (swap.quote, swap.multi, lending.supply, lending.borrow, lending.withdraw, lending.repay) return unsigned transactionRequest objects. The agent or user signs and submits from their own wallet. No custody, no withdrawal permissions, no key storage.
Execution is intent-only. The server computes optimal routes (swaps) or encodes protocol calldata (lending) and returns unsigned transactions; the client holds the key and signs. For cross-chain bridges, swap.status tracks progress but does not move funds. This keeps Syenite in the role of a router and data provider, not a custodian or executor.
Before signing, you can run tx.verify, tx.simulate, and tx.guard on any unsigned transaction (including quotes from Syenite or elsewhere). After signing, confirm with tx.receipt. See Transaction trust layer.
Open access (no API key) is rate-limited to 30 requests per minute per IP. Limits reduce abuse and keep the service stable for everyone. For higher throughput, use an API key (see the MCP README or dashboard). Health is exposed at /health for monitoring.
Each request is stateless. The server does not store session data or user identity between calls. That simplifies deployment and reduces the attack surface: there is no session to hijack and no long-lived credentials on the server.
For vault-based products (LISA, MLISA), Syenite uses isolated vault contracts with clear custody and parameter bounds. Vault design includes withdrawal guards, protocol allowlists, and risk parameter registries. Audit path exists for vault contracts; see product documentation for details.