Credential storage
Broker credentials are encrypted before they are stored, and the key that encrypts them is itself encrypted under a master key held outside the database. The practical consequence is that a stored credential record contains no usable key material. Reading the database, in full, does not yield a broker credential. The unencrypted key exists only for the instant it is being used. The encrypted credentials are held in WorkOS Vault. Anthid’s own database stores only a pointer to the vault entry, never the secret itself.An encrypted credential is bound to the client it belongs to
The organization, broker, and environment a credential was created for are cryptographically bound into the encrypted value. If any of the three differ when it is decrypted, decryption fails outright. A credential record copied into another client’s context does not decrypt into the wrong client. It does not decrypt at all.
Credential deletion
Deleting a credential means two things must happen: the credential must stop being usable, and the secret must be destroyed in the vault. The two can fail independently, so Anthid does them in a defined order. The credential is marked deleted, and the instruction to destroy the secret is committed, in a single durable step. The destruction itself happens immediately afterwards. Committing the instruction rather than simply firing it off is what makes a deletion survive a failure between the two: if anything interrupts the process, the outstanding destruction is picked up and completed rather than silently abandoned. A repeated or retried delete does not queue a second destruction. The record of the deletion outlives the secret. Who deleted the credential, when, and under which of your credentials remains on the account’s history after the secret it pointed at is gone.Keeping clients separate
Every record that belongs to a client is tagged with that client’s organization, and the separation is enforced by the database itself rather than by the application asking nicely. Every read declares which client it is acting for, and the database refuses to return rows belonging to anyone else. A read that fails to declare a client returns nothing rather than everything. That default is the important half: the failure mode of a bug in this area is an empty result, not another client’s data. The same rule applies to Anthid’s own administrative access. There is no privileged path that quietly bypasses it.Records that cannot be rewritten
The history of trading accounts and broker credentials is append-only. Correcting something means adding a new entry, not editing an old one, and the database rejects any attempt to modify or remove an existing record. That restriction is enforced in three independent ways at the database level, so defeating it means defeating all three rather than finding one gap. Anthid’s own application has no ability to alter a recorded entry, and neither does an ordinary database session. Internal read access for support and operations runs through a separate, read-only identity that cannot make changes and cannot be used to log in interactively.What is recorded when something changes
Connecting a broker account, disabling one, rotating a key, and deleting a connection are all acts somebody performed. Each is recorded, and each carries the caller behind it.
These values are captured before any processing begins. They are therefore identical across every record a single request produces, and they exist even for requests that fail before they get anywhere.
Attribution is taken from the request every time, never inherited from the thing being changed. One credential disabling what a different credential created is visible rather than hidden.
A new kind of caller cannot be silently mis-recorded
Anthid cannot add a new class of caller without deciding, explicitly, how it is recorded. The system refuses to build otherwise. The alternative, a plausible-looking default written into a record whose entire value is that it can be trusted, is the failure this design exists to prevent.
About the recorded address
The client address is taken from what Anthid’s network edge observed when it accepted the connection. It is not taken from the caller-supplied forwarding header that is conventionally used for this, because a caller can put anything it likes in that header. There is no fallback. When a request does not arrive through the edge, which is what an internal call between Anthid’s own services looks like, no address is recorded at all. Once written, a blank and a caller-invented string are indistinguishable, and these values are used as evidence, so recording nothing is the honest outcome.What this value is worth
A recorded address is only as trustworthy as the guarantee that traffic cannot reach Anthid except through its network edge. This is a property of how the platform is deployed, and we state it as such rather than overclaiming.