Credentials

For GTM Goat to work for you, you store access to your own systems — CRM, email sending, calendar, enrichment services. Those keys are yours, and how they are handled is a promise, not an afterthought.

Stored encrypted

Provider credentials are stored encrypted in the database (AES-256-GCM). The key for it does not live in the database but in the application’s runtime environment — whoever reads the database does not read your credentials with it.

That is the whole point: encryption whose key sits right next to the data does not protect against the very risk it is meant to address.

What gets encrypted are the secrets, not their context. Addresses, account identifiers and validity dates stay readable — otherwise nobody could see where a connection points, and a connection you cannot inspect becomes a black box.

What you see of it

• On connecting, the credential is verified against the provider. The outcome is threefold: confirmed · rejected (nothing is stored) · unverifiable (with a reason). “Not provable” is explicitly not the same as “broken”.
• In the interface you see whether a credential is stored — never its value.
• When a credential fails in operation, the workspace reports it with the provider and the failure class, instead of quietly doing nothing.

Your keys, your choice

For categories such as research or enrichment you can store your own keys (BYOK). Usage then bypasses your credit balance and runs directly with your provider — see Costs.

You can disconnect a credential at any time. It is then removed from the workspace; what happens to the data in your own system stays your decision.

See also: Approvals — credentials say what may be acted with; approvals say what may happen without asking.