Skip to content

Security model

The core question with agentic trading is: if the assistant is wrong — or compromised — how much damage can it do? PrimeDelta is built so the answer is bounded, and the bounds are things you control.

Non-custodial by construction

PrimeDelta never holds your key. Every write is signed by your signer, and the signer is the outer boundary of what's possible:

  • Browser / remote-browser — a human approves every action in a wallet. The assistant can't move anything you don't sign.
  • KMS / raw key — the server signs without prompting. Now the boundary is the caps and gates, not a human.

Choose the weakest signer that does the job; see the signing-modes matrix.

Layers between "the assistant asked" and "funds moved"

  1. Identity gate. Trading requires a KYC-verified, minted DID. An unverified wallet can read but not trade.
  2. Spend caps, enforced off the model. Per-trade and daily dUSD caps are checked before a trade is quoted, so an over-cap request is rejected up front. The model can't reword its way past them.
  3. Opt-in gates. Deposits, withdrawals, brokerage orders, and subaccount actions are off by default. A disabled capability isn't merely discouraged — the tool isn't exposed.
  4. Allowlists. Optionally restrict tradable symbols, native-send recipients, and approval spenders.
  5. Chain-id guard. The RPC's real chain id is checked against the selected network on startup, so a misconfiguration fails fast instead of trading on the wrong chain.
  6. Kill switch. halt() stops all trading immediately (only order cancellation remains).

What a compromised assistant still can't do

  • Sign anything in a browser mode without your wallet approval.
  • Exceed your spend caps.
  • Use a gated capability you didn't enable.
  • Trade a symbol outside your allowlist, if you set one.
  • Move funds on a chain other than the one you configured.

What it can do, within those bounds, is real — so set the bounds deliberately and keep them tight. See Operator hardening.

Remote deployments authenticate callers

A hosted HTTP server authenticates its callers (OAuth or a bearer token) and refuses to start otherwise, and it should sit behind TLS. That's separate from transaction signing — it controls who can reach the tools at all. See Connect Claude web.

Secrets

  • A raw private key and the HTTP auth secret are the sensitive values — keep them out of logs, shell history, and plaintext config. In the plugin, sensitive fields live in the OS keychain.
  • A KMS key id/ARN is an identifier, not a secret; the IAM credentials that can use it are what you guard.

Know the edges → Known limitations · Risk & responsible use