API Key Encryption

Envelope encryption with AWS KMS

When you connect a centralized exchange, Aegis stores your API credentials using envelope encryption backed by a KMS (AWS KMS). A data key encrypts the secret, and the data key itself is protected by a KMS master key that never leaves the KMS boundary. The domain layer works with ciphertext; it never stores the raw key bytes.

Because decryption requires KMS, a database dump alone is not enough to read your keys.

The secret is never returned

Aegis is designed so the API never returns your secret. Once a key is stored, there is no endpoint that hands it back — not to the dashboard, not to you, not to support. You can revoke and replace a connection, but you cannot read the secret out again.

Trade-only, non-custodial by policy

Aegis never holds your funds. A CEX API key is rejected unless withdrawals are disabled — it must be trade-only. If a key carries withdrawal permission, the connection is refused. On DEXs there are no stored keys at all: you sign every transaction yourself, and Aegis never signs or holds funds.

Multi-tenant isolation with PostgreSQL RLS

Encryption protects the secret at rest; tenant isolation ensures one account can never reach another's data. Aegis enforces PostgreSQL Row-Level Security (RLS) so every query is constrained to the calling tenant's rows at the database level. This is defense in depth — even if application code had a bug, RLS still blocks cross-tenant reads.

What is protected

For how you prove control before adding or revoking a connection, see Step-up signatures.