Security & Custody

The short version: GoodAI is custody-free. We never hold your coins, and we are structurally incapable of withdrawing them. Your funds stay on your exchange the entire time. GoodAI only ever places trades.

GoodAI is operated by Good AI Tech Ltd (UK company number 17249425). This page explains, in plain terms, exactly how your funds and credentials are protected — and where the hard technical guarantees come from, not just our promises.

1. Custody-free by design

You never deposit funds with GoodAI. Your assets stay in your own exchange account (Binance, Kraken, Bybit — with more exchanges coming soon). Instead of moving money to us, you connect a read-and-trade API key.

That means:

• We can place and cancel orders on your behalf, so your bots can trade.
• We cannot move your money. No withdrawals, no transfers, no payouts — ever.

This isn't a policy we ask you to trust. It's enforced at connection time and reinforced by how your key is stored.

2. Withdraw-disabled keys (enforced, not requested)

When you connect an exchange, GoodAI inspects the API key's permissions before it is ever activated:

A withdraw-enabled key is refused, not stored. The rejection is recorded in the audit log and the encrypted material is removed.

Exchanges we can't auto-inspect (e.g. Kraken): A few exchanges don't expose a key's permission scopes through their API. For those, GoodAI fails closed — you must explicitly attest that the key has no withdrawal permission, and without that attestation the connection is rejected before anything is even stored.

Our standing recommendation: create API keys with trading enabled and withdrawals disabled, and where your exchange supports it, lock the key to trading only. GoodAI is built to function perfectly under those restrictions.

3. How your key is stored: KMS envelope encryption

Your API key is never stored in plaintext, never logged, and never placed in an audit record. It is protected with envelope encryption:

1. A fresh, single-use data key (AES-256) is generated for your connection only.
2. Your API key/secret is encrypted under that data key (AES-256-GCM).
3. The data key itself is then wrapped by a master key held in AWS Key Management Service (KMS) in production.

Two critical properties fall out of this design:

• Only the Execution Gateway can decrypt. The web app and the rest of the platform can seal (encrypt) keys, but they have no ability to open them. Decryption is the sole responsibility of the isolated gateway service that talks to exchanges.
• Each key is cryptographically bound to its own connection. The wrapped data key is tied to your specific connection via a KMS encryption context. A ciphertext sealed for one connection physically cannot be unwrapped for another.

In production, the encrypt and decrypt capabilities are split across separate, least-privilege identities: the part of the system that connects your key can seal it, and only the gateway can ever read it back.

What this means for you: even an attacker who somehow read our database would have only encrypted blobs that cannot be decrypted without KMS access that lives outside the database — and even then, only within the gateway, bound per-connection.

When the gateway does decrypt a key to place a trade, the plaintext is held only momentarily in memory and discarded immediately after use.

4. The tamper-evident audit log

Every security-relevant and money-relevant event is written to an append-only, hash-chained audit log:

• Every key decryption, every order, and every configuration change is recorded.
• The log is append-only — updates, deletes, and truncation are blocked at the database level by triggers. Even a misconfigured or over-privileged connection cannot rewrite history.
• Each entry is hash-chained to the one before it (a SHA-256 chain). Altering any past entry would break the chain.
• Entries are written by a database trigger, not by application code, so the application can never forge or skip a hash link.
• A daily verifier walks the entire chain and re-derives every hash; any break raises an alert.

Key material never appears in the audit log. The audit subsystem actively rejects secret-shaped data — it fails closed rather than risk recording a credential.

The result is a forensic record you can rely on: a tamper-evident history of everything that ever touched your account.

5. Account security: MFA, passkeys, and step-up

Your GoodAI account itself is protected by modern authentication:

• Email + password sign-in.
• TOTP multi-factor authentication (authenticator apps like Google Authenticator, Authy, 1Password).
• WebAuthn passkeys — hardware-backed, phishing-resistant login (Face ID, Touch ID, YubiKey, platform passkeys).
• Step-up confirmation before live orders. Placing a live order requires a fresh re-confirmation of your identity, even within an active session. (Cancelling an order reduces your exposure, so it does not require step-up.)

We strongly recommend enabling at least one second factor — a passkey is the most resistant to phishing.

6. What GoodAI can and cannot do

Custody-free isn't a feature we added. It's the foundation the whole platform is built on — and it's enforced in code, in cryptography, and in the database.

7. Questions or a security concern?

If you have a security question or want to report something, reach us through the contact form at good.ai/contact.