MCP security model

Trading tools have real-money consequences. The server is built so the LLM can trade within the venue's limits but can never touch the credentials or withdraw funds.

What the LLM can and can't do

Can: place orders against the account (any market, any size, within venue limits), cancel orders, close positions, and read all account state.

Cannot:

  • See the agent private key, delegate key, or Geomi keys.
  • Withdraw funds — HL agents and Decibel delegates lack withdraw authority on-chain.
  • Change the account's main authentication.
  • Approve new builders or extra agents.
  • Configure or override the builder fee (baked into the package).

The HL agent + Decibel delegate are scoped, trade-only credentials minted by the Tria app — even if compromised they can't drain funds. Still, practice defense in depth:

  • Treat the env file like any other secret: chmod 600 ~/.config/tria/sdk.env.
  • Don't put credentials in shared shell config or commit them to source control.
  • The server never exposes env vars on any tool or resource.

Dangerous-tool approval

Most MCP clients (Claude Desktop) ask permission before each tool call by default. Configure auto-approve for read-only tools (ticker, markets, positions, balances, …) and keep write tools on manual approval (place_order, close_position, cancel_all_orders, scheduled_cancel). The server tags each tool with readOnlyHint / destructiveHint annotations so clients can gate appropriately.

Auditability

Every action goes through the SDK's normal path — HL signed by your agent key, Decibel by your delegate key, both attributed to Tria's builder. So every fill is auditable in the venue UI, the Tria app, and the backend's trade-event tables, all tagged with the same builder code. There are no "ghost" trades that bypass attribution.

Was this page helpful?