KeldariHow Keldari isolates, verifies, and gates your data
A plain-language walkthrough of the boundaries that matter for a technical revenue leader evaluating this system.
Tenant isolation
Each tenant's data — prospects, drafts, outcomes, and learned messaging patterns — is scoped to that tenant in Supabase/Postgres. Tenant-scoped row-level policies, not application-layer filtering alone, are the enforcement boundary. No account's outcome data trains or informs another account's model.
Credential vault posture
Keldari is BYO-provider: you bring your own sending, sourcing, and verification keys. Those credentials live in a dedicated vault, scoped per tenant, and are never shared across accounts or used to subsidize another tenant's usage.
Deliverability rails
Sending is gated on DKIM and SPF verification for your domain, enforced fail-closed — if either check doesn't pass, the send is blocked before it goes out, not flagged after. Cold outbound runs on your own sending subdomain rather than a shared Keldari or reseller domain, and new domains follow a paced warmup ramp rather than an immediate full-volume blast.
What data leaves the tenant, and where
Sourcing, verification, and sending calls go to the provider you configured (Apollo, Hunter, your ESP) using your own keys — Keldari does not proxy that traffic through a shared account. Platform and auth email (account notifications, password resets) run through Keldari's own workspace, separate from your tenant's cold-outbound sending path.
Data retention posture
Prospect, activity, and outcome records persist for as long as your account is active so scoring and learning stay grounded in your real history. Disqualified and suppressed prospects are retained with an audit trail rather than silently deleted, so you can see why a contact was excluded.