Security & governance
Built to be audited, not just trusted.
Every claim below is one we expect a security or compliance reviewer to test, not take on faith.
Tenant isolation at the database boundary
Isolation between tenants is enforced at the database layer, not left to application code to remember to filter correctly on every query. A defect in a single code path cannot expose one tenant’s data to another, because the database itself will not return it.
A counterparty’s name never reaches the model in the clear
Before any drafted commentary, rationale or recommendation is generated, a client or counterparty’s name is replaced with a stable, per-tenant token. The true value is stored encrypted and restored only inside the platform, on the way back — the model itself never learns whose data it processed. Two exceptions are stated here rather than left implicit: a public-record search (checking what is publicly known about a counterparty) still uses the real name, because a token returns no search results and this is a lookup of the public record, not a disclosure of anything proprietary; and an attached document itself — a statement, a rating report — still reaches the model as the original file at the one point it is read, since redacting inside a PDF is not something we can do reliably. That exposure is bounded to a single read per document and is covered by zero-data-retention terms with our model providers, not by this mechanism.
A tamper-evident audit ledger
Every extraction, validation, computation and approval is written to an append-only, hash-chained ledger. Each entry commits to the one before it. Altering a past entry invalidates every entry written after it, which is what makes the record usable by an internal auditor, rather than merely available to one.
Authentication, and why SMS is excluded
SMS one-time codes are not offered as a second factor anywhere in the platform. SIM-swap and port-out attacks make an SMS code a claim about a phone number, not a claim about a person, and that gap is well understood and actively exploited. Authenticator applications and hardware security keys are supported instead. This is a deliberate restriction, not an oversight, and it is not configurable away.
Deployment modes
Zarene-managed, or into your own cloud tenancy in a region you choose, so that data never has to leave an account you control. Both modes run the same validation and approval logic; the difference is where it runs, not what it does.
Data protection and processor role
Your organisation is the data controller. Zarene AI acts as processor, handling data only as instructed and only for the purpose of delivering the platform.