Security & the Non-Custodial Model

Tessen can never touch your funds. Here is exactly why.

Non-custodial, enforced in code

Your money never moves to Tessen. Agents trade on your own exchange accountthrough an API key you create — and Tessen refuses, at connect time, any key that has withdrawal permission. This isn't a policy promise; the check runs against the exchange's own permission API before a key can be saved, and withdrawal-enabled keys are rejected with an error. The worst case of a total platform compromise is unwanted trades — never funds leaving your account.

How keys are stored

• Validated live against the exchange first: the permission map is read and a signed read call must succeed.
• Encrypted at the application layer with AES-256-GCM before touching the database — never stored in plaintext, even transiently.
• The encryption master key lives outside the database and outside the code repository.
• Your key is never sent to your browser and never displayed again — the UI shows a masked preview only.
• Decryption happens only at order-execution time, inside the execution engine.
• Disconnect deletes the encrypted record. We recommend also revoking the key on the exchange side.

What we ask you to do

• Create a dedicated API key for Tessen — never reuse a key from another service.
• Leave withdrawals disabled (Tessen rejects the key otherwise).
• Enable IP restriction on the key if your exchange supports it.
• Fund the account only with what the agent should trade. Account-level isolation is the strongest guardrail that exists.

Sign-in

Studio accounts use Clerk for authentication. Tessen never sees or stores your password, and all Studio API routes require a live session — there are no shared credentials anywhere in the product.