Your clients hand you the keys to their environment on the strength of your judgement. Part of that judgement is the platform you run them on — so here is exactly how Tantivo handles isolation, secrets, auditing and your data leaving, including the parts we have not built.
Every row carries the tenant it belongs to. Rows that belong to a specific client carry the client as well. Both are enforced by Postgres row-level security on read and write, inside the session — not by application code remembering a filter.
Credentials, API keys and licence keys are envelope-encrypted with a per-tenant data key, itself wrapped by a key held in Azure Key Vault. Records store a reference. Every read, write and failure is audited.
The audit log and the per-module event logs cannot be updated or deleted by the application at all — the grant does not exist. The single exception is a redaction procedure that records what was redacted and why.
Access is granted through permission bundles rather than a single role enum, across three surfaces: your operator staff, your clients’ portal users, and vendor support. Role changes are themselves audited events.
Integration credentials are held per tenant in the same vault. Disconnecting a connector destroys its stored credential; OAuth state is bound to the principal that started the flow, so a state parameter cannot be replayed by someone else.
Self-service export covers every tenant-scoped table and is generated from the database schema, so a new table cannot silently escape it. Per-record erasure tombstones the row — PII redacted, operational keys preserved — with a 30-day target.
The usual way multi-tenant software leaks is a missing WHERE tenant_id in one query nobody reviewed carefully. Tantivo does not rely on that clause being present. Sessions carry the tenant — and for portal users the client — as database claims, and row-level security policies check them on every read and every write.
The client portal runs under a different database role from your operator app. That role is default-deny: it holds grants only on the specific tables the portal needs, and on some of those only on named columns. A table nobody granted is unreachable because it was never granted.
Adding a table to the portal takes three deliberate steps — a grant, an isolation policy, and a regression test that attempts cross-client access and asserts it fails. Every tenant-scoped table ships with its policy and its test in the same change.
Export is a button in Settings, not a support conversation. It covers every tenant-scoped table, and — this is the part that matters — the export is generated from the database schema itself. When we add a table, the build fails unless that table is either included or explicitly annotated as vendor intellectual property rather than your data.
That annotation requirement is the whole point. It means “we forgot to include it” is not a failure mode that can reach production quietly.
Personal data inside event payloads is stored by reference rather than copied, so redacting a person’s record does not leave their name scattered through a hundred immutable log rows.
Microsoft Azure, West US 2. Both applications run as containers on Azure Container Apps.
Azure Database for PostgreSQL Flexible Server. Plain Postgres — no proprietary extensions in the data path.
Azure Blob Storage. Files are served through short-lived signed URLs, never public containers.
Azure Key Vault holds the key-encrypting key. Per-tenant data keys are wrapped, never stored in plaintext.
HTTPS everywhere. Behind a proxy the client address is taken from the trusted hop, not the spoofable one.
In-app sessions with argon2id password hashing, invite-only sign-up, optional Microsoft SSO with verified-email matching.
A separate auth instance, separate session cookie and a separate database role from the operator app.
Sign-in throttling on both surfaces, keyed so a shared proxy cannot be used to lock out or overload.
Tantivo is a young platform run by a small team. Some things a mature vendor offers, we do not — and you should find that out here rather than three weeks into an evaluation.
These are current limits, not permanent policy. They lift when the company is big enough to stand behind them properly — and we would rather lose a deal now than fail an audit you staked your reputation on.
In Microsoft Azure, West US 2 — Postgres for records and Azure Blob Storage for files. There is no data residency option outside that region today; if your clients require one, tell us before you sign up rather than after.
No. Prompts go to Anthropic to answer that request under commercial terms that do not train on business-tier API content, and nothing is pooled into a shared model or a cross-tenant benchmark.
Only through a separate, explicitly audited code path — not through the normal application, which is bound to your tenant like everyone else’s. Every cross-tenant read writes an audit event naming the staff member. That path exists for support and for the product-feedback feature, and it is deliberately narrow.
You export it yourself, from inside the app, before you go — no ticket, no fee, no negotiation. Deletion on request follows a documented process with a 30-day target. Backups age out on their own retention schedule after that.
There is no paid bounty programme yet. If you find something, email support@tantivo.ai and we will respond. We would much rather hear it from you.
Something not answered here? Email support@tantivo.ai and ask directly — including the awkward ones.
Bring acquisition, delivery and billing into one transparent, AI-native system. Join the waitlist for the private trial.
Prefer email? support@tantivo.ai